SBOM-handhaving in Defensie CI/CD-pipelines: Van CycloneDX tot NDAA-afgestemde Gates

De Software Bill of Materials (SBOM) verschoof van optioneel artefact naar contractuele verplichting sneller dan de meeste defensieaannemers hadden verwacht. In 2021 was het een aanbeveling begraven in Executive Order 14028. Tegen 2026 is het een gate-conditie — elke binaire module die aan een Amerikaanse of NATO-klant wordt geleverd, moet een actueel, ondertekend, machine-leesbaar SBOM bijgevoegd hebben, en de pipeline die de binaire module produceerde moet in staat zijn om op audittijd te bewijzen dat de SBOM werd gegenereerd uit dezelfde bronnen, in dezelfde build, die het artefact produceerde. Dit artikel doorloopt de engineering-beslissingen die bepalen of uw CI/CD-pipeline die audit doorstaat.

1. Waarom SBOM Verplicht Werd in Defensie

Vier regelgevende draden kwamen samen. Executive Order 14028 (mei 2021) vereiste dat federale softwareleveranciers SBOM's zouden verstrekken en legde de basis voor de NTIA "minimale elementen." NDAA Section 1655 (FY2023, verfijnd door FY2026-amendementen) breidde SBOM-vereisten uit naar defensieaankopen, met als verplichting dat DoD-hoofdaannemers en onderaannemers SBOM's leveren voor alle software die aan het Departement wordt geleverd, met specifieke bepalingen over componenten van Chinese oorsprong en leveranciers uit vijandige landen. NIS2 oefende parallelle druk uit op de EU-defensiebasis, met als vereiste gedocumenteerd toeleveringsketen-risicobeheer voor essentiële en belangrijke entiteiten. NIST SP 800-218 — het Secure Software Development Framework (SSDF) — codificeerde SBOM-generatie als een verwachte praktijk voor elke leverancier die zichzelf attesteert onder OMB M-22-18 en M-23-16.

Het praktische effect is dat een defensiesoftware-vendor zonder SBOM-tooling in 2026 geen concurrerende vendor is. Aanbestedingen bevatten SBOM-clausules. Audits bevatten SBOM-controles. En een ontbrekende SBOM wordt op dezelfde manier behandeld als een ontbrekend testrapport — als bewijs dat het engineeringproces van de leverancier onvolledig is. Het goede nieuws voor engineeringteams is dat SBOM-generatie, eenmaal correct geïnstrumenteerd, goedkoop te onderhouden is. Het slechte nieuws is dat "correct geïnstrumenteerd" een lange lijst architectuurbeslissingen verbergt, waarvan de meeste de eerste keer verkeerd worden gemaakt.

2. CycloneDX vs SPDX

Twee SBOM-formaten zijn van belang: CycloneDX (oorspronkelijk bij OWASP, nu een Ecma-standaard) en SPDX (oorspronkelijk bij de Linux Foundation, ISO/IEC 5962:2021). Ze dekken hetzelfde conceptuele terrein — componenten, versies, licenties, hashes, relaties — maar de dialecten divergeren op manieren die van belang zijn voor tooling.

CycloneDX is geoptimaliseerd voor beveiligingstoepassingen: native VEX-ondersteuning, eersteklas kwetsbaarheids-velden, lichtgewicht JSON, strakke integratie met het OWASP-ecosysteem (Dependency-Track, dependency-check). Het is het formaat dat de meeste beveiligingsteams standaard produceren. SPDX is geoptimaliseerd voor licentie- en herkomsttoepassingen: rijkere licentie-expressietaal, langere staat van dienst in open-source nalevingsaudits, het ISO-stempel dat juridische en inkoop-teams vragen in gereguleerde sectoren.

Defensieklanten vragen om beide. NDAA-afgestemde contracten specificeren steeds vaker "SPDX 2.3 of hoger, of CycloneDX 1.5 of hoger," waardoor de formatkeuze aan de leverancier wordt overgelaten — totdat de downstream-tooling van de klant het een of het ander forceert. Het pragmatische patroon is dubbele uitvoer: genereer een CycloneDX SBOM in de build voor interne kwetsbaarheids-tooling, transformeer dan naar SPDX bij levering met een converter (cyclonedx-py, cdx2spdx of de SPDX-toolsketen). Behandel één als de waarheidsbron en de andere als een afgeleid artefact; houd beide geversieneerd naast de binaire module.

3. Build-Time vs Post-Build SBOM-generatie

De enkelvoudig grootste bepalende factor voor SBOM-geloofwaardigheid is wanneer in de pipeline de SBOM wordt geproduceerd. Er zijn twee kampen. Post-build scanners (Trivy, Snyk, GitHub-native afhankelijkheidsgrafiek in scanmodus) nemen een afgewerkte containerimage of binaire module op en reconstrueren de componenten. Build-time generatoren (Syft wanneer ingebouwd in de build, cdxgen, taalspecifieke tooling zoals cargo cyclonedx, mvn cyclonedx, npm sbom) observeren het werkelijke bouwproces en geven de SBOM uit vanuit de opgeloste afhankelijkheidsgrafiek die de build gebruikte.

