Een Software Bill of Materials (SBOM) is een gestructureerde, machineleesbare inventaris van alle componenten, bibliotheken en afhankelijkheden waaruit een softwareproduct is opgebouwd, inclusief de herkomst en versie van elk onderdeel. Met de inwerkingtreding van de Cyber Resilience Act (CRA) en de doorwerking van NIS-2 wordt de SBOM voor Europese organisaties geen technisch bijproduct meer, maar een juridisch vereist en strategisch bruikbaar instrument voor soevereine software-inkoop.
Wat de Cyber Resilience Act verplicht: artikel 13 en bijlage I
De CRA legt concrete verplichtingen op aan fabrikanten en importeurs van producten met digitale elementen, waaronder software. Op grond van artikel 13 CRA en de technische eisen in bijlage I moeten fabrikanten een SBOM opstellen en beschikbaar houden voor markttoezichthouders. De SBOM moet ten minste de gebruikte componenten van derden identificeren, inclusief hun versienummering.
De CRA maakt onderscheid tussen fabrikanten, die de volledige documentatieverplichting dragen, en importeurs, die moeten verifiëren dat een fabrikant buiten de EU aan deze eisen voldoet. Voor inkopers betekent dit dat zij bij elke softwareaanschaf kunnen eisen dat de leverancier een actuele SBOM aanlevert. Dit geldt ook voor cloudgebaseerde werkplatformen: een aanbieder die geen SBOM kan verstrekken, voldoet niet aan de CRA en plaatst de inkopende organisatie in een aantoonbare nalevingspositie.
De verbinding met NIS-2: toeleveringsketenbeveiliging als wettelijke eis
NIS-2 artikel 21 lid 2 sub d verplicht essentiële en belangrijke entiteiten tot het nemen van maatregelen voor de beveiliging van de toeleveringsketen, met inbegrip van beveiligingsaspecten van de relaties tussen de entiteit en haar directe leveranciers.
Zonder een SBOM is het onmogelijk om deze verplichting afdoende in te vullen. ENISA stelt in haar implementatiegids voor NIS-2 dat organisaties niet alleen hun directe leveranciers moeten kennen, maar ook de componenten die in de geleverde producten zijn ingebed. Een SBOM biedt precies die transparantielaag. Ontbreekt ze, dan is de risicoanalyse structureel onvolledig, wat bij een toezichtonderzoek of incident tot aansprakelijkheid kan leiden.
“Supply chain security requires organisations to know not only their direct suppliers, but also the components embedded within the products they procure.” (ENISA, NIS-2 Implementation Guidance)
Minimuminhoud van een bruikbare SBOM voor soevereiniteitsbeoordeling
Niet elke SBOM is gelijkwaardig. Voor gebruik als soevereiniteitsinstrument moet een SBOM minimaal de volgende gegevens bevatten:
| Veld | Toelichting | Relevant voor soevereiniteit |
|---|---|---|
| Componentnaam en versie | Unieke identificatie van elke bibliotheek of module | Koppeling aan CVE-databases |
| Leverancier of auteur | Rechtspersoon of individuele onderhouder | Juridische jurisdictie en herkomstland |
| Licentie | Open-source licentievorm (GPL, MIT, Apache, e.d.) | Hergebruiksrechten en exportrestricties |
| Pakket-URL (PURL) of CPE | Gestandaardiseerde identificator | Automatische kwetsbaarheidstoetsing |
| Hash (SHA-256 of vergelijkbaar) | Cryptografische vingerafdruk van het component | Integriteitsverificatie |
| Onderhoudsrelaties | Afhankelijkheidsgraph (directe en transitieve) | Risicoverspreiding via indirecte ketens |
De ENISA SBOM-richtlijnen uit 2023 benoemen beide dominante open standaarden als geschikt voor Europese praktijken: SPDX (Linux Foundation), dat sterk is in licentiedocumentatie en als ISO/IEC 5962:2021 is gestandaardiseerd, en CycloneDX (OWASP), dat specifiek is ontworpen voor beveiligingsanalyse en een rijkere context biedt voor kwetsbaarhedenbeheer. Voor overheidsinkoop die zowel juridische als technische toetsing vereist, is het aanbevelen waard beide formaten contractueel te accepteren of het primaire formaat met een conversieverplichting te combineren.
Componenten uit hoog-risicolanden: hoe een SBOM rode vlaggen onthult
De herziene Cybersecurity Act 2026 introduceert een ICT trusted supply chain-framework waarbinnen bepaalde leveranciers of componenten als hoog-risico kunnen worden aangemerkt op basis van juridische kwetsbaarheid voor inlichtingenwetgeving in hun land van vestiging. Een SBOM maakt het mogelijk dit per component systematisch te beoordelen.
“A Software Bill of Materials is not just a transparency tool; it is the foundation for understanding what you are actually running in your infrastructure and where the risk originates.” (Bernd Grobauer, Senior Security Expert, ENISA)
Concrete rode vlaggen die compliance officers in een SBOM kunnen identificeren:
- Onderhouders of rechtspersonen gevestigd in landen die door ENISA of nationale autoriteiten als hoog-risico zijn geclassificeerd voor ICT-toeleveringsketen.
- Componenten zonder actief onderhoud (laatste commit meer dan 24 maanden geleden), wat het risico op ongepatched kwetsbaarheden vergroot.
- Bibliotheken met bekende CVE’s van hoge of kritieke ernst waarvoor geen patch beschikbaar is.
- Telemetrie- of analysemodules die data naar servers buiten de Europese Economische Ruimte verzenden.
- Componenten afkomstig van organisaties die onderworpen zijn aan extraterritoriale wetgeving zoals de Amerikaanse CLOUD Act of de Chinese Cybersecurity Law.
De herziene Cybersecurity Act voorziet in een formeel beoordelingskader, maar ENISA raadt aan om al nu per SBOM een landenprofiel op te stellen en dit te toetsen aan eigen risicodrempelwaarden die door de raad van bestuur zijn vastgesteld.
Nextcloud en ONLYOFFICE versus Microsoft 365: SBOM-vergelijking
De SBOM-verplichting maakt het verschil tussen open-source en propriëtaire software concreet en aantoonbaar. Volgens het Synopsys Open Source Security and Risk Analysis Report 2023 bevat 84% van de onderzochte commerciële softwarepakketten minstens één kwetsbaar open-sourcecomponent, met gemiddeld 528 open-sourceafhankelijkheden per applicatie.
| Criterium | Nextcloud / ONLYOFFICE | Microsoft 365 |
|---|---|---|
| Broncode openbaar | Ja (AGPL / Apache) | Nee (propriëtair) |
| Zelf te genereren SBOM | Ja, via tooling (Syft, CycloneDX) | Nee, afhankelijk van Microsoft |
| CRA-conformiteit controleerbaar | Onafhankelijk verifieerbaar | Uitsluitend via verklaringen Microsoft |
| Jurisdictionele afhankelijkheid | Hosting in eigen beheer of EU-regio mogelijk | Gebonden aan Microsoft-datacenters en CLOUD Act-jurisdictie VS |
| NIS-2 toeleveringsketen-audit | Volledig auditeerbaar | Beperkt tot gepubliceerde compliance-documentatie |
ENISA signaleerde in haar Threat Landscape 2023 dat 15% van de cyberaanvallen bij grote organisaties de toeleveringsketen als initieel aanvalsvector gebruikte. Dit onderstreept waarom toezichthouders de SBOM-eis niet als bureaucratisch beschouwen, maar als directe risicobeheersingsmaatregel.
Handhaving en contractuele verankering van SBOM-eisen
De CRA kent een handhavingsregime met boetes tot 15 miljoen euro of 2,5% van de wereldwijde jaaromzet voor inbreuken op de essentiële vereisten, waaronder de SBOM-verplichting. Nationale markttoezichthouders zijn bevoegd producten van de markt te weren als de documentatie niet voldoet.
Voor inkopende organisaties is de praktische consequentie dat een leverancier zonder adequate SBOM niet langer aantoonbaar CRA-conform is. Dit schept contractuele ruimte en zelfs een verplichting om SBOM-eisen op te nemen in:
- SLA’s: Verplicht de leverancier tot het aanleveren van een actuele SBOM bij elke major release en op verzoek binnen een vastgelegde termijn (aanbevolen: 10 werkdagen).
- Verwerkersovereenkomsten (AVG artikel 28): Koppel de SBOM aan de verwerkersbeoordeling; een gewijzigde component die buiten de EER wordt onderhouden, vereist een bijgestelde risicoanalyse.
- Inkoopbestekken en aanbestedingscriteria: Maak de aanlevering van een CycloneDX- of SPDX-conforme SBOM een knock-outcriterium of zwaar wegend gunningscriterium.
- Auditrechten: Bedien u van het recht om de SBOM door een onafhankelijke derde te laten toetsen op volledigheid en juistheid.
Organisaties in gereguleerde sectoren (financiën, zorg, energie, overheid) die onder NIS-2 vallen, lopen bij een incident zonder aantoonbare SBOM-controle het risico dat de toezichthouder oordeelt dat artikel 21 lid 2 sub d niet naar behoren is nageleefd, met bestuursrechtelijke sancties als gevolg.
Praktische implementatiestappen voor compliance officers
De overgang van beleidsdocument naar afdwingbare praktijk verloopt het meest effectief in drie stappen. Eerst: stel een intern SBOM-beleid vast dat minimuminhoud, acceptabele formaten (CycloneDX en/of SPDX) en beoordelingscriteria voor jurisdictioneel risico vastlegt. Dit beleid wordt goedgekeurd op bestuursniveau en gekoppeld aan het informatiebeveiligingsbeleid.
Vervolgens: inventariseer het huidige softwareportfolio en vraag bij alle leveranciers een SBOM op. Ontbrekende of onvolledige SBOM’s worden geregistreerd als compliance-risico en opgevoerd in het risicoregister dat NIS-2 vereist. Tot slot: neem SBOM-leveringsverplichtingen op in alle nieuwe en te vernieuwen contracten, en koppel niet-naleving aan een contractueel opschortingsrecht of boeteclausule.
Voor de technische uitvoering zijn open-source tools beschikbaar, waaronder Syft (Anchore), Grype en de officiële CycloneDX-tooling van OWASP, die SBOM’s kunnen genereren uit broncode, containers en pakketmanifesten. Dit maakt onafhankelijke verificatie van leveranciersdocumentatie mogelijk, ongeacht of de leverancier zelf een SBOM aanlevert.
FAQ: SBOM, CRA en soevereine software-inkoop
Wanneer treedt de SBOM-verplichting van de CRA in werking?
De CRA is in 2024 gepubliceerd in het Publicatieblad van de EU. De meeste verplichtingen, waaronder de SBOM-eis, kennen een overgangsperiode van 36 maanden, wat betekent dat afdwinging circa vanaf 2027 geldt. Organisaties die nu contracten afsluiten of verlengen, doen er verstandig aan SBOM-eisen al in de huidige contracttekst op te nemen.
Welk SBOM-formaat wordt aanbevolen voor Europese overheidsopdrachten?
Zowel CycloneDX (OWASP) als SPDX (Linux Foundation) zijn erkende open standaarden die door ENISA worden benoemd in haar SBOM-richtlijnen van 2023. CycloneDX is sterk in beveiligingsgerichte analyse; SPDX is gestandaardiseerd als ISO/IEC 5962:2021 en sterk in licentie-compliance. Voor overheidsinkoop is acceptatie van beide formaten, of het primaire formaat met conversieverplichting, het meest robuust.
Kan een organisatie NIS-2-conformiteit aantonen zonder SBOM van haar leveranciers?
Niet volledig. NIS-2 artikel 21 lid 2 sub d vereist beheersing van de toeleveringsketen. Zonder SBOM is onmogelijk te verifiëren welke derde-partijcomponenten in gebruikte software zitten, waar ze vandaan komen en of ze kwetsbaarheden bevatten. Een ontbrekende SBOM is daarmee een aantoonbaar gat in de verplichte risicobeheersing.
Hoe verschilt Nextcloud van Microsoft 365 vanuit SBOM-perspectief?
Nextcloud en ONLYOFFICE zijn open-source platforms waarvan de volledige broncode publiek beschikbaar is; dit maakt onafhankelijke SBOM-generatie en verificatie mogelijk. Microsoft 365 is propriëtaire software waarbij inkopers afhankelijk zijn van wat Microsoft vrijwillig documenteert. Dit jurisdictionele en transparantievoordeel van open-source is bij aanbesteding een concreet en aantoonbaar criterium.
Welke rode vlaggen signaleren een hoog soevereiniteitsrisico in een SBOM?
Rode vlaggen zijn: onderhouders gevestigd in door ENISA of nationale autoriteiten als hoog-risico aangemerkte landen, componenten zonder actief onderhoud (meer dan 24 maanden geen release), bekende CVE’s zonder beschikbare patch, telemetriemodules die data buiten de EER sturen, en afhankelijkheden van organisaties die vallen onder extraterritoriale wetgeving zoals de Amerikaanse CLOUD Act of de Chinese Cybersecurity Law.
