Een Software Bill of Materials (SBOM) is een gestructureerde, machineleesbare inventarislijst van alle componenten, bibliotheken, afhankelijkheden en metadata waaruit een softwareproduct is opgebouwd. Voor Europese organisaties in gereguleerde sectoren, zoals overheid, rechtspraak, financiële dienstverlening en zorg, is de SBOM uitgegroeid tot een onmisbaar instrument voor soevereine softwareinkoop: het maakt aantoonbaar welke componenten van welke oorsprong zijn, welke kwetsbaarheden daarin bestaan, en of een product voldoet aan Europese juridische kaders zoals de Cyber Resilience Act en NIS-2.
Waarom de SBOM centraal staat in soevereine inkoop
De SBOM is niet langer een technisch nichedocument. Het is een juridisch en compliance-instrument geworden dat aansluit op verplichtingen rond ketenverantwoordelijkheid en leveranciersrisico.
Zonder een SBOM is het voor een compliance officer onmogelijk om vast te stellen of een softwareproduct, bijvoorbeeld een Nextcloud-installatie of een on-premise werkplekoplossing, componenten bevat van leveranciers die onder Amerikaanse jurisdictie vallen. Denk aan bibliotheken van Microsoft, Amazon of Google die als dependency zijn meegeleverd, of aan analytics-SDK’s van partijen waarop de CLOUD Act van toepassing is. De SBOM maakt deze afhankelijkheden zichtbaar vóórdat het contract wordt getekend.
“A software bill of materials is a key building block in software security and software supply chain risk management.”
CISA, Cybersecurity and Infrastructure Security Agency (VS), officieel standpunt inzake SBOM-beleid (cisa.gov)
Dat dit geen theoretisch risico is, blijkt uit cijfers: volgens het ENISA Threat Landscape 2023 hield 45 procent van de cyberincidenten in 2023 verband met een kwetsbaarheid in de toeleveringsketen van software.
Minimale SBOM-elementen: CISA 2026 versus CRA artikel 13
Twee normatieve kaders bepalen wat een bruikbare SBOM minimaal moet bevatten: de CISA Minimum Elements en de Cyber Resilience Act.
De CISA Minimum Elements for a Software Bill of Materials (gepubliceerd in 2021, richttermijn voor brede adoptie 2026) schrijven zeven basisvelden voor: naam van de leverancier, naam van het component, versienummer, unieke identificator (zoals een PURL of CPE), afhankelijkheidsrelaties, auteur van de SBOM-data, en tijdstempel. Deze velden zijn het absolute minimum voor automatische kwetsbaarheidscorrelatie.
De Cyber Resilience Act (Verordening EU 2024/2847), artikel 13 gaat verder. Fabrikanten van producten met digitale elementen zijn verplicht een machineleesbare SBOM op te stellen die de traceerbaarheid van componenten waarborgt. De CRA voegt aan de CISA-basis toe: licentie-informatie per component, de cryptografische hashes voor integriteitscontrole, en documentatie van bekende kwetsbaarheden op het moment van levering.
“Fabrikanten van producten met digitale elementen moeten een machineleesbare softwarestuklijst opstellen en beschikbaar stellen om de traceerbaarheid van componenten te waarborgen.”
Europese Commissie, toelichting bij Cyber Resilience Act, artikel 13 (eur-lex.europa.eu)
| Vereist element | CISA 2026 Minimum Elements | CRA artikel 13 |
|---|---|---|
| Leveranciersnaam component | Ja | Ja |
| Componentnaam en versie | Ja | Ja |
| Unieke identificator (PURL/CPE) | Ja | Ja |
| Afhankelijkheidsrelaties | Ja | Ja |
| Tijdstempel en auteur | Ja | Ja |
| Licentie-informatie | Niet verplicht | Ja |
| Cryptografische hash (integriteit) | Niet verplicht | Ja |
| Bekende kwetsbaarheden bij levering | Niet verplicht | Ja |
Voor inkopers in gereguleerde sectoren is de praktische aanbeveling: eis nu al de CRA-standaard, ook bij leveranciers die formeel nog niet CRA-plichtig zijn. Dit beschermt de organisatie ook na de inwerkingtreding van de volledige verplichtingen.
CRA en NIS-2: complementaire verplichtingen
De SBOM-plicht in de CRA en de ketenverantwoordelijkheid in NIS-2 zijn geen dublures, maar werken als tandwielen in elkaar.
CRA artikel 13 adresseert de fabrikant: die moet de SBOM opstellen, actueel houden en beschikbaar stellen. NIS-2 artikel 21 adresseert de gebruikende organisatie: die moet aantoonbaar risico’s in haar toeleveringsketen beheersen, ook op het gebied van softwarecomponenten. De SBOM die de fabrikant levert, is het bewijsstuk waarmee de afnemer aan zijn eigen NIS-2-verplichtingen voldoet.
Dit betekent in de praktijk dat een overheidsinstantie of zorgorganisatie niet kan volstaan met de verklaring van een leverancier dat de software veilig is. Zij moeten de SBOM analyseren en die analyse documenteren als onderdeel van hun risicobeheer. Normatief houvast biedt hierbij NEN-EN-ISO/IEC 27036, de internationale standaard voor informatiebeveiliging in leveranciersrelaties, die concrete eisen stelt aan contractuele afspraken, auditrechten en doorlopende monitoring van leveranciersrisico’s.
Hoe een compliance officer een SBOM analyseert op jurisdictierisico
Het gebruik van een SBOM als juridisch controle-instrument vereist een gestructureerde aanpak, niet alleen technische kennis.
De eerste stap is het identificeren van de herkomst van elke component. Bij een Nextcloud-installatie gaat het dan niet alleen om de Nextcloud-kern zelf (open source, Europese beheerorganisatie), maar ook om PHP-bibliotheken, JavaScript-pakketten en eventuele integraties. Een compliance officer checkt voor elk component de juridische entiteit achter de oorspronkelijke ontwikkeling: is dat een Amerikaans bedrijf, een Chinese entiteit, of een Europese stichting of overheidsinstelling?
De tweede stap is het koppelen van componenten aan bekende kwetsbaarheidsdatabases. Dit kan via de NVD (National Vulnerability Database) van NIST of via Europese alternatieven zoals de ENISA-kwetsbaarheidsdatabank. De PURL of CPE in de SBOM is de sleutel voor automatische correlatie.
De derde stap is het beoordelen van VEX-documenten (Vulnerability Exploitability eXchange). Een VEX-document is een aanvulling op de SBOM waarin de leverancier aangeeft welke bekende kwetsbaarheden wel of niet exploiteerbaar zijn in de specifieke context van het product. Dit voorkomt vals-positieve meldingen bij geautomatiseerde scans en maakt prioritering mogelijk.
Statistisch gezien is dit geen overbodige luxe: het Synopsys Open Source Security and Risk Analysis Report 2023 toont aan dat 84 procent van de geanalyseerde codebases minstens één bekende kwetsbaarheid bevat in open-source componenten. Bovendien bevat vier op de vijf codebases een kwetsbaarheid die meer dan vier jaar oud is (Synopsys OSSRA 2024).
Praktische stappen voor een SBOM-ontvangst- en analyseproces
Een werkend SBOM-proces bij inkoop omvat meerdere fasen, van contractvoorbereiding tot doorlopend beheer.
Fase 1: inkoopbeleid en contracteisen. Verankert de SBOM-eis in het inkoopbeleid. Formuleer expliciet dat alle softwareleveranciers een SBOM moeten aanleveren in een geaccepteerd formaat (CycloneDX of SPDX), bij initiële levering en bij elke relevante update. Leg de minimale velden vast conform CRA artikel 13.
Fase 2: ontvangst en validatie. Stel een technisch validatieproces in dat controleert of de ontvangen SBOM de vereiste velden bevat, machineleesbaar is, en voldoet aan het opgegeven formaat. Tools als OWASP Dependency-Track (open source, zelf te hosten) kunnen dit proces automatiseren zonder afhankelijkheid van cloud-diensten van Big Tech.
Fase 3: kwetsbaarheidscorrelatie. Laad de SBOM-data in een kwetsbaarheidsbeheertool die koppelt aan CVE-databases. Dependency-Track ondersteunt zowel CycloneDX als SPDX en biedt VEX-import. Voor soevereine organisaties is zelf hosten essentieel: de kwetsbaarheidsinformatie mag niet via een Amerikaans SaaS-platform worden verwerkt als daarin ook gegevens over de eigen infrastructuur zitten.
Fase 4: jurisdictieanalyse. Gebruik de leveranciersnamen in de SBOM om per component de juridische entiteit op te zoeken. Documenteer welke componenten onder niet-Europese jurisdictie vallen en beoordeel of dit een risico vormt voor de verwerking van bijzondere of vertrouwelijke gegevens.
Fase 5: doorlopende monitoring. Plan kwartaalchecks waarbij nieuwe SBOM-versies worden vergeleken met de vorige, en nieuwe CVE-publicaties automatisch worden gecorreleerd met de opgeslagen SBOM-data.
Geautomatiseerde tooling zonder Big Tech-afhankelijkheid
Voor soevereine organisaties is de keuze van tooling zelf een soevereiniteitsafweging. De meest gebruikte open-source tools voor SBOM-beheer zijn zelf te hosten en vereisen geen licenties van Amerikaanse technologiebedrijven.
OWASP Dependency-Track is de meest volwassen open-source oplossing voor SBOM-ingestie en kwetsbaarheidscorrelatie. Het ondersteunt CycloneDX en SPDX, integreert met de NVD en kan VEX-documenten verwerken. De tool is te draaien op eigen infrastructuur of op een Europese private cloud.
Syft (van Anchore, open source) genereert SBOM’s uit container-images en bestandssystemen en exporteert naar zowel CycloneDX als SPDX. Grype, eveneens van Anchore, koppelt de gegenereerde SBOM aan kwetsbaarheidsdatabases zonder dat data naar externe servers wordt gestuurd.
Voor organisaties die migreren van Microsoft 365 naar een soevereine Nextcloud-werkplaats, bieden deze tools de mogelijkheid om bij elke Nextcloud-update automatisch een nieuwe SBOM te genereren, te valideren en te corrigeren met de reeds opgeslagen basislijn.
SBOM-eisen in verwerkersovereenkomsten en inkoopcontracten
De SBOM-eis hoort in twee contractuele documenten thuis: het inkoopcontract (of de raamovereenkomst) en een aparte Security Annex.
In het inkoopcontract worden de leverplicht, het formaat, de versie en de frequentie van SBOM-aanlevering vastgelegd. Voeg een bepaling toe die de leverancier verplicht een bijgewerkte SBOM te leveren binnen een vastgestelde termijn (bijv. 10 werkdagen) na elke release die productiecomponenten wijzigt.
De Security Annex bevat de technische specificaties: welke SBOM-formaten worden geaccepteerd (CycloneDX 1.4 of hoger, SPDX 2.3 of hoger), welke minimale velden verplicht zijn conform CRA artikel 13, en hoe VEX-documenten worden aangeleverd bij bekende kwetsbaarheden.
In de verwerkersovereenkomst (voor software die persoonsgegevens verwerkt) kan de SBOM-eis indirect worden verankerd als onderdeel van de aantoonbaarheid van passende technische maatregelen. Verwijs in het artikel over technische en organisatorische maatregelen naar de Security Annex, zodat de verplichting ook geldt in de AVG-context.
Aanvullend schrijft NEN-EN-ISO/IEC 27036 voor dat leverancierscontracten auditrechten bevatten, zodat de afnemende organisatie periodiek kan verifiëren of de aangeleverde SBOM’s volledig en actueel zijn. Zorg dat dit auditrecht expliciet is opgenomen en niet beperkt is tot alleen de primaire leverancier, maar ook diens sub-leveranciers omvat die kritieke componenten leveren.
FAQ: SBOM en soevereine softwareinkoop
Wat is een SBOM en waarom is het relevant voor soevereine softwareinkoop?
Een SBOM (Software Bill of Materials) is een gestructureerde lijst van alle componenten, bibliotheken en afhankelijkheden waaruit een softwareproduct bestaat. Voor soevereine inkoop maakt een SBOM zichtbaar welke componenten afkomstig zijn van aanbieders onder niet-Europese jurisdictie, zodat jurisdictierisico’s aantoonbaar worden beoordeeld vóór contractsluiting.
Wanneer treedt de SBOM-verplichting uit de Cyber Resilience Act in werking?
De Cyber Resilience Act (Verordening EU 2024/2847) is gepubliceerd in 2024. De meeste fabrieksverplichtingen, waaronder artikel 13 over de SBOM, worden van toepassing 36 maanden na inwerkingtreding, wat neerkomt op eind 2027. Organisaties doen er verstandig aan deze eisen nu al te integreren in hun inkoopbeleid, zodat leveranciers de tijd hebben om te voldoen.
Wat is het verschil tussen CycloneDX en SPDX als SBOM-formaat?
SPDX (Software Package Data Exchange) is een Linux Foundation-standaard die primair is ontworpen voor licentie-compliance en is ook ISO-standaard (ISO/IEC 5962:2021). CycloneDX, beheerd door OWASP, is meer gericht op beveiligingstoepassingen en ondersteunt VEX-documenten voor kwetsbaarheidsstatus. Beide formaten zijn machineleesbaar. Voor beveiligings- en jurisdictieanalyse is CycloneDX praktisch veelzijdiger; voor licentieaudit biedt SPDX meer diepgang.
Hoe verschilt de SBOM-eis in de CRA van de ketenverantwoordelijkheid in NIS-2?
CRA artikel 13 legt de verplichting bij de fabrikant van software: die moet een SBOM opstellen en beschikbaar stellen. NIS-2 artikel 21 legt de verantwoordelijkheid bij de gebruikende organisatie: die moet aantoonbaar risico’s in haar toeleveringsketen beheersen. De SBOM van de fabrikant is daarmee het instrument waarmee de afnemer aan zijn eigen NIS-2-verplichting kan voldoen. De twee regimes vullen elkaar aan en zijn niet redundant.
Moet een SBOM-eis worden opgenomen in een verwerkersovereenkomst?
Een verwerkersovereenkomst regelt primair de verwerking van persoonsgegevens onder de AVG. SBOM-eisen horen in eerste instantie thuis in het inkoopcontract of een Security Annex. Voor software die persoonsgegevens verwerkt, kunnen SBOM-eisen indirect ook relevant zijn voor de verwerkersovereenkomst, namelijk als onderdeel van de aantoonbaarheid van passende technische maatregelen. De praktische aanbeveling is een apart Security Annex bij het contract, waarnaar de verwerkersovereenkomst verwijst.
