Een Software Bill of Materials (SBOM) is een gestructureerde, machine-leesbare lijst van alle softwarecomponenten, afhankelijkheden, licenties en versienummers waaruit een softwareproduct is opgebouwd. Met de inwerkingtreding van de Cyber Resilience Act (Verordening (EU) 2024/2847) wordt de SBOM voor het eerst een afdwingbare leveringsverplichting op de Europese markt. Voor compliance officers en IT-beslissers in overheid, juridische dienstverlening en gereguleerde sectoren is dit geen administratief detail, maar een fundamenteel inkoopinstrument bij de keuze voor soevereine cloudoplossingen.
Wat de Cyber Resilience Act precies verplicht
De CRA legt fabrikanten van producten met digitale elementen, waaronder software die als zelfstandig product op de markt wordt gebracht, de verplichting op om een SBOM beschikbaar te stellen als onderdeel van hun technische documentatie. Dit is geregeld in Bijlage I en Bijlage VII van de verordening.
Concreet betekent dit dat de SBOM minimaal de volgende elementen moet bevatten: de naam en versie van alle direct opgenomen componenten van derden, de afhankelijkheidsrelaties tussen die componenten, en verwijzingen naar bekende kwetsbaarheden via gestandaardiseerde identificatoren zoals CVE-nummers. De SBOM hoeft niet actief gepubliceerd te worden, maar moet beschikbaar zijn voor markttoezichtautoriteiten en, in geval van een beveiligingsincident, voor de betrokken partijen.
Voor on-premise werkplekoplossingen zoals Nextcloud, die als softwarepakket worden geleverd en geïnstalleerd, geldt de CRA rechtstreeks: de ontwikkelende partij is verantwoordelijk voor het opstellen en actueel houden van de SBOM bij elke nieuwe versie. Bij SaaS-diensten waarbij geen software wordt overgedragen, is de directe CRA-aansprakelijkheid beperkter, maar via NIS-2-leveranciersbeheervereisten kan een inkooporganisatie contractueel een gelijkwaardige SBOM-plicht opleggen.
CRA versus CISA Minimum Elements: welke standaard is leidend voor Europese inkopers?
Voor Europese organisaties is de CRA de juridisch bindende norm; de Amerikaanse CISA-standaard dient als technische referentie, niet als rechtsbron.
De CISA 2021 Minimum Elements for a Software Bill of Materials definiëren zeven basisvelden: leveranciersnaam, componentnaam, versie, andere unieke identifiers, afhankelijkheidsrelaties, de auteur van de SBOM-data, en een tijdstempel. Deze elementen zijn inhoudelijk grotendeels consistent met wat de CRA vereist, maar er zijn relevante verschillen.
| Kenmerk | CRA (EU) 2024/2847 | CISA Minimum Elements (VS, 2021) |
|---|---|---|
| Juridische status voor EU-inkopers | Bindend EU-recht | Niet-bindende aanbeveling |
| Koppeling aan kwetsbaarhedenbeheer | Verplicht (CVE-verwijzingen, VEX-compatible) | Aanbevolen, niet verplicht |
| Actualisatieplicht bij nieuwe versies | Ja, expliciet | Niet gespecificeerd |
| Reikwijdte | Alle producten met digitale elementen op EU-markt | Federale softwareleveranciers VS |
Een Europese inkoper die een buitenlandse leverancier beoordeelt, mag de CISA-elementen als technische checklist hanteren, maar toetst de juridische voldoening uitsluitend aan de CRA. Leveranciers die alleen aan CISA voldoen en geen aantoonbare conformiteitsdocumentatie voor de Europese markt kunnen overleggen, voldoen niet automatisch aan de CRA.
SBOM-formaten: SPDX, CycloneDX en SWID vergeleken
Drie formaten domineren de praktijk: SPDX, CycloneDX en SWID. De keuze heeft directe gevolgen voor automatische ingestie en risicoanalyse.
SPDX (Software Package Data Exchange, ISO/IEC 5962:2021) is de internationaal genormeerde standaard, ontwikkeld door de Linux Foundation. Het formaat is sterk georiënteerd op licentie-compliance en biedt uitgebreide velden voor auteursrechtinformatie. Voor beveiligingsgerichte risicoanalyse is SPDX functioneel beperkter dan CycloneDX.
CycloneDX, beheerd door OWASP, is ontworpen vanuit een beveiligingsperspectief. Het ondersteunt naast softwarecomponenten ook hardware, firmware, containers, services en, cruciaal voor PQC-migratie, een cryptographic bill of materials (CBOM). Bovendien is CycloneDX het enige formaat dat native integratie biedt met de Vulnerability Exploitability eXchange (VEX), een mechanisme waarmee leveranciers per component kunnen aangeven of een bekende CVE daadwerkelijk exploiteerbaar is in hun implementatie. Voor NIS-2-plichtige organisaties die actief kwetsbaarhedenbeheer willen voeren, is CycloneDX daarmee de meest complete keuze.
SWID-tags (ISO/IEC 19770-2) zijn primair bedoeld voor software-inventarisatie en activabeheer, niet voor beveiligingsanalyse. Ze worden soms gecombineerd met SPDX of CycloneDX maar zijn zelden leidend in een inkoop- of compliancecontext.
Hoe een inkoper de SBOM controleert op jurisdictie- en toeleveringsrisico’s
Een SBOM is pas nuttig als hij actief wordt geanalyseerd. Voor soevereine inkoop gaat die analyse verder dan kwetsbaarheden alleen: de juridische oorsprong van componenten is minstens zo relevant.
Stap 1 is het ophalen van eigendoms- en licentie-informatie per component. Veel pakketnamen in een SBOM verwijzen naar open-source projecten die worden beheerd door stichtingen (Apache, Linux Foundation, Eclipse), maar sommige componenten worden onderhouden door bedrijven met een zetel in de Verenigde Staten of China. Componenten van bedrijven die onder de US CLOUD Act (18 U.S.C. § 2713) of de Chinese Cybersecurity Law 2017 vallen, introduceren juridisch toegangsrisico dat haaks staat op de principes van datasouvereiniteit.
Stap 2 is het kruisen van de componentenlijst met kwetsbaarheidsdatabases: het CISA Known Exploited Vulnerabilities (KEV)-register en de NVD (National Vulnerability Database). Tools als Dependency-Track of OWASP’s eigen CycloneDX BOM-Tool automatiseren dit proces. Stap 3 is het opvragen van een bijgewerkt VEX-document bij de leverancier, zodat duidelijk is welke CVE’s in de specifieke implementatie daadwerkelijk exploiteerbaar zijn.
Volgens de ENISA SBOM Adoption State of Play 2024 had minder dan 25% van de onderzochte Europese organisaties een volledig SBOM-proces operationeel. Dit betekent dat de meeste inkooporganisaties nu nog reactief handelen in plaats van SBOM-analyse structureel te beleggen bij inkoop en contractbeheer.
“A software bill of materials is a foundational building block for software security and supply chain risk management. Without knowing what is in your software, you cannot know where your risks are.” (Jen Easterly, voormalig directeur CISA)
Handhavingsconsequenties bij ontbrekende of onvolledige SBOM
De CRA kent een getrapt handhavingsstelsel. Nationale markttoezichtautoriteiten kunnen bij non-conformiteit corrigerende maatregelen opleggen, inclusief een verbod op het op de markt brengen van het product. Maximale boetes bedragen 15 miljoen euro of 2,5 procent van de wereldwijde jaaromzet, afhankelijk van welk bedrag hoger is.
Voor NIS-2-plichtige organisaties als afnemende partij geldt een aanvullende verantwoordelijkheid. Richtlijn (EU) 2022/2555 verplicht essentiële en belangrijke entiteiten tot actief leveranciersrisicobeheer (Artikel 21, lid 2, sub d). Het niet kunnen overleggen van een SBOM bij een leverancier is een aantoonbaar gat in dat beheer. Bij toezicht door nationale autoriteiten, in Nederland het Nationaal Cyber Security Centrum (NCSC) en sectorale toezichthouders zoals de AFM of de NZa, kan dit worden aangemerkt als onvoldoende implementatie van NIS-2-maatregelen.
ENISA stelt hierover: “The Cyber Resilience Act gives public authorities and buyers in Europe a concrete legal lever to demand transparency about software composition. The SBOM requirement is not a bureaucratic exercise; it is a structural shift in how software accountability works.”
Praktisch gevolg voor inkoopcontracten: leg een harde SBOM-leveringsplicht vast bij initiële levering en bij elke nieuwe major release, gecombineerd met een termijn voor correctie bij onvolledigheid. Leveranciers die structureel niet kunnen voldoen, voldoen niet aan de CRA en zijn daarmee een onaanvaardbaar leveranciersrisico voor NIS-2-plichtige organisaties.
SBOM-beheer als onderdeel van cryptografische inventarisatie en PQC-migratie
De integratie van SBOM-beheer met een post-quantum cryptografie (PQC) migratieplan is een van de meest onderbenutte mogelijkheden in de huidige praktijk.
Circa 80% van de codebasis in moderne applicaties bestaat uit open-source componenten van derden (Gartner, 2023). Dit betekent dat een groot deel van de cryptografische implementaties in een organisatie niet zelfgeschreven is, maar afkomstig is van bibliotheken zoals OpenSSL, BouncyCastle of libsodium. Welke versies van die bibliotheken worden gebruikt, en welke algoritmen zij implementeren, is exact de informatie die een CBOM in CycloneDX-formaat vastlegt.
Door SBOM en CBOM te combineren ontstaat een volledig beeld: welke componenten gebruiken RSA of elliptische-curve-cryptografie die kwetsbaar is voor een cryptografisch relevante kwantumcomputer, en welke ondersteunen al PQC-algoritmen zoals CRYSTALS-Kyber (nu gestandaardiseerd als FIPS 203, ML-KEM) of CRYSTALS-Dilithium (FIPS 204, ML-DSA)? Dit maakt gerichte migratieplanning mogelijk zonder handmatige code-inventarisatie door interne ontwikkelteams.
Voor organisaties die migreren van een Microsoft 365-omgeving naar een soevereine Nextcloud-werkplek is dit bijzonder relevant: vraag de Nextcloud SBOM op, controleer de cryptografische afhankelijkheden (PHP-extensies, TLS-implementaties, authenticatiemodules) en stel vast welke componenten een PQC-upgrade vereisen als onderdeel van het migratieprogramma. Dit verbindt operationele datasouvereiniteit direct aan kwantumresiliënte infrastructuur.
FAQ
Geldt de SBOM-verplichting uit de Cyber Resilience Act ook voor SaaS-diensten zoals cloudwerkplekken?
De CRA is primair van toepassing op producten met digitale elementen die op de EU-markt worden gebracht, inclusief software. Zuivere SaaS-diensten waarbij geen software wordt overgedragen aan de gebruiker vallen buiten de directe CRA-reikwijdte, maar de leverancier van de onderliggende software (zoals Nextcloud als on-premise pakket) valt er wel onder. Inkopers kunnen contractueel een SBOM-verplichting opleggen aan SaaS-aanbieders via NIS-2-leveranciersbeheervereisten.
Wat is het verschil tussen CycloneDX en SPDX en welke kies ik als inkoper?
SPDX (ISO/IEC 5962:2021) is sterk gericht op licentie-compliance en is de ISO-genormeerde standaard. CycloneDX is ontworpen vanuit een beveiligingsperspectief en ondersteunt naast softwarecomponenten ook VEX-documenten, hardwarebeschrijvingen en cryptografische inventarisaties. Voor risicogestuurde inkoop in NIS-2-context is CycloneDX functioneel rijker. Beide formaten zijn machine-leesbaar en door de CRA impliciet aanvaard.
Wat kan een NIS-2-plichtige organisatie doen als een leverancier geen SBOM kan aanleveren?
Onder NIS-2 (Richtlijn 2022/2555) zijn essentiële en belangrijke entiteiten verplicht toeleveringsketenrisico’s te beheersen. Het ontbreken van een SBOM is een aantoonbaar tekort in leveranciersbeheer en kan bij toezicht worden aangemerkt als onvoldoende risicobeheer. Leg in inkoopcontracten een harde SBOM-leveringsplicht vast met een escalatieclausule, en overweeg leveranciers te vervangen die structureel niet kunnen voldoen.
Hoe gebruik ik een SBOM om jurisdictierisico’s van cloudcomponenten te beoordelen?
Analyseer de SBOM op de oorsprong van afhankelijkheden: kijk naar de rechtspersoon achter elk pakket, het land van inschrijving en eventuele moedermaatschappijen. Componenten van bedrijven onder de US CLOUD Act of Chinese cyberveiligheidswetgeving introduceren juridisch toegangsrisico. Gebruik tooling die SBOM-invoer koppelt aan een rechtsgebiedenregister, of voer handmatige controle uit via het CISA Known Exploited Vulnerabilities-register en de licentie- en eigendomsinformatie per component.
Hoe verbindt SBOM-beheer zich met een post-quantum cryptografie migratieplan?
CycloneDX ondersteunt een cryptographic bill of materials (CBOM), waarmee alle cryptografische algoritmen, sleutellengten en protocollen in een softwareproduct worden gedocumenteerd. Door SBOM en CBOM te combineren krijgt een organisatie een volledig beeld van welke componenten kwetsbare algoritmen gebruiken en welke al PQC-algoritmen ondersteunen. Dit maakt gerichte migratieplanning mogelijk zonder handmatige code-inventarisatie.
