Software Bill of Materials (SBOM) voor Defensie: Wat Inkoop Nu Vereist

Een Software Bill of Materials (SBOM) is een machine-leesbare inventaris van alle softwarecomponenten, bibliotheken en afhankelijkheden waaruit een softwareproduct bestaat. Het is in wezen het softwaregegeven van een fysieke productiestuklijst: een gestructureerde lijst van elk ingrediënt dat in het eindproduct is gegaan, inclusief de versie van elk component en de bekende kwetsbaarheden die aan elke versie zijn gekoppeld op het moment van levering.

SBOM-vereisten in defensie-inkoop zijn niet langer opkomend — ze zijn aanwezig. US Executive Order 14028 (mei 2021) vereiste SBOM-levering voor software verkocht aan de federale overheid. De DoD Software Modernization Strategy verwijst naar SBOM als een vereiste voor toeleveringsketenbeveiliging. De EU Cyber Resilience Act (CRA), die in 2024 van kracht werd, zal SBOM's vereisen voor producten met digitale elementen die op de EU-markt worden verkocht — dit omvat een breed scala aan defensie-aangrenzende producten. Defensiesoftwareleveranciers die geen conforme SBOM's kunnen produceren, worden gediskwalificeerd voor inkoopkansen.

Wat een SBOM Is: Machine-leesbare Componentinventaris

Een SBOM somt elk softwarecomponent op dat is opgenomen in een softwareproduct, hetzij direct (een bibliotheek die het ontwikkelteam expliciet als afhankelijkheid heeft toegevoegd) hetzij transitief (een bibliotheek waarvan een van die directe afhankelijkheden zelf afhankelijk is). Voor een moderne softwareapplicatie gebouwd met standaard open-source componenten bevat de transitieve afhankelijkheidsboom doorgaans honderden tot duizenden componenten — veel te veel om handmatig bij te houden.

De NTIA (National Telecommunications and Information Administration) minimumelementen voor een SBOM definiëren wat elk componentitem moet bevatten: de naam van de componentleverancier, de componentnaam, de componentversie, andere unieke identificatoren (pakket-URL of hash), de afhankelijkheidsrelatie (hoe het component past in de bredere componentboom), de auteur van de SBOM-data en een tijdstempel.

De operationele waarde van een SBOM is het gebruik ervan voor kwetsbaarheidsbeheer. Wanneer een nieuwe kritieke kwetsbaarheid wordt bekendgemaakt — Log4Shell (CVE-2021-44228) is het canonieke voorbeeld — kan een organisatie met SBOM's voor al haar geïmplementeerde software onmiddellijk die SBOM's bevragen om te identificeren welke systemen Log4j bevatten en op welke versie, waarbij herstel wordt geprioriteerd. Een organisatie zonder SBOM's moet elk systeem handmatig onderzoeken, wat in een grote defensieomgeving weken kan duren en kritieke systemen tussentijds ongepatcht laat.

Regelgevende Drivers: EO 14028, NTIA en EU Cyber Resilience Act

US Executive Order 14028 (Verbetering van de Nationale Cyberbeveiliging) werd ondertekend in mei 2021 na de SolarWinds-toeleveringsketenaanval, die aantoonde hoe een enkele gecompromitteerde software-updatepijplijn duizenden stroomafwaartse organisaties kon compromitteren, waaronder meerdere federale instanties. Sectie 4 van het bevel vereist specifiek dat softwareleveranciers die aan de federale overheid verkopen SBOM's leveren. OMB-richtlijnen die EO 14028 implementeren hebben de SBOM-vereisten voor federale aannemers progressief aangescherpt.

NTIA minimumelementen (gepubliceerd juni 2021) bieden de basisstandaard voor wat een conforme SBOM vormt. Deze elementen zijn het minimum — contracten kunnen aanvullende vereisten specificeren zoals specifieke SBOM-formaten, opname van transitieve afhankelijkheden tot een bepaalde diepte, of integratie met kwetsbaarheidsbeheerssystemen.

De EU Cyber Resilience Act is van toepassing op producten met digitale elementen die op de EU-markt worden gebracht. Producten in de "belangrijke" en "kritieke" categorieën (inclusief veel defensie-aangrenzende hardware- en softwareproducten) worden geconfronteerd met verplichte conformiteitsbeoordelingen door derden. Hoewel de CRA niet in alle gevallen expliciet SBOM's vereist, worden de essentiële cyberbeveiligingsvereisten die het definieert — kwetsbaarheidsverwerking, beveiligingsupdates, openbaarmaking van beveiligingsrelevante componentinformatie — het meest praktisch vervuld via SBOM-generatie en -onderhoud. EU-defensieprogramma's en producten die op EU-markten worden verkocht, moeten plannen voor SBOM-vereisten als onderdeel van CRA-naleving.

