Een Software Bill of Materials (SBOM) is een gestructureerde, machineleesbare inventarislijst van alle softwarecomponenten, afhankelijkheden en bibliotheken waaruit een applicatie of dienst is opgebouwd. Voor compliance officers en IT-beslissers in gereguleerde sectoren is de SBOM niet langer een optioneel instrument: de Cyber Resilience Act en NIS-2 maken SBOM-documentatie een juridische randvoorwaarde bij soevereine softwareinkoop.
Wat de Cyber Resilience Act en NIS-2 concreet eisen
De twee regelgevingskaders vullen elkaar aan, maar richten zich op verschillende actoren in de toeleveringsketen.
Cyber Resilience Act, artikel 13 verplicht fabrikanten van producten met digitale elementen een nauwkeurige en actuele SBOM bij te houden voor de gehele levensduur van het product. De SBOM moet op verzoek beschikbaar zijn voor markttoezichthouders. De CRA onderscheidt risicoklassen: voor klasse I en II geldt een strengere documentatieplicht, terwijl voor de zwaarste categorie een conformiteitsbeoordeling door een derde partij vereist is. Afnemers, zoals overheidsorganisaties of zorginstanties, kunnen via contractuele weg afdwingen dat zij de SBOM ontvangen, ook al is directe afnemersverstrekking niet expliciet verplicht in alle risicoklassen.
NIS-2 Implementing Regulation (EU) 2024/2690 vult dit aan vanuit het perspectief van de afnemende organisatie. Essentiële en belangrijke entiteiten moeten aantoonbaar leveranciersbeheer voeren, inclusief documentatie van de softwarecomponenten in kritieke systemen. De deadline voor volledige naleving ligt op 17 oktober 2027, maar toezichthouders kunnen eerder controleren op het bestaan van beleid en procedures.
Slechts 23 procent van de Europese organisaties had in 2025 een volledig geïmplementeerd SBOM-proces voor kritieke software, aldus het ENISA SBOM Adoption State of Play 2025. Dat betekent dat de meerderheid van de organisaties nu nog achterloopt op wat de regelgeving verwacht.
De minimale datavelden van CISA 2026 en de vertaling naar Nederland
CISA heeft in haar richtlijn Minimum Elements for an SBOM (2023, met een geplande actualisatie in 2026) de basisvelden vastgelegd die elke SBOM moet bevatten om bruikbaar te zijn bij incidentrespons en kwetsbaarhedenbeheer.
| CISA minimumveld | Toelichting | NIS-2-relevantie |
|---|---|---|
| Component naam | Naam van de bibliotheek of het pakket | Identificatie bij CVE-koppeling |
| Versie | Exacte versienummer, niet een bereik | Patchbeheer en meldplicht |
| Leverancier | Naam van de component-eigenaar of -auteur | Ketenbeoordeling leverancier |
| Unieke identifier | CPE, PURL of SWID | Automatische vulnerability-matching |
| Afhankelijkheidsrelaties | Directe en transitieve afhankelijkheden | Risicospreiding in keten |
| Tijdstempel | Datum van SBOM-generatie | Aantoonbaarheid actualiteit |
| SBOM-auteur | Organisatie of tool die de SBOM heeft opgesteld | Verantwoording bij audit |
NCSC-NL sluit in haar praktijkadviezen aan op de CISA-velden en voegt daar voor Nederlandse organisaties een prioritering aan toe: systemen die vallen onder de NIS-2-sectorindeling (energie, water, digitale infrastructuur, overheid) krijgen prioriteit bij SBOM-invoering. NCSC-NL benadrukt dat een SBOM zonder actuele tijdstempel praktisch waardeloos is bij een incident waarbij snel moet worden bepaald of een kwetsbare componentversie in gebruik is.
CISA stelt zelf: “A software bill of materials is a key building block in software security and software supply chain risk management. Without it, organizations cannot understand what they have deployed, let alone patch it.”
AI-SBOM: een nieuwe categorie voor lokale AI-modellen
Een AI-SBOM gaat verder dan een conventionele SBOM en vereist aanvullende documentatielagen.
Waar een reguliere SBOM softwarecomponenten en hun versies inventariseert, moet een AI-SBOM ook de volgende elementen bevatten: de herkomst en licenties van trainingsdata, de versie en bron van het modelgewicht, eventuele finetuning-stappen met de daarin gebruikte datasets, en een risicoclassificatie conform de EU AI Act. Voor organisaties die lokaal gehoste AI-modellen inzetten, bijvoorbeeld voor juridische analyse of medische besluitondersteuning, is dit onderscheid cruciaal: zij moeten kunnen aantonen dat het model niet op klantdata traint en dat de trainingsdata zelf vrij is van onrechtmatig verkregen content.
De G7-landen hebben in mei 2026 minimumprincipes voor AI-softwaretransparantie vastgesteld. Deze principes verlangen van leveranciers van AI-systemen dat zij een model card publiceren met informatie over beoogd gebruik, bekende beperkingen en de belangrijkste kenmerken van de trainingsdata. Voor inkopers van lokaal gehoste AI in een soevereine omgeving betekent dit dat de SBOM-eis in het inkoopcontract expliciet de AI-SBOM-dimensie moet adresseren, inclusief de model card als bijlage bij de verwerkersovereenkomst.
SBOM-validatie in leveranciersbeoordelingen en verwerkersovereenkomsten
Compliance officers kunnen SBOM-validatie op drie niveaus inbedden in het inkoopproces.
Inkoopfase
Neem in het Programma van Eisen een verplicht veld op voor SBOM-aanlevering in een erkend formaat, bij voorkeur CycloneDX of SPDX. CycloneDX (een OWASP-standaard) integreert rechtstreeks met vulnerability-scanners en CI/CD-pipelines, wat geautomatiseerde ingestie in een soevereine on-premise omgeving vergemakkelijkt. Vraag leveranciers aantoonbaar te maken welke tooling zij gebruiken voor SBOM-generatie en hoe zij de actualiteit bij elke release waarborgen.
Contractuele verankering
Voeg in de verwerkersovereenkomst een specifiek artikel toe dat de leverancier verplicht een actuele SBOM te leveren bij aanvang, bij elke major release en op eerste verzoek bij een incident. Koppel hieraan een auditrecht en een opschortingsclausule voor het geval de SBOM niet binnen een contractueel bepaalde termijn, doorgaans vijf werkdagen, wordt aangeleverd. NCSC-NL heeft in het kader van NIS-2-leveranciersbeheer modelformuleringen gepubliceerd die als basis kunnen dienen.
NCSC-NL stelt hierover: “Organisaties die software inkopen zonder te verifiëren welke componenten daarin zitten, nemen bewust een risico dat zij wettelijk niet meer kunnen rechtvaardigen onder de Cyberbeveiligingswet.”
Periodieke beoordeling
Plan minimaal jaarlijkse leveranciersbeoordelingen waarbij de SBOM wordt getoetst op volledigheid van de CISA-minimumvelden, afwezigheid van componenten met bekende kritieke kwetsbaarheden (CVS-score 9.0 of hoger zonder mitigatie-documentatie), en aansluiting op de eigen vulnerability-managementprocedure. Voor soevereine clouddiensten, zoals een on-premise Nextcloud-installatie, voert de eigen IT-afdeling of een vertrouwde auditor de SBOM-controle uit, zonder dat gegevens de eigen perimeter verlaten.
Open standaarden en tooling voor soevereine omgevingen
In een soevereine on-premise omgeving zijn de eisen aan SBOM-tooling anders dan in een publieke cloud: de tools zelf mogen geen telemetrie naar externe servers sturen en moeten offline kunnen opereren.
CycloneDX ondersteunt JSON- en XML-formaten en is direct bruikbaar met open-source scanners zoals Syft (van Anchore), Grype en Trivy. Deze tools draaien volledig lokaal, genereren een SBOM op basis van containerimages of broncoderepositories, en exporteren naar CycloneDX-formaat zonder cloud-afhankelijkheid. Koppeling met een lokale instantie van Dependency-Track (ook een OWASP-project) maakt continue monitoring van kwetsbaarheden mogelijk op basis van de gegenereerde SBOM.
SPDX (ISO/IEC 5962:2021) is met name geschikt wanneer naast beveiligingsrisico’s ook licentie-compliance een eis is, bijvoorbeeld bij overheidsinkoop van open-source software waarbij de licentiecompatibiliteit aantoonbaar moet zijn. SPDX en CycloneDX zijn door CISA beide erkend als geldige uitwisselingsformaten en sluiten elkaar niet uit: sommige tools genereren beide formaten gelijktijdig.
Gevolgen van ontbrekende SBOM bij incident of audit
Bij een significante cyberbeveiligingsincident geldt onder de Cyberbeveiligingswet een meldplicht van 24 uur voor de eerste melding en 72 uur voor een gedetailleerde melding. Zonder actuele SBOM is het in de praktijk onmogelijk om binnen 24 uur te bepalen welke systemen een getroffen component bevatten, wat de wettelijke meldplicht direct in gevaar brengt.
Bij een audit door het Agentschap Telecom of een sectorale toezichthouder zal het ontbreken van SBOM-documentatie worden aangemerkt als tekortkoming in het leveranciersbeheer, een van de verplichte beheersmaatregelen onder NIS-2. De toezichthouder kan een hersteltermijn opleggen, maar bij onvoldoende voortgang escaleren naar een bindende aanwijzing of bestuurlijke boete. Naast de financiële sanctie is er reputatierisico: essentiële entiteiten kunnen worden verplicht de tekortkoming openbaar te maken.
Veelgestelde vragen
Is een SBOM wettelijk verplicht voor alle software die mijn organisatie inkoopt?
Niet voor alle software tegelijk. De Cyber Resilience Act (artikel 13) verplicht fabrikanten van producten met digitale elementen tot een SBOM, maar de oplevering ervan aan afnemers is gekoppeld aan risicoklassen. NIS-2 via Implementing Regulation (EU) 2024/2690 vereist van essentiële en belangrijke entiteiten dat zij leveranciers kunnen verantwoorden, wat in de praktijk een SBOM-eis impliceert voor kritieke systemen.
Wat is het verschil tussen een SBOM in SPDX- en CycloneDX-formaat?
SPDX (ISO/IEC 5962:2021) is een ISO-standaard met nadruk op licentie-informatie en breed ingezet in juridische compliance. CycloneDX, een OWASP-standaard, is meer gericht op beveiligingsrisico’s en kwetsbaarhedenbeheer en integreert beter in CI/CD-pipelines en vulnerability-scanners. Beide zijn door CISA erkend als geldige formaten voor SBOM-uitwisseling.
Wat moet een AI-SBOM bevatten dat een gewone SBOM niet bevat?
Een AI-SBOM documenteert naast softwarecomponenten ook de trainingsdata (herkomst, licenties, datumreeks), het modelgewicht en de finetuning-stappen. De G7-principes voor AI-softwaretransparantie uit mei 2026 voegen daar eisen aan toe over model-card-informatie en risicoclassificatie. Dit is relevant voor organisaties die lokaal gehoste AI-modellen inzetten en moeten aantonen dat het model niet op klantdata traint.
Wat zijn de gevolgen als mijn leverancier geen SBOM kan aanleveren bij een incident?
Onder de Cyberbeveiligingswet kan de toezichthouder een bindende aanwijzing opleggen en bij herhaling bestuurlijke boetes tot 10 miljoen euro of 2 procent van de wereldwijde jaaromzet. Bovendien vergroot het ontbreken van een SBOM de tijd die nodig is om getroffen componenten te identificeren, wat de meldplicht van 24 uur voor significante incidenten onder druk zet.
Hoe neem ik SBOM-eisen op in een verwerkersovereenkomst?
Voeg een specifiek artikel toe dat de verwerker verplicht een actuele SBOM te leveren in SPDX- of CycloneDX-formaat bij aanvang van de overeenkomst, bij elke major release en op eerste verzoek bij een incident. Koppel hieraan een auditrecht en een opschortingsclausule als de SBOM niet binnen een redelijke termijn wordt aangeleverd. NCSC-NL heeft hiervoor modelformuleringen gepubliceerd in het kader van NIS-2-leveranciersbeheer.
