Een Software Bill of Materials (SBOM) is een gestructureerde, machineleesbare inventarislijst van alle softwarecomponenten, bibliotheken en afhankelijkheden waaruit een applicatie of systeem is opgebouwd, inclusief versienummers, licenties en herkomst. Onder de Cyber Resilience Act (Verordening (EU) 2024/2847) wordt de SBOM voor het eerst in Europese wetgeving verankerd als verplicht instrument voor transparantie in de softwaretoeleveringsketen. Voor compliance officers en IT-beslissers in gereguleerde sectoren is de SBOM daarmee niet langer een technische bijzaak, maar een centraal inkoopinstrument voor soevereine infrastructuur.
Wat de Cyber Resilience Act verplicht bij SBOM
De CRA legt fabrikanten van producten met digitale elementen een reeks verplichtingen op die direct raken aan de manier waarop organisaties software inkopen en beoordelen.
Verordening (EU) 2024/2847, gepubliceerd in november 2024, verplicht fabrikanten van producten met digitale elementen om een SBOM op te stellen, bij te houden en beschikbaar te stellen aan markttoezichthouders. De CRA treedt gefaseerd in werking: de meldingsverplichtingen voor actief uitgebuite kwetsbaarheden gelden per september 2026, terwijl de volledige verordening per december 2027 van toepassing is.
De minimale elementen die een CRA-conforme SBOM moet bevatten, sluiten nauw aan bij de richtsnoeren die de Amerikaanse instantie CISA in 2021 publiceerde onder de titel “Minimum Elements for an SBOM”. CISA identificeerde daarin 14 verplichte datavelden per component, waaronder componentnaam, versie, leveranciernaam, unieke identifier (bij voorkeur een PURL of CPE), afhankelijkheidsrelaties en tijdstempel van de SBOM zelf. ENISA heeft deze elementen als referentiekader overgenomen in haar eigen SBOM-publicaties.
Concreet betekent dit voor inkooporganisaties dat zij bij aanbesteding van software of SaaS-diensten contractueel moeten vastleggen dat de leverancier een actuele, machineleesbare SBOM kan aanleveren. Ontbreekt deze verplichting in het contract, dan is naleving van de CRA feitelijk onverifieerbaar.
SBOM als inkoopinstrument voor soevereine infrastructuur
Een SBOM biedt organisaties die bewust kiezen voor soevereine of Europese softwareherkomst een concreet verificatiemiddel om die keuze aantoonbaar te maken.
Zodra een SBOM beschikbaar is, kunnen inkoopteams en IT-beveiligers systematisch controleren welke derde partijen via de software toegang hebben tot de infrastructuur of verwerkte gegevens. Dit is geen theoretische oefening: veel populaire applicaties bevatten honderden transitieve afhankelijkheden, waarvan een aanzienlijk deel afkomstig is van leveranciers buiten de EU. Een SBOM maakt dit zichtbaar; zonder SBOM blijft de afhankelijkheidsketen een blinde vlek.
Bij de beoordeling van componentherkomst let je op de volgende signalen in de SBOM:
- Leveranciersnamen die gelieerd zijn aan Amerikaanse hyperscalers (Amazon, Google, Microsoft) of Chinese technologiebedrijven, ook wanneer de component als open source is gelabeld.
- Packages afkomstig van registries zoals npm, PyPI of Maven Central, waarbij de feitelijke beheerder buiten de EU is gevestigd.
- API-afhankelijkheden die bij runtime verbinding maken met externe endpoints in niet-EU-jurisdicties.
Tools als Dependency-Track (een open source platform van OWASP) kunnen SBOM-bestanden importeren en automatisch koppelen aan kwetsbaarheidsdatabases (NVD, OSV) en aan zelfgedefinieerde risicoclassificaties per leveranciersjurisdictie. Dit maakt geautomatiseerde risicobeheersing schaalbaar, ook voor organisaties met grote softwareportfolio’s.
SPDX en CycloneDX: keuze van formaat voor NIS-2-plichtige organisaties
Twee formaten domineren de SBOM-markt, elk met een eigen sterktegebied dat de keuze voor specifieke toepassingen bepaalt.
| Kenmerk | SPDX | CycloneDX |
|---|---|---|
| Standaardbeheer | Linux Foundation (ISO/IEC 5962:2021) | OWASP |
| Primaire focus | Licentiecompliance en provenance | Beveiligingsanalyse en kwetsbaarheidsbeheer |
| VEX-ondersteuning | Beperkt | Ingebouwd (CycloneDX VEX-documenten) |
| AI/ML-componenten | Beperkt | Uitgebreid (ML-BOM extensie) |
| Toolondersteuning | Breed, o.a. SPDX-tools, Syft | Breed, o.a. Dependency-Track, cdxgen |
| CRA-geschiktheid | Geschikt voor licentiedocumentatie | Geschikt voor volledige CRA-compliance |
Voor NIS-2-plichtige organisaties die SBOM-analyse willen integreren in hun bestaande beveiligingsoperaties, heeft CycloneDX een praktisch voordeel: het formaat ondersteunt Vulnerability Exploitability eXchange (VEX), waarmee leveranciers kunnen aangeven of een bekende kwetsbaarheid in hun product daadwerkelijk uitbuitbaar is. Dit vermindert het aantal valse alarmen in geautomatiseerde kwetsbaarheidsbeheersystemen aanzienlijk. NIS-2 artikel 21 vereist dat organisaties passende technische en organisatorische maatregelen nemen voor risicobeheer in de toeleveringsketen; een geautomatiseerde SBOM-analyse-pipeline is een aantoonbare invulling van die verplichting.
ENISA-bevindingen over CRA-gereedheid in Europa
De gereedheid van Europese organisaties voor CRA-conforme SBOM-processen is in 2024 en 2025 systematisch onderzocht door ENISA, met weinig bemoedigende uitkomsten.
Uit het ENISA SBOM Adoption State of Play-rapport blijkt dat minder dan 30% van de onderzochte Europese organisaties eind 2024 een operationeel SBOM-inkoopproces had. In gereguleerde sectoren zoals de gezondheidszorg, energie en overheid scoorden organisaties gemiddeld lager dan in de technologiesector, mede omdat de inkooppraktijk traditioneel gericht is op functionele eisen en prijs, niet op softwarecompositie en herkomst.
ENISA stelt hierover: “De Cyber Resilience Act is de eerste wetgeving ter wereld die fabrikanten van producten met digitale elementen verplicht om beveiligingsvereisten gedurende de volledige levenscyclus na te leven.” De implicatie is duidelijk: organisaties die nu geen SBOM-processen opbouwen, riskeren bij de inwerkingtreding van de volledige CRA per december 2027 niet alleen non-compliance bij leveranciers, maar ook een eigen handhavingsrisico op grond van NIS-2 artikel 21.
In Nederland loopt de CRA-implementatie parallel aan de NIS2-implementatiewet, die de Europese richtlijn omzet in nationaal recht. Het Nationaal Cyber Security Centrum (NCSC) heeft SBOM expliciet genoemd als instrument voor supply chain security, maar concrete handhavingspraktijk rondom SBOM-vereisten bij aanbestedingen is in 2025 nog beperkt ontwikkeld.
SBOM voor AI-software en SaaS-omgevingen
AI-systemen en SaaS-platforms stellen aanvullende eisen aan de SBOM, omdat hun afhankelijkheidsketen fundamenteel anders is dan die van traditionele software.
Een standaard SBOM documenteert bibliotheken en packages. Een AI-SBOM voegt daar de volgende lagen aan toe: de gebruikte basismodellen en modelgewichten (inclusief herkomst en trainingsdata-bronnen), inferentie-infrastructuurcomponenten, en API-koppelingen met externe diensten voor functies als embeddings, speech-to-text of content-moderatie. Dit laatste is GDPR-kritisch: wanneer een SaaS-applicatie bij elke aanroep gegevens doorstuurt naar een externe API buiten de EU, moet dit traceerbaar zijn en contractueel geborgd worden via een verwerkersovereenkomst.
CycloneDX biedt voor dit doel een ML-BOM-extensie die specifiek is ontwikkeld voor machine learning-systemen. Hiermee kunnen modelversies, datasets, evaluatiemetrics en afhankelijke inferentiediensten worden gedocumenteerd. Voor overheidsorganisaties en juridische instellingen die AI inzetten voor documentverwerking of beslissingsondersteuning, is een AI-SBOM geen luxe maar een noodzakelijke transparantiemaatregel.
Contractuele verankering en verificatie van SBOM-verplichtingen
Een SBOM-verplichting heeft alleen juridische waarde wanneer ze afdwingbaar is vastgelegd en periodiek wordt gecontroleerd.
Bij het sluiten van softwarecontracten of verwerkersovereenkomsten met cloudleveranciers neem je een SBOM-clausule op die minimaal het volgende regelt: het formaat (CycloneDX of SPDX, bij voorkeur beide), de frequentie van aanlevering (initieel bij oplevering, daarna bij elke materiële componentwijziging), de diepte van de SBOM (inclusief alle transitieve afhankelijkheden, niet alleen directe), en een auditrecht waarmee de afnemer een onafhankelijke verificatie kan laten uitvoeren.
CISA formuleert het belang hiervan als volgt: “A software bill of materials is a key building block in software security and software supply chain risk management.” Zonder contractuele verankering blijft de SBOM een vrijwillig gebaar van de leverancier dat bij de eerste versie-update al verouderd kan zijn.
Verificatie van naleving gaat verder dan het ontvangen van een bestand. De SBOM moet worden gevalideerd op volledigheid (zijn alle bekende afhankelijkheden aanwezig?), consistentie (kloppen versienummers met wat er daadwerkelijk draait?) en actualiteit (is de SBOM bijgewerkt na de laatste release?). Geautomatiseerde tooling kan hier periodieke verificatiecontroles uitvoeren, maar bij kritische systemen verdient een jaarlijkse onafhankelijke audit de voorkeur.
Praktische integratie in het inkoopproces
SBOM-vereisten werken alleen wanneer ze vroeg in het inkoopproces worden ingebouwd, niet achteraf als compliance-checkbox.
Neem SBOM-aanlevering op als eliminatiecriterium in aanbestedingsdocumenten: leveranciers die geen SBOM kunnen of willen aanleveren, kwalificeren niet. Voeg in de gunningscriteria een weging toe voor de kwaliteit van de SBOM: diepte van de afhankelijkheidsketen, gebruik van erkende formaten en aanwezigheid van VEX-documentatie. Koppel de eerste SBOM-aanlevering aan de contractuele oplevermijlpaal, zodat er geen onduidelijkheid bestaat over het moment van verplichting.
Voor organisaties die meerdere leveranciers beheren, is centralisatie in een SBOM-beheertool zoals Dependency-Track of een vergelijkbare oplossing de enige schaalbare aanpak. Dit maakt het ook mogelijk om op portfolioniveau te rapporteren aan de raad van bestuur of de toezichthouder over de stand van de softwaretoeleveringsketen, een verplichting die onder NIS-2 artikel 21 impliciet aanwezig is en onder de CRA explicieter wordt.
Veelgestelde vragen
Wanneer is een organisatie verplicht een SBOM op te vragen bij de leverancier op grond van de Cyber Resilience Act?
De Cyber Resilience Act (Verordening (EU) 2024/2847) verplicht fabrikanten van producten met digitale elementen om een SBOM beschikbaar te stellen aan markttoezichthouders. Als afnemer heb je het recht deze op te vragen bij producten die onder de CRA vallen. Organisaties in NIS-2-plichtige sectoren hebben daarnaast op grond van NIS-2 artikel 21 een zelfstandige verplichting om risico’s in de toeleveringsketen te beheersen, wat het opvragen van een SBOM in de praktijk noodzakelijk maakt.
Wat is het verschil tussen CycloneDX en SPDX en welk formaat kies je voor geautomatiseerde risicobeheersing?
SPDX is een ISO-standaard (ISO/IEC 5962:2021) die sterk gericht is op licentiedocumentatie en provenance. CycloneDX, ontwikkeld door OWASP, is breder inzetbaar voor beveiligingsanalyse, inclusief kwetsbaarheidsbeheer en VEX-documenten. Voor geautomatiseerde koppeling aan vulnerability-databases en integratieve risicobeheersing binnen een beveiligingsoperatiecentrum heeft CycloneDX in de praktijk de voorkeur. Beide formaten zijn machine-leesbaar en kunnen in combinatie worden ingezet.
Hoe detecteer je met een SBOM verborgen afhankelijkheden van niet-EU-leveranciers?
Een SBOM bevat voor elk component de naam, versie, leverancier en licentie. Door de genoemde leveranciers en packages systematisch te controleren tegen een register van bekende niet-EU-entiteiten, kun je transnationale afhankelijkheden zichtbaar maken. Tools als Dependency-Track kunnen dit proces automatiseren door SBOM-bestanden te importeren en te koppelen aan externe risicoclassificaties.
Welke SBOM-elementen zijn specifiek vereist voor AI-systemen en SaaS-platforms?
Voor AI-software voegt een AI-SBOM naast standaardcomponenten ook de gebruikte trainingsdata-bronnen, modelgewichten, inferentie-afhankelijkheden en eventuele API-koppelingen met externe diensten toe. Voor SaaS-omgevingen is het cruciaal dat de SBOM ook aangeeft welke subprocessors en derde-landsdiensten de applicatie aanroept, omdat dit directe GDPR-implicaties heeft. De CRA verplicht fabrikanten tot documentatie van de volledige afhankelijkheidsketen, wat ook voor AI-componenten geldt.
Hoe leg je SBOM-verplichtingen afdwingbaar vast in een inkoopcontract met een cloudleverancier?
Neem in de verwerkersovereenkomst of het servicecontract een expliciete clausule op die de leverancier verplicht tot periodieke aanlevering van een machineleesbare SBOM in CycloneDX of SPDX-formaat, inclusief alle transitieve afhankelijkheden. Koppel hier een auditrecht aan: de afnemer kan op verzoek een onafhankelijke verificatie laten uitvoeren. Leg bovendien vast dat de leverancier bij materiële wijzigingen in de componentenlijst binnen een bepaalde termijn een bijgewerkte SBOM aanlevert, conform de meldingslogica van de CRA.
