Een commercieel softwareteam kan een nieuwe functie in enkele minuten naar productie verzenden: een pull request passeert geautomatiseerde tests, een reviewer keurt goed, de CI-pijplijn bouwt en implementeert. Voor defensiesoftwareteams moet hetzelfde leveringspad navigeren in een fundamenteel ander beperkingsruimte: ITAR-exportregelgeving die beperkt wie toegang heeft tot bouw-artefacten, STIG-nalevingsvereisten die definiëren hoe elke laag van de stack geconfigureerd moet zijn, SBOM-mandaten die een machineleesbare inventaris van elke afhankelijkheid vereisen, en implementatieomgevingen die mogelijk helemaal geen internetverbinding hebben. Het resultaat is dat veel defensieprogramma's CI/CD geheel verlaten ten gunste van handmatige, gate-zware releaseprocessen — of commerciële CI/CD-tools adopteren zonder de nalevingsbekabeling en auditverantwoordelijkheden creëren.

Geen van beide uitkomsten is noodzakelijk. Een CI/CD-pijplijn voor defensiesoftware die voldoet aan ITAR-controles, STIG-conforme artefacten produceert, ondertekende SBOM's genereert en implementeert in air gap-omgevingen is haalbaar met beschikbare open source-tools en een duidelijk architectuurpatroon. Dit artikel beschrijft dat patroon en behandelt keuzes voor pijplijninfrastructuur, geautomatiseerde teststadia, SBOM-generatie, containerverharding, air gap-implementatie, terugdraaiprocedures en vereisten voor auditsporen.

Beperkingen van defensiesoftware: ITAR, STIG en classificatieafhandeling in CI

De International Traffic in Arms Regulations (ITAR) beheren de export van defensieartikelen en -diensten, inclusief technische gegevens gerelateerd aan defensiesystemen. In een CI/CD-context kunnen broncode, bouw-artefacten en testresultaten allemaal exportgecontroleerd zijn, en toegang moet worden beperkt tot Amerikaanse personen. Build runners die ITAR-gecontroleerde code verwerken, moeten draaien op systemen waar toegang wordt afgedwongen op infrastructuurniveau — zelfbeheerde runners op lokale hardware of runners in een FedRAMP High- of DoD IL4/IL5-cloudenclave met gedocumenteerde toegangscontroles.

Het Technology Control Plan (TCP) van het programma moet de CI/CD-infrastructuur in zijn bereik opnemen. Classificatieafhandeling voegt een verdere beperking toe: de CI/CD-pijplijn zelf draait op het hoogste classificatieniveau van elk artefact dat het produceert.

Pijplijnarchitectuur: on-premises GitLab vs. SaaS, air gap-overwegingen

GitLab zelfbeheerd is de dominante CI/CD-platformkeuze voor gevoelige defensieprogramma's. Het draait volledig op infrastructuur die u beheert, ondersteunt volledig offline installatie, integreert met Active Directory en LDAP voor toegangscontrole, en heeft een grote installatiebasis in DoD-programma's. Het artefactregister moet ook draaien op infrastructuur die u beheert — Harbor voor containers, Artifactory of Nexus voor taalecosysteemafhankelijkheden. Voor air gap-implementaties brengt een mirrorupdate-proces externe inhoud over het air gap op een gedocumenteerd schema.

Geautomatiseerde teststadia: van unit-tests tot STIG-nalevingsscan

Een defensie CI/CD-pijplijn vereist: unit- en integratietests bij elke commit; SAST (Semgrep of SonarQube) bij elk pull request; DAST (OWASP ZAP) tegen een geïmplementeerde testinstantie; software composition analysis (Grype of Trivy) tegen een interne kwetsbaarhedenspiegel; STIG-nalevingsscanning (InSpec met DISA-profielen of OpenSCAP); geheimen-detectie; en licentienalevering. Elke fase stopt de pijplijn bij beleidsschendingen zonder handmatige omzeilingsmogelijkheid.

SBOM-generatie: CycloneDX/SPDX, Grype/Trivy, licentienalevering

NDAA Sectie 1655 (FY2023) gaf DoD de opdracht richtlijnen te ontwikkelen die SBOM's van softwareleveranciers vereisen. SBOM's worden gegenereerd tijdens het bouwen met Syft of cdxgen in CycloneDX- of SPDX-formaat, ondertekend naast het bouw-artefact met Cosign, en opgeslagen in het artefactregister als eersteklas artefacten. Grype of Trivy kruisverwijzen SBOM-componenten met CVE-databases en produceren VEX-annotaties. Licentienalevering wordt afgedwongen als parallelle gate.

Containerverharding: distroless bases, non-root uitvoering, seccomp, image-ondertekening

Defensiecontainerimages gebruiken distroless of DISA STIG-verharde basisimages, draaien als niet-root gebruikers, gebruiken alleen-lezen root-bestandssystemen, passen RuntimeDefault of aangepaste seccomp-profielen toe, en zijn ondertekend met Cosign of Notary v2. Toelatingsbeheerders (OPA/Gatekeeper of Kyverno) handhaven deze vereisten bij pod-planningsmoment in alle clusters.

Implementatie in geclassificeerde omgevingen: sneakernet-overdracht, hash-verificatie, manifest-ondertekening

De pijplijn produceert een ondertekend implementatiepakket met: ondertekende binaries of containerimages, SBOM, kwetsbaarheidscanresultaten, SLSA-herkomstattestate, implementatiemanifest en SHA-256-hashbestand. Overdracht kruist het air gap via een geaccrediteerde cross-domain-oplossing of gedocumenteerde sneakernet-procedures. Aan de geclassificeerde kant verifieert het installatiescript hash en handtekening voordat het verdergaat.

Terugdraaiprocedures: blue-green voor services, SQLite-snapshots voor ingebedde systemen

Webservices gebruiken blue-green-implementaties — terugdraaien is een verkeersomschakeling, geen herimplementatie. Ingebedde systemen en SQLite-gebaseerde applicaties gebruiken versioned pre-upgrade snapshots. De CI-pijplijn test het snapshot/herstelpad in integratietests. Alle terugdraaievents worden geregistreerd in het onveranderlijk auditspoor.

Vereisten voor auditspoor: onveranderlijke logs, wijzigingsgoedkeuringen, vereistentracerbaarheid

Pijplijnlogs worden opgeslagen in een schrijf-eenmalig SIEM of objectopslag met objectvergrendeling. Elke implementatie verwijst naar een goedgekeurd wijzigingsticket. Traceerbaarheid koppelt ontwikkelwerkitems aan vereistenelementen, met testresultaten gekoppeld aan werkitems. De pijplijn koppelt samenvatingen van testresultaten en artefacthashes aan het relevante issue bij implementatievoltooiing.

Kerninzicht: Een conforme defensie CI/CD-pijplijn vertraagt de levering niet — het maakt snelle levering mogelijk in een omgeving met hoge nalevingseisen. Programma's die investeren in pijplijnnalevingsinfrastructuur halen de investering terug in elke releasecyclus en bij elke daaropvolgende ATO-verlenging.