Verwijzigingen naar OpenVAS verwijderd. (#1007)

Closes #949.

Author: fniessink

Content/Maatregelen/M16/Definitie.md

@@ -9,15 +9,14 @@ ICTU stelt het gebruik van tools verplicht voor de volgende taken:
 5. release van software,
 6. maken van testrapportages,
 7. maken van kwaliteitsrapportages,
-8. controleren van de configuratie op aanwezigheid van bekende kwetsbaarheden,
-9. controleren van door de applicatie gebruikte versies van externe software op aanwezigheid van bekende kwetsbaarheden,
-10. statische controle van de software op aanwezigheid van kwetsbare constructies,
-11. dynamische controle van de software op aanwezigheid van kwetsbare constructies,
-12. controleren van container images op aanwezigheid van bekende kwetsbaarheden,
-13. testen van performance en schaalbaarheid,
-14. testen op toegankelijkheid van de applicatie,
-15. produceren van een "software bill of materials" (SBoM),
-16. opslaan van artifacten,
-17. registratie van incidenten bij gebruik en beheer, en
-18. bij het uitvoeren van operationeel beheer; uitrollen van de software in de productieomgeving.
+8. controleren van door de applicatie gebruikte versies van externe software op aanwezigheid van bekende kwetsbaarheden,
+9. statische controle van de software op aanwezigheid van kwetsbare constructies,
+10. dynamische controle van de software op aanwezigheid van kwetsbare constructies,
+11. controleren van container images op aanwezigheid van bekende kwetsbaarheden,
+12. testen van performance en schaalbaarheid,
+13. testen op toegankelijkheid van de applicatie,
+14. produceren van een "software bill of materials" (SBoM),
+15. opslaan van artifacten,
+16. registratie van incidenten bij gebruik en beheer, en
+17. bij het uitvoeren van operationeel beheer; uitrollen van de software in de productieomgeving.
 <!-- end: measure -->

Content/Maatregelen/M16/Maatregel.md

@@ -13,17 +13,16 @@ ICTU adviseert en ondersteunt voor de genoemde taken onderstaande tools. Project
 5. release van software: Releaseserver in het ontwikkelplatform,
 6. maken van testrapportages: JUnit, Robot Framework, TestNG, of hiermee compatible tools,
 7. maken van kwaliteitsrapportages: Quality-time,
-8. controleren van de configuratie op aanwezigheid van bekende kwetsbaarheden in configuratie: OpenVAS (Vulnerability Assessment System),
-9. controleren op aanwezigheid van bekende kwetsbaarheden in externe software: OWASP (Open Web Application Security Project) Dependency-Check en/of Dependency-Track,
-10. statische controle van de software op aanwezigheid van kwetsbare constructies: SonarQube,
-11. dynamische controle van de software op aanwezigheid van kwetsbare constructies: ZAP (Zed Attack Proxy) by Checkmarx,
-12. controleren van container images op aanwezigheid van bekende kwetsbaarheden: Trivy,
-13. testen van performance en schaalbaarheid: JMeter en Performancetestrunner,
-14. testen op toegankelijkheid van de applicatie: Axe,
-15. produceren van een "software bill of materials" (SBoM): tools die een SBoM in CycloneDX-formaat (zie https://cyclonedx.org) genereren,
-16. opslaan van artifacten: Nexus of Harbor,
-17. registratie van incidenten bij gebruik en beheer: Jira, en
-18. bij het uitvoeren van operationeel beheer; uitrollen van de software in de productieomgeving: Ansible.
+8. controleren op aanwezigheid van bekende kwetsbaarheden in externe software: OWASP (Open Web Application Security Project) Dependency-Check en/of Dependency-Track,
+9. statische controle van de software op aanwezigheid van kwetsbare constructies: SonarQube,
+10. dynamische controle van de software op aanwezigheid van kwetsbare constructies: ZAP (Zed Attack Proxy) by Checkmarx,
+11. controleren van container images op aanwezigheid van bekende kwetsbaarheden: Trivy,
+12. testen van performance en schaalbaarheid: JMeter en Performancetestrunner,
+13. testen op toegankelijkheid van de applicatie: Axe,
+14. produceren van een "software bill of materials" (SBoM): tools die een SBoM in CycloneDX-formaat (zie https://cyclonedx.org) genereren,
+15. opslaan van artifacten: Nexus of Harbor,
+16. registratie van incidenten bij gebruik en beheer: Jira, en
+17. bij het uitvoeren van operationeel beheer; uitrollen van de software in de productieomgeving: Ansible.
 
 ### Rationale
 

Content/Templates/Detailtestplan-Softwarerealisatie/Template-Inhoud.md

@@ -30,7 +30,7 @@ Binnen het project worden door ICTU de volgende testsoorten onderscheiden en toe
   + **Handmatig regressietest:** Het handmatig uitvoeren van fysieke testgevallen om de werking van de bestaande functionaliteit te controleren. Deze testgevallen zijn veelal te complex om te automatiseren.
 * Niet-functionele testen:
   + **Performancetesten:** Het testen van de snelheid van afhandeling van bepaalde functies van het systeem onder een vooraf gedefinieerde belasting. Performancetesten vinden bij voorkeur plaats in een productie-like omgeving, maar kunnen ook in een niet-productie-like omgeving plaatsvinden ten behoeve van het volgen van de relatieve performance van verschillende versies van de software. Er vinden zowel een loadtest (normale en piekbelasting), als een duurtest (normale belasting voor langere tijd), als een stresstest (verhogen van de belasting totdat het systeem het begeeft) plaats. De Kwaliteitsaanpak schrijft voor dat er tijdens de realisatiefase performancetesten worden uitgevoerd. Deze worden bij voorkeur automatisch uitgevoerd. Belangrijk is dat de performancetest die op de testomgeving wordt uitgevoerd, niet vanzelfsprekend representatief is voor de productieomgeving. Dit betekent dat een opdrachtgevende organisatie op de eigen productieomgeving een performancetest moet (laten) uitvoeren om te controleren dat er aan de gestelde performance-eisen is voldaan.
-  + **Securitytesten:** Security- en penetratietesten uitgevoerd door een externe partij. Normaliter worden deze minimaal twee maal per jaar of met elke grote release uitgevoerd en niet elke sprint. Securitytesten vinden bij voorkeur plaats in een productie-like omgeving, maar kunnen ook in een niet-productie-like omgeving plaatsvinden ten behoeve van het testen van de beveiliging van de software zelf. De securitytest is inclusief een review van de broncode. Tijdens de realisatie draaien standaard al de volgende securitytesttools mee in de geautomatiseerde pijplijn: SonarQube, OWASP Dependency-Check en/of Dependency-Track, ZAP by Checkmarx en OpenVAS; de bevindingen die uit deze tools komen worden meteen tijdens de realisatie van het systeem opgepakt.
+  + **Securitytesten:** Security- en penetratietesten uitgevoerd door een externe partij. Normaliter worden deze minimaal twee maal per jaar of met elke grote release uitgevoerd en niet elke sprint. Securitytesten vinden bij voorkeur plaats in een productie-like omgeving, maar kunnen ook in een niet-productie-like omgeving plaatsvinden ten behoeve van het testen van de beveiliging van de software zelf. De securitytest is inclusief een review van de broncode. Tijdens de realisatie draaien standaard al de volgende securitytesttools mee in de geautomatiseerde pijplijn: SonarQube, OWASP Dependency-Check en/of Dependency-Track en ZAP by Checkmarx; de bevindingen die uit deze tools komen worden meteen tijdens de realisatie van het systeem opgepakt.
 * **Integratietesten:** Tijdens deze test wordt de onderlinge verwerkingswijze tussen de verschillende applicaties getest. Denk hierbij aan gewijzigde applicaties die samen werken met ongewijzigde applicaties. Indien van toepassing zullen hier ook externe systemen bij betrokken worden, in de vorm van stubs. Integratietesten zijn normaal gesproken geautomatiseerde tests. Als onderdeel van de integratietesten wordt getest of de software kan omgaan met fouten in andere applicaties en na een herstart goed blijft functioneren.
 * **Gebruikersacceptatietest (GAT):** In tegenstelling tot de ‘traditionele’ watervalmethode biedt agile ontwikkelen meer ruimte voor de gebruiker om te participeren in het ontwikkeltraject. Tijdens elke sprint wordt nieuwe functionaliteit gedemonstreerd door het Scrumteam in een demo-omgeving. {opdrachtgevende organisatie} en/of beheerorganisatie kan een GAT-testomgeving beschikbaar stellen waar gebruikers kunnen werken met de nieuwe applicaties. Bevindingen worden tijdens trainingen of workshops verzameld om in de product backlog verwerkt te worden. De product owner prioriteert vervolgens deze bevindingen.
 * **Usabilitytesten:** Het doel van deze test is om te bepalen hoe gemakkelijk / toegankelijk het systeem is in het gebruik ervan. Onderdeel van deze test is de toegankelijkheidstest; hiermee wordt bepaald in welke mate de software voldoet aan de wettelijke vereisten van de Web Content Accessibility Guidelines (WCAG2.2) en eventuele aanvullende toegankelijkheidseisen. Deze toegankelijkheidstesten worden waar mogelijk geautomatiseerd uitgevoerd. De toegankelijkheidseisen die niet geautomatiseerd getest kunnen worden, worden periodiek handmatig getest.

Content/Templates/Inwerkplan-Kwaliteitsmanager/Template-Inhoud.md

@@ -174,7 +174,7 @@ Acties (week 3):
 * Je hebt toegang tot het versiebeheersysteem van je project (GitLab of Azure DevOps)
 * Je hebt toegang tot de build server van je project (GitLab CI, Azure DevOps of Jenkins)
 * Je hebt toegang tot je project in [Jira](https://jira.ictu-sd.nl/jira/)
-* Je hebt toegang tot de securityrapportages in de build pipeline (OWASP Dependency-Check, ZAP by Checkmarx, OpenVAS)
+* Je hebt toegang tot de securityrapportages in de build pipeline (Dependency-Track, OWASP Dependency-Check, ZAP by Checkmarx )
 * Je hebt toegang tot de toegankelijksrapportage (Axe) in de build pipeline
 * Je hebt toegang tot de testrapportages in de build pipeline (Robot Framework, JUnit, Cypress, etc.)
 * Je hebt toegang tot de Dependency-Track instantie van je project

Content/Templates/Kwaliteitsplan/Template-Inhoud.md

@@ -280,7 +280,7 @@ Quality-time rapporteert over de geautomatiseerde performancetesten. Als de vera
 
 De eisen aan de beveiliging worden in de documenten projectstartarchitectuur en niet-functionele eisen gedefinieerd. De in te richten testen dienen aan te tonen dat aan de gestelde beveiligingseisen wordt voldaan.
 
-De geautomatiseerde broncodereviews en rapportages uit Quality-time bevatten diverse metrieken voor beveiligingsaspecten, zoals de OWASP Top-10-criteria. De applicatie wordt gescand met behulp van SonarQube, OWASP Dependency-Check en/of Dependency-Track, ZAP by Checkmarx en OpenVAS.
+De geautomatiseerde broncodereviews en rapportages uit Quality-time bevatten diverse metrieken voor beveiligingsaspecten, zoals de OWASP Top-10-criteria. De applicatie wordt gescand met behulp van SonarQube, OWASP Dependency-Check en/of Dependency-Track en ZAP by Checkmarx.
 
 Om de beveiliging van de software te testen kan deze met enige regelmaat getest worden door een externe partij. Het MTP beschrijft de gekozen aanpak.
 

Content/Templates/PvA-Realisatiefase/Template-Inhoud.md

@@ -29,7 +29,7 @@ ICTU levert de volgende producten en diensten op:
 Binnen de scope van de opdracht valt de {ontwikkeling en/of het onderhoud} van {het product}, inclusief:
 
 * Ontwikkel, test- en demo-omgevingen,
-* Engineering tools voor versiebeheer (GitLab of Azure DevOps), bouwen en testen (Azure DevOps, GitLab en/of Jenkins), kwaliteitscontrole (SonarQube), beveiligingscontrole (SonarQube, OWASP Dependency-Check en/of Dependency-Track, ZAP by Checkmarx, OpenVAS), toegankelijkheid (Axe), performancetesten (JMeter) en integrale kwaliteitsrapportage (Quality-time),
+* Engineering tools voor versiebeheer (GitLab of Azure DevOps), bouwen en testen (Azure DevOps, GitLab en/of Jenkins), kwaliteitscontrole (SonarQube), beveiligingscontrole (SonarQube, OWASP Dependency-Check en/of Dependency-Track en ZAP by Checkmarx), toegankelijkheid (Axe), performancetesten (JMeter) en integrale kwaliteitsrapportage (Quality-time),
 * {Als operationeel beheer onderdeel is van de dienstverlening:} Uitrollen in de productieomgeving (Ansible), container registry (Harbor), performance monitoring (APM), security monitoring ({vul aan met concreet product}), controle van kwetsbaarheden in frameworks ({vul aan met concreet product}), controle van images van containers (Trivy), registratie van incidenten bij gebruik en beheer (Topdesk of Jira).
 * Product en sprint backlog management tools (Jira en/of Azure DevOps),
 * Beveiligings- en performancetesten in de ICTU-testomgevingen. ICTU voert deze tests uit voordat een nieuwe versie van de software wordt opgeleverd. {Beschrijf hier eventuele andere afspraken met de opdrachtgevende organisatie}.

Content/Wijzigingsgeschiedenis.md

@@ -1,3 +1,9 @@
+# Versie 5.0.0, nog niet gereleased
+
+## Alle documenten
+
+* Verwijzigingen naar OpenVAS verwijderd. Te weinig projecten leveren infrastructuur op om OpenVAS als verplicht tool voor te schrijven.
+
 # Versie 4.2.0, 24 maart 2025
 
 ## Kwaliteitsaanpak
@@ -52,6 +58,7 @@
 ## Alle documenten
 
 * De spelling van business impact analysis veranderd in business impact analyse, conform NORA.
+* Product backlog, sprint backlog en product owner consistent geschreven.
 
 # Versie 4.0.4, 16 december 2024