SBOM-formaten: SPDX vs CycloneDX

Twee formaten domineren het SBOM-ecosysteem: SPDX en CycloneDX. Beide zijn open standaarden, beide zijn machine-leesbaar en beide kunnen dezelfde onderliggende componentdata weergeven. De keuze tussen hen is primair een functie van toolondersteuning en nadruk van het gebruiksgeval.

SPDX (Software Package Data Exchange) is een ISO-standaard (ISO/IEC 5962:2021). Het werd oorspronkelijk ontwikkeld door de Linux Foundation en heeft de diepste wortels in de open-source licentiecompliancegemeenschap — SPDX begon als een licentievolgformaat en werd uitgebreid om beveiligingsgebruiksscenario's te omvatten. SPDX wordt ondersteund door een breed scala aan tools en heeft sterke integratie met de NTIA-minimumelementenspecificatie. SPDX-documenten kunnen worden geserialiseerd als tag-waarde, JSON, YAML of RDF-XML.

CycloneDX is een OWASP-standaard die specifiek voor beveiligingsgebruiksscenario's is ontworpen van meet af aan. CycloneDX heeft sterkere ondersteuning voor kwetsbaarheidsdata-integratie (VEX-documenten, hieronder beschreven), ondersteunt aanvullende artefacttypes (services, hardware, machine-leermodellen) en heeft een actiever tool-ecosysteem specifiek gericht op DevSecOps-workflows. CycloneDX wordt geserialiseerd als JSON of XML.

Voor defensieprogramma's is de praktische richtlijn: beide formaten zijn acceptabel onder huidige US SBOM-richtlijnen; verifieer de specifieke formaatsvereisten in uw contract en programmaDocumentatie; genereer beide als toolondersteuning dat toestaat (Syft, hieronder beschreven, genereert beide); en zorg ervoor dat uw SBOM-beheerplatform het formaat dat u produceert kan consumeren.

SBOM-generatie in CI/CD: Syft en cdxgen

Syft (van Anchore) is de toonaangevende open-source SBOM-generatietool voor containerafbeeldingen en bestandssystemen. Het ondersteunt zowel SPDX- als CycloneDX-uitvoerformaten en verwerkt een breed scala aan pakketecosystemen: npm, PyPI, Maven/Gradle, NuGet, Go-modules, RubyGems, Cargo, Alpine APK, Debian/Ubuntu DPKG en RPM. In een CI/CD-pijplijn wordt Syft uitgevoerd als een bouwfasestap nadat de containerafbeelding is gebouwd maar voordat deze naar het register wordt gepusht, waarbij een SBOM wordt gegenereerd die als bouwartefact naast de afbeelding wordt gepubliceerd.

cdxgen is de OWASP-onderhouden CycloneDX-generatietool, met bijzonder sterke ondersteuning voor polyglot-repositories (repositories die code in meerdere talen bevatten). cdxgen doorloopt de afhankelijkheidsmanifesten van meerdere pakketbeheerders tegelijkertijd en produceert een uniforme CycloneDX SBOM die alle componenten over alle taalecosystemen in de repository dekt. Dit is bijzonder relevant voor defensiesoftwareprojecten die bijvoorbeeld een Python-backend combineren met een TypeScript-frontend en Java-middleware.

VEX: Vulnerability Exploitability eXchange

Een SBOM vertelt u welke componenten aanwezig zijn. Een VEX (Vulnerability Exploitability eXchange)-document vertelt u of de kwetsbaarheden in die componenten daadwerkelijk exploiteerbaar zijn in de specifieke productcontext. Het onderscheid is belangrijk omdat software-compositie-analyse doorgaans lange lijsten CVE's produceert in transitieve afhankelijkheden die niet daadwerkelijk exploiteerbaar zijn: het kwetsbare codepad is niet bereikbaar in de applicatie, het kwetsbare component wordt gebruikt in een testgerichte context, of de configuratie die de kwetsbaarheid mogelijk maakt is niet aanwezig in het geïmplementeerde product.

VEX-statussen voor elk CVE-componentpaar zijn: "getroffen" (de kwetsbaarheid is aanwezig en exploiteerbaar), "niet getroffen" (de kwetsbaarheid bestaat in het component maar is niet exploiteerbaar in dit product), "opgelost" (een herstelde versie is beschikbaar en geïmplementeerd), of "onder onderzoek" (exploiteerbaarheid is nog niet vastgesteld). Defensie-inkoopcontracten vereisen steeds vaker zowel een SBOM als een VEX-document als een complete toeleveringsketenbeveiliging-levering. CISA heeft richtlijnen gepubliceerd over VEX-formaten en minimaal vereiste inhoud.