DevSecOps voor defensie: beveiliging in elke sprint integreren

DevSecOps — de integratie van beveiligingspraktijken in de levenscyclus van softwareontwikkeling en -operaties — is geen nieuw concept in commerciële softwareontwikkeling. In defensiesoftwareprogramma's blijft het echter een gebied waar de kloof tussen ambitie en praktijk groot is. Veel defensieprogramma's leveren beveiliging nog steeds als een gate aan het einde van de ontwikkelcyclus: een penetratietest, een beveiligingsreview, een accreditatieproces, allemaal plaatsvindend nadat de code functioneel compleet is. Dit model is duur, traag en produceert software met beveiligingstekortkomingen die na levering kostbaar zijn om te verhelpen.

Een DevSecOps-aanpak verschuift beveiliging naar links — het integreert het in elke sprint in plaats van het te behandelen als een release-gate. Dit artikel legt uit waarom einde-van-sprint beveiligingsreview mislukt in defensie, hoe SAST, DAST en SCA in een geautomatiseerde pijplijn te integreren, hoe omgaan met geheimen en geheimbeheer, en hoe STIG-compliance als continue pijplijnoutput te onderhouden in plaats van als een eenmalige audit.

Waarom einde-van-sprint beveiligingsreview mislukt in defensie

Het traditionele defensiesoftware-beveiligingsmodel creëert een structurele mismatch: ontwikkelaars besteden maanden aan het bouwen van functionaliteit, dan besteedt een beveiligingsteam weken aan het vinden van kwetsbaarheden in de voltooide code. De herstelkosten zijn hoog omdat het repareren van een beveiligingskwetsbaarheid in geïmplementeerde of bijna-geïmplementeerde code regressietests, her-review en mogelijk herwerk van meerdere afhankelijke componenten vereist. NIST-onderzoek (gerefereerd in hun SP 800-64) schatte dat de kosten om een beveiligingskwetsbaarheid te repareren die bij ontwerp gevonden is 1x zijn; dezelfde kwetsbaarheid gevonden bij testen is 15x; en gevonden bij implementatie is 30x of meer.

In defensieprogramma's versterkt de accreditatietijdlijn dit probleem. Een Authority to Operate (ATO) proces — vereist voordat een DoD-systeem operationele gegevens kan verwerken — duurt doorgaans 6-18 maanden voor een nieuw systeem. Als beveiligingsbevindingen laat in de ontwikkeling opduiken, verlengen ze de al-lange accreditatietijdlijn. Een enkele hoge-ernst bevinding die tijdens de finale beveiligingsbeoordeling wordt gevonden, kan een programma maandenlang vertragen terwijl de kwetsbaarheid wordt verholpen en de beoordeling wordt herhaald.

Het DevSecOps-alternatief: beveiligingstools draaien op elke code-commit en elk pull-verzoek. Ontwikkelaars ontvangen beveiligingsfeedback binnen minuten, in dezelfde ontwikkelworkflow die ze al gebruiken. Beveiligingsschuld wordt sprint-voor-sprint geëlimineerd in plaats van geaccumuleerd en in één pijnlijk blok aan het einde van het programma betaald.

SAST, DAST en SCA in de geautomatiseerde pijplijn

Static Application Security Testing (SAST) analyseert broncode zonder deze uit te voeren, op zoek naar patronen die geassocieerd worden met beveiligingskwetsbaarheden: SQL-injectie, opdrachtinjectie, bufferoverloop, hardgecodeerde referenties, onveilige cryptografische functieaanroepen en honderden andere zwaktepatronen. SAST draait op elke commit en elk pull-verzoek als onderdeel van de CI-pijplijn.

Semgrep is de open-source SAST-tool die standaard is geworden in moderne DevSecOps-pijplijnen. De regelgebaseerde aanpak maakt het schrijven van aangepaste regels mogelijk voor organisatiespecifiek beveiligingsbeleid, en de snelheid (doorgaans onder 30 seconden voor een middelgrote codebase) maakt het geschikt voor pull-verzoekfeedback. Semgrep onderhoudt een curated regelset voor veelvoorkomende kwetsbaarheidsklassen en ondersteunt regels voor DoD-specifieke beveiligingszorgen (onveilige crypto-primitieven die zijn verboden door CNSA-beleid, bijvoorbeeld).

Dynamic Application Security Testing (DAST) test de draaiende applicatie door aanvallergedrag te simuleren: gecrafted HTTP-verzoeken sturen, injectie-aanvallen proberen, authenticatiemechanismen testen. OWASP ZAP (Zed Attack Proxy) is de standaard open-source DAST-tool. In een CI/CD-pijplijn draait ZAP in "headless"-modus tegen een geïmplementeerde testinstantie van de applicatie, genereert een bevindingsrapport dat wordt gepubliceerd naar het beveiligingsdashboard en kan de implementatiepijplijn gatten op hoge-ernst bevindingen.

Software Composition Analysis (SCA) identificeert bekende kwetsbaarheden in externe bibliotheken en open-source afhankelijkheden. Gezien dat moderne softwareapplicaties doorgaans 70-90% externe code zijn per componenttelling, is SCA kritisch voor defensieprogramma's met toeleveringsketenbeveiligingszorgen. Grype (van Anchore) en Trivy (van Aqua Security) zijn de twee toonaangevende open-source SCA-tools. Beide onderhouden databases van CVE's kruisgerefereerd tegen pakketdatabases voor grote taalecosystemen (npm, PyPI, Maven, Go-modules, etc.) en produceren gestructureerde bevindingsrapporten die kunnen worden ingepast door SIEM of beveiligingsdashboard-tooling.