Alleen build-time generatie is geloofwaardig bij audit. De reden is eenvoudig: een post-build scanner identificeert wat hij kan zien — hij kan geen onderscheid maken tussen een bibliotheek die statisch is gelinkt in de binaire module en een bibliotheek die werd binnengehaald voor een build-time tool maar nooit werd geleverd. Hij kan geen privéregistries zien waarvoor de scanner geen referenties heeft. Hij kan compiletijd-codegeneratie niet zien. Een reviewer die vraagt "hoe weet u dat deze SBOM volledig is?" krijgt alleen een bruikbaar antwoord wanneer de SBOM door de build zelf werd geproduceerd, met herkomst terug naar de lockfiles. Post-build scanning is een nuttige tweede mening. Het is niet het primaire artefact.

In de praktijk convergeren teams op een stack van Syft voor OS- en containerlagen, taalnatieve generatoren (cargo, npm, pip, mvn, go-licenses met CycloneDX-uitvoer) voor broncomponenten, cdxgen wanneer polyglot-repositories een enkele doorgang nodig hebben, en Trivy of GitHub's native SBOM-export als post-build kruiscontrole. De build-pipeline voegt de taalnatieve uitvoeren samen tot één CycloneDX-document, ondertekent het en voegt het bij het uitgebrachte artefact.

4. SBOM-ondertekening en Attestatie

Een ongetekende SBOM is geen bewijs. Een reviewer kan niet verifiëren dat het werd geproduceerd door de build die de binaire module produceerde; hij kan niet verifiëren dat het niet is bewerkt; hij kan niet bewijzen dat de buildomgeving vertrouwd was. De oplossing is attestatie — een ondertekende verklaring, geproduceerd door het bouwsysteem, die de SBOM koppelt aan een specifieke artefacthash.

