Een Software Bill of Materials (SBOM) is een gestructureerde, machine-leesbare inventarislijst van alle softwarecomponenten, bibliotheken en afhankelijkheden waaruit een softwareproduct is opgebouwd, inclusief versienummers, licenties en herkomstinformatie. Voor organisaties die kiezen voor soevereine cloud- of on-premise IT-omgevingen, is de SBOM niet langer een vrijblijvende best practice: de Europese Cyber Resilience Act (CRA) maakt het een juridische verplichting voor fabrikanten, en NIS-2 maakt het een logisch instrument voor inkopers.
Wat de Cyber Resilience Act concreet vereist van softwarefabrikanten
De CRA (Verordening (EU) 2024/2847) verplicht fabrikanten van producten met digitale elementen om een SBOM op te stellen die minimaal de top-level afhankelijkheden van het product dekt. Artikel 13, lid 3 stelt dit expliciet: fabrikanten moeten de SBOM beschikbaar houden en op verzoek kunnen overleggen aan markttoezichthouders.
De CRA maakt onderscheid tussen standaard digitale producten en kritieke producten (klasse I en II, zoals industriële firewalls, besturingssystemen voor servers en PKI-software). Voor klasse I-producten is een conformiteitsbeoordeling door een notified body verplicht; voor alle categorieën geldt de SBOM-plicht. De CRA treedt gefaseerd in werking: de meeste verplichtingen zijn van toepassing vanaf december 2027, maar fabrikanten doen er goed aan hun SBOM-processen nu te bouwen.
De verordening verplicht fabrikanten daarnaast tot actieve kwetsbaarheidsbewaking: bekende kwetsbaarheden (CVE’s) moeten worden bijgehouden, gedocumenteerd en binnen gedefinieerde termijnen gepatcht. Een actuele SBOM is de technische basis voor die bewaking, omdat je zonder componentenlijst niet systematisch kunt controleren of een nieuw gepubliceerde CVE betrekking heeft op jouw product.
CycloneDX en SPDX: de twee dominante SBOM-formaten
De CRA schrijft geen specifiek bestandsformaat voor, maar de praktijk en de ENISA SBOM minimum viable guidelines wijzen duidelijk in de richting van twee machine-leesbare standaarden.
| Formaat | Beheerder | Primaire focus | ISO-normering | Tooling-ondersteuning |
|---|---|---|---|---|
| CycloneDX | OWASP | Beveiligingsanalyse, VEX (kwetsbaarheidsverklaringen) | Nee (eigen OWASP-standaard) | Breed, inclusief Syft, Trivy, Dependency-Track |
| SPDX (Software Package Data Exchange) | Linux Foundation | Licentie-compliance, herkomst | ISO/IEC 5962:2021 | Breed, inclusief SPDX-tools, Fossology, Tern |
Voor Europese overheidsorganisaties en gereguleerde sectoren is het aanbevolen om beide formaten te genereren: CycloneDX voor operationele kwetsbaarheidsanalyse via tools als OWASP Dependency-Track, en SPDX voor licentie-auditdossiers en inkoopdocumentatie. Moderne pipelines zoals Syft kunnen beide formaten simultaan uitvoeren vanuit dezelfde bronanalyse.
Een SBOM opstellen voor Nextcloud en open-source werkplekoplossingen
Open-source werkplekoplossingen zoals Nextcloud bestaan uit een kern plus een ecosysteem van apps en externe bibliotheken, waarvan een deel door derden wordt beheerd. De Nextcloud open-source component registry biedt een startpunt voor het identificeren van officieel ondersteunde apps en hun afhankelijkheden, maar een volledige SBOM vereist geautomatiseerde analyse van de volledige softwareketen.
Praktische stappen voor SBOM-generatie
De meest betrouwbare aanpak combineert drie methoden. Ten eerste: statische analyse van de broncode en pakketmanifesten (composer.json voor PHP, package.json voor JavaScript), uitgevoerd door tools als Syft of CycloneDX-php. Ten tweede: containerlaaganalyse als Nextcloud draait in Docker of Kubernetes, waarbij tools als Trivy of Grype elke containerlaag inspecteren. Ten derde: runtime-inventarisatie, die componenten vastlegt die alleen dynamisch worden geladen.
Het resultaat is een geneste SBOM: een top-level document voor Nextcloud Hub zelf, met verwijzingen naar SBOM-documenten per app of integratie. Dit sluit aan op de aanbeveling in de ENISA minimum viable guidelines om afhankelijkheden tracebaar te houden tot op componentniveau.
SBOM-analyse voor jurisdictierisico’s en kwetsbaarheden
Een van de meest onderschatte toepassingen van de SBOM is jurisdictieanalyse: het in kaart brengen welke componenten worden beheerd door rechtspersonen die vallen onder wetgeving met extraterritoriale werking, zoals de Amerikaanse CLOUD Act of de Foreign Intelligence Surveillance Act (FISA).
De methodiek is als volgt: koppel elk component in de SBOM aan de rechtspersoon die het beheert (via de purl-identificator en packagehome-URL), zoek vervolgens de vestigingsplaats en juridische structuur van die rechtspersoon op, en classificeer het jurisdictierisico. Componenten die worden beheerd door entiteiten met Amerikaanse aandeelhouders of Amerikaanse rechtsvorm verdienen extra aandacht, ook als ze open-source zijn, omdat de Amerikaanse overheid in principe toegang kan eisen tot data die die entiteit verwerkt of controleert.
Parallel daaraan gebruik je de SBOM voor CVE-analyse: door de componentversies te koppelen aan de National Vulnerability Database (NVD) of OSV (Open Source Vulnerabilities) identificeer je welke van jouw productiecomponenten een bekende kwetsbaarheid dragen. Tools als OWASP Dependency-Track automatiseren deze koppeling en genereren dashboards per risicoscore.
Statistisch onderstreept onderzoek de urgentie: 96% van alle geauditeerde codebases bevat open-source componenten, en 84% van die codebases bevat minstens één kwetsbaarheid met een hoog of kritisch risico (Synopsys Open Source Security and Risk Analysis Report, 2023). Zonder SBOM is systematische detectie van die kwetsbaarheden in een samengestelde werkplekoplossing vrijwel onmogelijk.
De gemiddelde wereldwijde kostprijs van een datalek bedroeg in 2023 4,45 miljoen US dollar (IBM Cost of a Data Breach Report, 2023). Organisaties in de overheids- en rechtssector dragen bovendien reputatierisico’s die in geen enkel financieel model volledig worden gevangen.
SBOM-beheer integreren in inkoop en leveranciersbeoordeling
NIS-2 artikel 21 lid 2 sub e verplicht essentiële en belangrijke entiteiten tot het beheersen van beveiligingsrisico’s in de toeleveringsketen. De SBOM is het meest directe instrument om die verplichting operationeel te maken bij softwareinkoop.
Eisen aan leveranciers vastleggen in contracten
Neem in aanbestedingsdocumenten en contracten minimaal de volgende eisen op: de leverancier levert bij elke release een actuele SBOM in CycloneDX- of SPDX-formaat; de leverancier rapporteert binnen 24 uur na publicatie van een kritieke CVE die betrekking heeft op een component in de SBOM; en de leverancier documenteert de juridische vestigingsplaats van de beheerders van alle top-level afhankelijkheden.
Voor organisaties die werken met de CADA-soevereiniteitscriteria (het Franse kader voor cloud-inkoopsoevereiniteit, inmiddels een referentiepunt voor meerdere EU-lidstaten) is de SBOM aanvullend een instrument om te toetsen of leveranciers daadwerkelijk vrij zijn van niet-Europese juridische onderwerpelijkheid. Een SBOM die componenten bevat van leveranciers met Amerikaanse rechtsvorm kan duiden op een soevereiniteitsrisico dat contractueel moet worden geadresseerd.
Periodieke herbeoordeling en continue monitoring
Leveranciersbeoordeling onder NIS-2 is geen eenmalige exercitie. Bouw een kwartaalcyclus in waarbij de leverancier een bijgewerkte SBOM aanlevert, jij die analyseert op nieuwe CVE’s en jurisdictiewijzigingen, en het resultaat wordt gedocumenteerd in het informatiebeveiligingsdossier. OWASP Dependency-Track ondersteunt automatische ingestion van SBOM-bestanden en verstuurt alerts bij nieuwe kwetsbaarheden, waardoor de periodiciteit van handmatige reviews kan worden beperkt tot strategische beoordelingsmomenten.
De NTIA heeft het belang van de SBOM voor supply chain risk management bondig geformuleerd: “A software bill of materials is a key building block in software security and software supply chain risk management.” De CRA vertaalt die stelling naar een rechtstreekse verplichting: “Manufacturers must draw up a software bill of materials covering at minimum the top-level dependencies of the product with digital elements” (artikel 13, lid 3, Verordening (EU) 2024/2847).
Soevereine cloud en de samenhang met GDPR en NIS-2
De SBOM is geen doel op zichzelf. Binnen een soevereine IT-strategie vormt het de technische onderbouwing van drie bredere verplichtingen: GDPR-artikel 32 (passende technische maatregelen), NIS-2 artikel 21 (toeleveringsketenbeheer) en de aanstaande CRA-conformiteit. Organisaties in de overheid, juridische sector en andere gereguleerde sectoren die migreren van een hyperscaler-gebaseerde omgeving naar een Europese of on-premise werkplek, doen er goed aan de SBOM-verplichting te behandelen als onderdeel van de migratiechecklist: niet als nalevingsformaliteit achteraf, maar als instrument waarmee je de veiligheid en soevereiniteit van de nieuwe omgeving aantoonbaar onderbouwt.
FAQ: SBOM, soevereine cloud en de Cyber Resilience Act
Is een SBOM verplicht voor alle softwareproducten onder de Cyber Resilience Act?
De CRA verplicht fabrikanten van producten met digitale elementen tot het opstellen van een SBOM die minimaal de top-level afhankelijkheden dekt. Voor kritieke producten (klasse I en II) gelden zwaardere conformiteitseisen, maar de SBOM-plicht zelf is breed van toepassing op alle categorieën die onder de werkingssfeer van de verordening vallen.
Welk SBOM-formaat moet ik gebruiken: CycloneDX of SPDX?
De CRA schrijft geen specifiek formaat voor. Zowel CycloneDX (beheerd door OWASP) als SPDX (beheerd door de Linux Foundation, genormeerd als ISO/IEC 5962:2021) zijn breed ondersteund en voldoen aan de eis van machine-leesbaarheid. Veel organisaties genereren beide formaten tegelijk: CycloneDX voor beveiligingsanalyse, SPDX voor licentiedocumentatie.
Hoe helpt een SBOM bij het beoordelen van jurisdictierisico’s?
Door de herkomst van elk component te koppelen aan de rechtspersoon van de ontwikkelaar, kun je vaststellen welke componenten worden beheerd door entiteiten die vallen onder de Amerikaanse CLOUD Act of FISA. Dat maakt gerichte risicobeperking mogelijk, bijvoorbeeld door vervanging door Europees beheerde alternatieven of door contractuele waarborgen te eisen.
Wat moet ik als inkoper vragen aan een leverancier van een soevereine cloudoplossing?
Vraag om een actuele, machine-leesbare SBOM in CycloneDX- of SPDX-formaat, een gedocumenteerd kwetsbaarheidsbeheerproces met aantoonbare CVE-responstijden, bewijs van CRA-conformiteitsvoorbereiding, en contractuele rapportageplicht bij componenten met problematische jurisdictiebindingen.
Hoe verhoudt SBOM-beheer zich tot NIS-2 artikel 21?
NIS-2 artikel 21 lid 2 sub e verplicht essentiële en belangrijke entiteiten tot het beheersen van beveiligingsrisico’s in de toeleveringsketen. Een SBOM is een direct instrument om die verplichting in te vullen: het biedt transparantie over de softwarecomponenten van leveranciers, maakt systematische kwetsbaarheidsanalyse mogelijk en onderbouwt de risicoafweging die toezichthouders verwachten in een auditdossier.