Geheimdetectie: het voorkomen van referentielekken in defensiepijplijnen

Hardgecodeerde geheimen — API-sleutels, databasewachtwoorden, privésleutels, toegangstokens — in broncode-opslagplaatsen zijn een eeuwig beveiligingsprobleem. Voor defensiesoftware zijn de gevolgen ernstig: een gelekte API-sleutel naar de backend van een geclassificeerd systeem kan een adversair directe toegang tot dat systeem bieden zonder enige exploitatie van de applicatielaag vereiste te vereisen.

Pre-commit hooks zijn de eerste verdedigingslinie: git-hooks die draaien voordat een commit wordt geaccepteerd, de gefaseerde wijzigingen scannen op patronen die overeenkomen met bekende geheimformaten (AWS-toegangssleutels, Google Cloud-referenties, privésleutelheaders, etc.). Twee tools domineren dit gebied: detect-secrets (van Yelp, breed gebruikt in enterprise DevSecOps) en Gitleaks (speciaal gebouwd voor git-geschiedenis en pre-commit-scanning). Beide onderhouden patroonbibliotheken voor honderden geheimtypen en ondersteunen aangepaste patronen voor defensiespecifieke referentieformaten.

HashiCorp Vault biedt het positieve alternatief voor hardgecodeerde geheimen: een gecentraliseerd geheimbeheersysteem dat applicaties bij runtime bevragen om referenties op te halen, in plaats van deze op te slaan in configuratiebestanden of omgevingsvariabelen. De dynamische geheimen-functie van Vault genereert kortstondige, automatisch verlopende referenties voor elk applicatieverzoek — een databasewachtwoord dat 1 uur geldig is biedt dramatisch minder aanvalsoppervlak dan een statische referentie die voor onbepaalde tijd geldig is. In defensiepijplijnen wordt Vault doorgaans on-premises geïmplementeerd (niet de Vault-cloudservice) om controle over de geheimensinfrastructuur te behouden.

Container-imagescan in defensieregisters

Containerisatie is standaard geworden in defensiesoftwareprogramma's — Kubernetes-implementaties op DoD-platforms zoals Platform One (P1) en nog-te-classificeren cloudomgevingen gebruiken container-images als de implementatie-eenheid. Container-images kunnen kwetsbaarheden dragen vanuit hun basisimages en vanuit pakketten die tijdens het image-bouwproces zijn geïnstalleerd. Container-imagescan integreert kwetsbaarheidsdetectie in de container-build en registerworkflow.

Harbor is het CNCF-afgestudeerde open-source containerregister met ingebouwde beveiligingsscan. In een defensie DevSecOps-pijplijn dient Harbor als het organisatiecontainerregister en scant automatisch images bij push met Trivy als scannerbackend. Scanresultaten worden aan elk image in het register gekoppeld, en toelatingsbeheersbeleidsregels (geïmplementeerd via de ingebouwde beleidsmotor van Harbor) kunnen implementatie van images met kritieke kwetsbaarheden voorkomen.

Toelatingsbeheersbeleidsregels handhaven beveiligingsvereisten op het Kubernetes API-niveau: elke poging om een pod te implementeren wordt geëvalueerd aan een beleidsset voordat het wordt toegelaten tot het cluster. Voor defensieomgevingen handhaven beleidsregels: geen images van niet-geverifieerde registers, geen images met kritieke CVE's boven een opgegeven CVSS-drempel, geen geprivilegieerde containers, geen containers die als root draaien en resourcelimietvereisten. OPA/Gatekeeper en Kyverno zijn de standaard toelatingsbeheerframeworks.

Accreditatie-bewuste CI/CD: STIG-compliance onderhouden

Security Technical Implementation Guides (STIG's) zijn configuratiestandaarden gepubliceerd door DISA (Defense Information Systems Agency) die de beveiligingsconfiguratie-eisen definiëren voor elke categorie technologie die in DoD-systemen wordt gebruikt: besturingssystemen, webservers, databases, netwerkapparaten en steeds meer container-platformen en Kubernetes-configuraties. STIG-compliance is een harde vereiste voor DoD ATO, geen aanbevolen beste praktijk.

Traditionele STIG-compliancevalidatie wordt handmatig uitgevoerd bij audittijd: een beveiligingsbeoordelaar voert een STIG-compliant scantool uit (SCAP-compliant scanner met de STIG XCCDF-inhoud) tegen het geïmplementeerde systeem en genereert een bevindingsrapport. Dit produceert een eenmalig compliance-beeld dat de huidige configuratie mogelijk niet weerspiegelt als het systeem na de audit verandert.

Een accreditatie-bewuste CI/CD-pijplijn behandelt STIG-compliance als continue output. InSpec (van Chef) met STIG-profielen of OpenSCAP biedt programmatische STIG-compliancecontrole die als een pijplijnfase kan draaien. Container-images worden gebouwd met STIG-conforme basisconfiguraties (met DISA-gepubliceerde STIG-geharde basisimages of bouwen vanuit een bekende STIG-geharde basis), en compliance wordt geverifieerd bij buildtijd. Elke configuratieafwijking van de STIG-basislijn leidt tot een pijplijnmislukking en een bevinding in het beveiligingsdashboard, in plaats van maanden later tijdens een audit ontdekt te worden.