De dominante primitieven zijn sigstore/cosign voor sleutelloze ondertekening (OIDC-gebonden certificaten, transparantielogboek in Rekor) en in-toto-attestaties voor het verklaringsformaat. Een in-toto-attestatie heeft drie delen: het onderwerp (de artefacthash die wordt geattesteerd), het predicaattype (bijv. https://cyclonedx.org/bom of het SLSA-herkomsttype) en het predicaatlichaam (de SBOM zelf of de build-herkomst). Cosign ondertekent de attestatie, voegt het bij als een OCI-artefact naast de containerimage en pusht de handtekening naar het Rekor-transparantielogboek.

Het SLSA-framework (Supply-chain Levels for Software Artifacts) is het volwassenheidsmodel waarnaar defensieklanten verwijzen wanneer ze een enkel getal willen om hun vereisten op te baseren. SLSA 1 betekent dat herkomst bestaat. SLSA 2 betekent dat het is ondertekend en dat de buildservice gehost is. SLSA 3 betekent dat de build geГЇsoleerd is en de herkomst niet vervalsbaar is door het project zelf. SLSA 4 betekent twee-partijen-review en hermetische, reproduceerbare builds. De meeste defensiecontracten in 2026 vragen om SLSA 3 als vloer voor software geleverd aan operationele omgevingen; SLSA 2 is acceptabel voor niet-geГЇmplementeerde tooling. SLSA 4 blijft zeldzaam buiten de hoogst geclassificeerde workloads.

5. Kwetsbaarheids-correlatielaag

Een SBOM is een lijst van componenten; het is op zichzelf geen kwetsbaarheidsrapport. De correlatielaag koppelt de SBOM aan kwetsbaarheidsdatabases (NVD, OSV, GitHub Advisory Database) om een kwetsbaarheidslijst per artefact te produceren. Dit is waar de meeste teams ontdekken dat 80% van de gerapporteerde kwetsbaarheden in hun SBOM niet exploiteerbaar zijn in hun context — de kwetsbare functie wordt nooit aangeroepen, de betreffende configuratie is nooit ingeschakeld, of het pad is onbereikbaar vanuit elk extern oppervlak.

De gestandaardiseerde manier om dit te communiceren is VEX (Vulnerability Exploitability eXchange). Een VEX-verklaring declareert, voor een specifieke CVE tegen een specifieke productversie, een van vier statuswaarden: not_affected, affected, fixed of under_investigation, met een rechtvaardiging (bijv. vulnerable_code_not_in_execute_path). CycloneDX ondersteunt VEX native; SPDX ondersteunt het via het CSAF-begeleidingsformaat (Common Security Advisory Framework). Een defensieklant die uw SBOM beoordeelt, verwacht VEX-verklaringen te zien die de open CVE's verklaren — geen stilte.

De operationele workflow ziet er als volgt uit: SBOM gegenereerd in build в†’ kwetsbaarheidsscan tegen OSV/NVD в†’ triage in een tool zoals Dependency-Track в†’ ingenieur dient VEX-verklaring in met rechtvaardiging в†’ VEX bijgevoegd als ondertekende in-toto-attestatie naast de SBOM. De auditor van de klant ziet een coherent verhaal voor elke CVE.

6. CI Gate-logica

SBOM's en VEX-verklaringen handhaven alleen toeleveringsketen-hygiГ«ne wanneer de pipeline erop blokkeert. De gate zit tussen "build geslaagd" en "release-artefact gepromoveerd." Moderne teams schrijven de gate als een beleid in Rego (Open Policy Agent) of Kyverno, geГ«valueerd tegen de SBOM- en VEX-invoeren.

Een werkbaar beleid handhaaft vier regels. Één: geen kritieke CVE's zonder VEX-rechtvaardiging. Twee: geen componenten van een denylist van licentiefamilies (AGPL in propriëtaire leveringen, alles met een door de VS exportgecontroleerde oorsprongsclausule). Drie: geen componenten van sanctie-landregistries (dit is waar NDAA 1655 thuishoort — pakketten van Chinese oorsprong automatisch gemarkeerd). Vier: de SBOM moet zijn ondertekend, de build-herkomst moet SLSA 3 of hoger claimen, en het Rekor-transparantielogboekinvoer moet bestaan.

Ontheffingen zijn de plek waar de meeste beleidsregels in de praktijk falen. Een algemene "negeer deze CVE voor altijd"-override is het auditfaalpatroon. Het patroon dat audits doorstaat is ontheffing met rechtvaardiging en vervaldatum: het ontheffingsbestand leeft in de repo, wordt beoordeeld in een pull request, noemt de CVE en het artefact, bevat een geschreven rechtvaardiging (dezelfde VEX-rechtvaardigingsvelden) en heeft een vervaldatum. De pipeline accepteert de ontheffing alleen zolang ze niet verlopen is. Auditors houden van dit patroon omdat het een schriftelijk spoor van risicobesluiten produceert; ingenieurs tolereren het omdat het eindig werk is.

7. Klantlevering

De SBOM is niet alleen een build-artefact — het is een contractleverbaarheid. Defensiecontracten in 2026 bevatten routinematig clausules over SBOM-formaat, ondertekening, leveringsmechanisme en update-cadans. Formatonderhandeling vindt doorgaans plaats bij contractopstelling: de leverancier stelt CycloneDX 1.5 JSON voor, de klant counters met SPDX 2.3 omdat zijn downstream-tool dat vereist, en de leverancier verbindt zich tot dubbele uitvoer. Levering is gewoonlijk via een door de klant beheerd register of portaal — nooit e-mailbijlagen, die het informatiebeleid van de klant verbiedt.

De periodieke update-verplichting is de clausule die de meeste leveranciers onderschatten. NDAA-afgestemde contracten vereisen doorgaans een bijgewerkte SBOM bij elke patchrelease, elke kwartaalonderhoudsaanlevering en binnen 72 uur na elke relevante CVE-publicatie. Als uw releaseproces een week duurt, kunt u een 72-uur-klok niet halen. De oplossing is SBOM-uitvoer automatisch te maken bij elke release, inclusief patchreleases, zodat de SBOM altijd actueel is met de binaire module die de klant uitvoert. Leveranciers die proberen SBOM's handmatig na release te regenereren, eindigen met het uitleggen van hiaten aan accreditatiebeoordelaars — zie ook hoe veiligheidsmachtiging en personeelsbeperkingen beïnvloeden wat uw team kan leveren.

8. Audit Doorstaan

De accreditatiebeoordeler arriveert. Ze stellen drie vragen. Laat me de SBOM zien voor versie 2.4.1, die we in productie draaien. Uw register retourneert het ondertekende CycloneDX-document met een in-toto-attestatie die verwijst naar de binaire hash die de klant heeft geГЇnstalleerd. Laat me de VEX-verklaringen zien voor elke "hoge" CVE in die SBOM. Uw register retourneert het VEX-bundel, met rechtvaardigingen en datums. Laat me zien hoe u vandaag zou weten of een nieuwe CVE werd gepubliceerd voor een component in deze SBOM. U toont hen de continue scan die wordt uitgevoerd op het SBOM-corpus en de SLA voor klantmelding.

De pipeline die die drie vragen helder beantwoordt, is de pipeline die de audit doorstaat. De pipeline die dat niet kan — omdat de SBOM achteraf werd gegenereerd, of de VEX-verklaringen in een spreadsheet leven, of niemand CVE-publicaties bijhoudt tegen gepubliceerde SBOM's — is de pipeline die het contract verliest bij verlenging. De investering is eindig; de gevolgen van het niet doen zijn dat niet. Voor het bredere toeleveringsketenkader, zie ons SBOM in defensiesoftware-overzicht, de complete gids voor defensie-cyberbeveiliging en de DevSecOps + zero trust-diepgaande analyse die één laag boven dit pipeline-werk zit.