Een Software Bill of Materials (SBOM) is een gestructureerde, machine-leesbare inventarislijst van alle componenten, bibliotheken, afhankelijkheden en hun metadata die samen een softwareproduct vormen. Voor compliance officers en IT-beslissers in gereguleerde sectoren is de SBOM de feitelijke basis geworden voor softwaretransparantie, leveranciersrisicobeoordeling en aantoonbare naleving van de NIS-2 Richtlijn en de Cyber Resilience Act.
Wettelijk kader: wat NIS-2 en de Cyber Resilience Act vereisen
Zowel de NIS-2 Richtlijn als de Cyber Resilience Act leggen concrete verplichtingen op rond softwaretransparantie, maar met een verschillende reikwijdte en focus.
De NIS-2 Richtlijn (EU) 2022/2555, van toepassing op aanbieders van essentiële en belangrijke diensten, verplicht organisaties tot passende technische en organisatorische maatregelen voor de beveiliging van de toeleveringsketen. Artikel 21 lid 2 noemt expliciet het beheer van kwetsbaarheden en de beveiliging van softwareleveranciers als onderdeel van die verplichting. ENISA heeft in haar aanbevelingen verduidelijkt dat een SBOM een kernmaatregel is om hieraan invulling te geven, al staat het woord “SBOM” niet letterlijk in de richtlijntekst.
De Cyber Resilience Act (CRA), Verordening (EU) 2024/2847, gaat verder en maakt een SBOM expliciet verplicht voor fabrikanten van producten met digitale elementen. Bijlage I van de CRA schrijft voor dat fabrikanten een machine-leesbare SBOM moeten documenteren en beschikbaar stellen die minimaal bevat: de namen en versienummers van top-level softwarecomponenten, de directe afhankelijkheden en de bijbehorende licentie-informatie. De volledige verplichtingen treden gefaseerd in werking, met een einddatum van 2027 voor de meeste productcategorieën.
Als referentiekader voor wat een minimaal bruikbare SBOM bevat, zijn de CISA Minimum Elements for a Software Bill of Materials (gepubliceerd in 2021, geactualiseerd in 2025) het meest geciteerde basisdocument. CISA onderscheidt zeven verplichte datavelden: naam van de leverancier, naam van het component, versienummer, unieke identifier (zoals een PURL of CPE), afhankelijkheidsrelatie, auteur van de SBOM-data en tijdstempel. Organisaties in gereguleerde Europese sectoren kunnen deze lijst als contractuele checklist gebruiken bij inkoop.
SBOM-formaten: SPDX, CycloneDX en SWID vergeleken
De keuze van het SBOM-formaat bepaalt grotendeels of geautomatiseerde risicomonitoring haalbaar is in de bestaande toolchain van een organisatie.
| Formaat | Beheerder | ISO-status | VEX-ondersteuning | Geschikt voor |
|---|---|---|---|---|
| SPDX | Linux Foundation | ISO/IEC 5962:2021 | Beperkt (via koppeling) | Licentie-compliance, overheidsprocedures |
| CycloneDX | OWASP | Geen formele ISO | Ingebouwd (VEX-profiel) | Kwetsbaarheidsmonitoring, CI/CD-integratie |
| SWID | ISO/IEC 19770-2 | ISO/IEC 19770-2 | Niet van toepassing | Softwareidentificatie, aanvulling op SBOM |
CycloneDX (OWASP) heeft in de praktijk de voorkeur voor geautomatiseerde risicomonitoring in gereguleerde sectoren, omdat het formaat een ingebouwd VEX-profiel kent en breed wordt ondersteund door SAST- en SCA-tools in CI/CD-pipelines. SPDX heeft als ISO-standaard (ISO/IEC 5962:2021) formele erkenning die voordeel biedt bij Europese overheidsprocedures. SWID-tags zijn nuttig voor softwareinventarisatie, maar ongeschikt als zelfstandige SBOM omdat ze geen afhankelijkheidsrelaties vastleggen.
Voor organisaties die meerdere leveranciers aansturen, is het verstandig contractueel zowel SPDX als CycloneDX te accepteren en te vereisen dat de SBOM via een geautomatiseerde koppeling beschikbaar is in het eigen kwetsbaarheidsbeheersysteem.
Jurisdictierisico’s identificeren via SBOM-analyse
Een SBOM biedt compliance officers een concreet startpunt om de juridische herkomst van softwarecomponenten te beoordelen, iets wat met traditionele leveranciersaudits nauwelijks haalbaar is op componentniveau.
Statistisch is de urgentie duidelijk: 84% van de onderzochte softwarepakketten bevatte open source-componenten met bekende kwetsbaarheden (Synopsys Open Source Security and Risk Analysis Report 2023). Dat betekent dat praktisch elk cloudproduct een SBOM-analyse rechtvaardigt.
In de praktijk werkt een jurisdictieanalyse op basis van SBOM-data als volgt. De pakket-URL’s (PURLs) in de SBOM verwijzen naar registries zoals npm, PyPI of Maven Central. Via de maintainer-informatie in die registries, aangevuld met licentie-informatie (zoals Apache 2.0 met een Contributor License Agreement), kan een analist vaststellen of een component primair door een Amerikaanse entiteit wordt beheerd. Componenten die vallen onder de rechtsmacht van bedrijven die onderworpen zijn aan de US CLOUD Act of de Foreign Intelligence Surveillance Act kunnen vervolgens worden gemarkeerd als verhoogd risico voor organisaties die persoonsgegevens of gerubriceerde informatie verwerken.
Dit proces is niet volledig te automatiseren, maar tooling zoals DependencyTrack (open source) kan het scannen van PURLs en het koppelen aan kwetsbaarheidsdatabases grotendeels overnemen. Een compliance officer voegt dan de juridische jurisdictielaag toe op basis van de geëxporteerde componentenlijst.
“Software transparency is a prerequisite for meaningful risk assessment across the entire supply chain.” (ENISA, Recommendations for a European SBOM Study, 2023)
SBOM integreren in aanbestedingsprocedures
Voor overheidsorganisaties en gereguleerde sectoren is aanbesteding het meest effectieve moment om SBOM-vereisten juridisch afdwingbaar te maken.
In de technische specificaties van een aanbesteding (conform de Aanbestedingswet 2012 en de Europese richtlijnen 2014/24/EU en 2014/25/EU) kunnen minimumeisen worden opgenomen die de leverancier verplichten tot:
- Het aanleveren van een initiële SBOM bij oplevering, in CycloneDX of SPDX-formaat.
- Het bijwerken van de SBOM binnen een afgesproken termijn (bijvoorbeeld 72 uur) na elke software-update of beveiligingspatch.
- Het meesturen van een VEX-document bij elke SBOM-update die betrekking heeft op een gepubliceerde CVE in de componenten.
- Het opgeven van de geografische locatie en rechtspersoonlijkheid van de primaire maintainers van alle kritieke componenten.
Deze eisen zijn aantoonbaar haalbaar: ze sluiten aan op de CRA-verplichtingen die leveranciers sowieso moeten nakomen na 2027. Vroeg inkopen met SBOM-vereisten geeft aanbestedende diensten een concurrentievoordeel in de transitie naar soevereine software-inkoop.
SBOM en VEX: de koppeling bij incidentrespons
De waarde van een SBOM wordt pas volledig benut in combinatie met Vulnerability Exploitability eXchange (VEX)-documenten. Een SBOM zegt dat een component aanwezig is; een VEX-document zegt of een bekende kwetsbaarheid in dat component daadwerkelijk exploiteerbaar is in de specifieke configuratie van het product.
In 2023 werden meer dan 28.900 CVE’s gepubliceerd in de NIST National Vulnerability Database. Zonder VEX-data leidt dat tot een vrijwel onwerkbare hoeveelheid meldingen voor incidentresponsteams. Met VEX kan een leverancier per CVE aangeven: “not affected”, “affected”, “fixed” of “under investigation”. Dat reduceert de operationele last aanzienlijk en maakt prioritering mogelijk op basis van daadwerkelijk risico.
Voor organisaties die vallen onder NIS-2 is een snelle en gedocumenteerde incidentrespons een directe compliance-eis. De koppeling SBOM/VEX maakt het mogelijk om binnen de door NIS-2 artikel 23 voorgeschreven meldingstermijnen (24 uur voor een vroegtijdige waarschuwing, 72 uur voor een officiële melding) gefundeerd te rapporteren welke systemen zijn geraakt en welke niet.
“An SBOM is a key building block in software security and software supply chain risk management.” (CISA, SBOM overview)
De rol van ENISA bij Europese harmonisatie
ENISA, het Agentschap van de Europese Unie voor Cyberbeveiliging, speelt een centrale rol in de praktische harmonisatie van SBOM-implementatie. In de ENISA-studie over SBOM-aanbevelingen (2023) concludeerde het agentschap dat meer dan de helft van de ondervraagde softwareleveranciers nog geen volledige SBOM aan klanten kon leveren, wat de implementatiekloof aantoont tussen regelgeving en de praktijk.
ENISA werkt aan sectorspecifieke richtlijnen voor energie, gezondheidszorg en transport, sectoren die zwaar vallen onder NIS-2. Het agentschap coördineert ook de afstemming tussen de CRA-uitvoeringsbepalingen en bestaande Europese normalisatietrajecten via CEN/CENELEC. Concreet betekent dit dat de ENISA-richtlijnen voor SBOM leidend zullen zijn voor de invulling van de “state of the art”-norm in artikel 13 van de CRA.
Voor compliance officers is het raadzaam de ENISA-publicaties op enisa.europa.eu structureel te monitoren, omdat de gedetailleerde technische uitvoeringsregels onder de CRA deels via gedelegeerde handelingen worden vastgesteld en nog volop in ontwikkeling zijn.
FAQ: SBOM, NIS-2 en soevereine inkoop
Is een SBOM verplicht onder de NIS-2 Richtlijn?
NIS-2 (EU) 2022/2555 verplicht organisaties in essentiële en belangrijke sectoren tot passende beheersmaatregelen voor de beveiliging van de toeleveringsketen, inclusief software. Een SBOM staat niet als verplicht document in de richtlijntekst, maar ENISA merkt het aan als een kernmaatregel om aan die verplichting te voldoen.
Wat schrijft de Cyber Resilience Act voor over SBOM?
De Cyber Resilience Act, Verordening (EU) 2024/2847, verplicht fabrikanten van producten met digitale elementen om een machine-leesbare SBOM beschikbaar te stellen die minimaal de top-level componenten, hun versienummers en de bijbehorende licenties bevat. De volledige verplichting treedt gefaseerd in werking tot 2027.
Welk SBOM-formaat wordt aanbevolen voor gereguleerde sectoren in Europa?
CycloneDX (OWASP) en SPDX (Linux Foundation, ISO/IEC 5962:2021) zijn beide breed ondersteund. CycloneDX biedt ingebouwde VEX-ondersteuning en is daardoor praktischer voor geautomatiseerde kwetsbaarheidsmonitoring. SPDX heeft als ISO-standaard formele voorkeur in sommige overheidsprocedures. SWID-tags zijn geschikt als aanvulling voor softwareidentificatie, maar minder volledig als stand-alone SBOM.
Hoe gebruik ik een SBOM om jurisdictierisico’s van cloudsoftware te beoordelen?
Door de pakketherkomst, licenties en maintainerlocaties in een SBOM te combineren met een lookup in licentie- en jurisdictiedatabases, kun je componenten identificeren die vallen onder de Amerikaanse CLOUD Act of vergelijkbare wetgeving. Dit geeft een concrete grondslag voor een risicoafweging bij aanbesteding of contractverlenging.
Wat is het verschil tussen een SBOM en een VEX-document?
Een SBOM beschrijft welke componenten in software aanwezig zijn. Een VEX-document geeft aan of een specifieke bekende kwetsbaarheid in die componenten daadwerkelijk exploiteerbaar is in het betreffende product en de betreffende configuratie. Samen vormen ze de basis voor geïnformeerde incidentrespons: de SBOM toont de aanwezigheid, de VEX de relevantie.
