Een Software Bill of Materials (SBOM) is een gestructureerde, machine-leesbare inventaris van alle softwarecomponenten, afhankelijkheden en licenties in een digitaal product. Voor compliance-officers en IT-beslissers in de overheid, juridische sector en andere gereguleerde sectoren is de SBOM de kern van verantwoorde software-inkoop: zonder componenttransparantie is toeleveringsketenveiligheid een lege belofte, zeker wanneer die inkoop betrekking heeft op soevereine cloud- of AI-oplossingen die gevoelige gegevens verwerken.
Wat de 2026 CISA/NSA SBOM-guidance van Europese inkopers vraagt
De gezamenlijke guidance van CISA, NSA en FBI, voortbouwend op de NTIA Minimum Elements for a Software Bill of Materials (2021), beschrijft de basisvereisten waaraan een SBOM moet voldoen om bruikbaar te zijn voor risicobeheersing. Elk component dient te zijn voorzien van een leveranciersnaam, productnaam, versie, unieke identifier (bij voorkeur een Package URL of CPE), afhankelijkheidsrelaties en tijdstempel van de SBOM zelf. Hoewel deze guidance primair gericht is op de Amerikaanse federale markt, is zij feitelijk de internationale ijklijn geworden voor wat een “minimaal bruikbare” SBOM inhoudt.
Voor Europese inkopers van soevereine clouddiensten, zoals Nextcloud-installaties bij een Zwitserse of op locatie beheerde hoster, betekent dit concreet: een leverancier die geen SBOM kan leveren die aan deze minimumvereisten voldoet, kan ook niet aantonen dat zijn product vrij is van bekende kwetsbaarheden in transitieve afhankelijkheden. Dat is geen administratieve formaliteit; meer dan 80% van de open-source kwetsbaarheden bevindt zich in indirecte, transitieve afhankelijkheden (Sonatype State of the Software Supply Chain 2023).
De SBOM-plicht in de Cyber Resilience Act en de verbinding met NIS-2
De Cyber Resilience Act (CRA) verankert de SBOM-verplichting in Europees recht. Artikel 13 lid 3 CRA schrijft voor dat fabrikanten van producten met digitale elementen kwetsbaarheden en componenten identificeren en documenteren, inclusief het opstellen van een software bill of materials. De CRA is in 2024 aangenomen; de meeste verplichtingen gelden voor producten die na de overgangsperiode (verwacht eind 2027) op de EU-markt worden gebracht.
Het Europees Parlement en de Raad formuleren het als volgt in artikel 13 lid 3: “Manufacturers shall identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials.”
NIS-2 artikel 21 lid 2 sub d verplicht essentiële en belangrijke entiteiten daarnaast om de beveiliging van hun toeleveringsketen te borgen, inclusief de beveiligingsrelaties met directe leveranciers. Deze twee verplichtingen overlappen bewust: de CRA legt de verantwoordelijkheid bij de softwareleverancier, NIS-2 bij de afnemende organisatie. Een overheidsinstelling die Nextcloud inzet bij een externe hoster is zelf verantwoordelijk voor het opvragen en beoordelen van de SBOM; de hoster is op grond van de CRA verplicht die te leveren zodra hij als fabrikant of importeur kwalificeert.
| Verplichting | Rechtsgrond | Adressaat | Wat wordt vereist |
|---|---|---|---|
| SBOM opstellen | CRA artikel 13 lid 3 | Softwareleverancier / fabrikant | Machine-leesbare componentinventaris met kwetsbaarheidsdocumentatie |
| Toeleveringsketen beveiligen | NIS-2 artikel 21 lid 2 sub d | Essentiële of belangrijke entiteit (afnemer) | Beoordeling en contractuele borging van leveranciersbeveiliging |
| SBOM opvragen en beoordelen | NIS-2 in combinatie met CRA | Compliance-officer bij inkoop | Verificatie dat leverancier voldoet aan minimumvereisten SBOM-inhoud |
SPDX of CycloneDX: welk format is bruikbaar in de praktijk?
Twee formats domineren de praktijk van SBOM-uitwisseling. SPDX (Software Package Data Exchange), gestandaardiseerd als ISO/IEC 5962:2021 en beheerd door de Linux Foundation, is primair ontworpen voor licentie-compliance en bevat gedetailleerde informatie over auteursrechthouders en licentieteksten. CycloneDX, ontwikkeld door OWASP, is meer gericht op beveiligingsgebruik en ondersteunt naast softwarecomponenten ook kwetsbaarheidsmetadata (VEX, Vulnerability Exploitability eXchange) en hardware-inventarisaties.
Voor een compliance-officer die een cloudleverancier wil beoordelen op componenttransparantie en beveiligingsrisico’s is CycloneDX in de praktijk breder inzetbaar: het format ondersteunt directe koppeling met de CVE-database en maakt het mogelijk om per component de exploitatiestatus van bekende kwetsbaarheden vast te leggen. SPDX is de betere keuze wanneer licentie-audit de primaire doelstelling is, bijvoorbeeld bij een aanbesteding waarbij intellectueleigendomsrisico’s worden beoordeeld. In veel gevallen vraagt u bij inkoop het beste beide aan: SPDX voor licentieaudit, CycloneDX voor beveiligingsanalyse.
84% van de in 2024 onderzochte codebases bevat minstens één bekende open-source kwetsbaarheid, en 91% bevat componenten die geen actieve ontwikkeling meer ontvangen (Synopsys Open Source Security and Risk Analysis 2024). Zonder een SBOM in een bruikbaar format zijn dit soort risico’s bij inkoop feitelijk onzichtbaar.
SBOM als instrument voor PQC-migratieanalyse in de toeleveringsketen
Post-quantum cryptografie (PQC) is geen toekomstmuziek meer: NIST publiceerde in augustus 2024 de eerste definitieve standaarden (FIPS 203, 204 en 205) op basis van CRYSTALS-Kyber, CRYSTALS-Dilithium en SPHINCS+. Organisaties in gereguleerde sectoren die nu nog afhankelijk zijn van RSA of elliptische-curvecryptografie lopen een reëel “harvest now, decrypt later”-risico.
Een SBOM maakt de migratie-analyse concreet uitvoerbaar. Door de componentlijst van een leverancier te vergelijken met een inventaris van bibliotheken die uitsluitend klassieke algoritmen implementeren (zoals oudere versies van OpenSSL vóór 3.x, of Java-implementaties zonder BouncyCastle PQC-extensie), kan een compliance-officer systematisch vaststellen welke onderdelen van de software nog niet kwantumbestendig zijn. Tools zoals OWASP Dependency-Check, Google OSV-Scanner en de CISA-vulnerability-database ondersteunen dit gedeeltelijk geautomatiseerd wanneer de SBOM in CycloneDX-formaat beschikbaar is.
Voor Nextcloud-omgevingen is de analyse relatief transparant doordat de broncode openbaar is: de gebruikte PHP-cryptobibliotheek en eventuele onderliggende TLS-implementatie zijn traceerbaar. Bij gesloten clouddiensten van grote Amerikaanse aanbieders ontbreekt die mogelijkheid volledig, wat de SBOM-verplichting onder de CRA extra relevant maakt als tegengewicht.
AI-SBOM: aanvullende vereisten bij inkoop van on-premise AI-systemen
De G7-landen hebben binnen hun werkprogramma voor verantwoorde AI de contouren van een AI-SBOM Minimum Elements gepubliceerd. Waar een reguliere SBOM zich beperkt tot softwarecomponenten en afhankelijkheden, vereist een AI-SBOM aanvullende metadata over de AI-systeemketen, namelijk trainingsdata-herkomst, gebruikte modelgewichten en de versie daarvan, finetuning-stappen, en externe API-afhankelijkheden die tijdens inferentie worden aangeroepen.
Voor compliance-officers in gereguleerde sectoren die een on-premise of private AI-systeem aanschaffen, zijn die aanvullende elementen niet optioneel. Een AI-systeem dat claimen “nooit op klantdata te trainen” maar waarbij de inferentie-infrastructuur externe API-calls maakt naar een Amerikaanse clouddienst, valt juridisch onder de jurisdictie van de CLOUD Act op het moment dat die calls plaatsvinden. Een AI-SBOM maakt dergelijke verborgen afhankelijkheden zichtbaar.
De combinatie van CRA-verplichtingen, NIS-2 toeleveringsketenonvereisten en de AI-Act (voor AI-systemen met hoog risico) maakt een geïntegreerde SBOM-aanpak noodzakelijk: één document dat softwarecomponenten, cryptografische primitieven én AI-specifieke metadata omvat. Dit is momenteel nog geen marktstandaard, maar de G7-guidance biedt een operationeel startpunt voor inkoopcontracten.
Praktische inkoopprocedure voor compliance-officers
De SBOM-beoordeling hoort in de aanbestedingsfase, niet achteraf. Neem in het programma van eisen of de inkoopspecificaties de volgende verplichte leveranciersdocumenten op: een CycloneDX-SBOM van de meest recente productieversie, een VEX-document met de exploitatiestatus van bekende CVE’s in die SBOM, een cryptografisch componentprofiel (welke algoritmen, welke sleutellengtes, welke bibliotheken), en voor AI-systemen een AI-SBOM conform de G7-minimumelementen.
Verificatie is de volgende stap. Vergelijk de aangeleverde SBOM met de publieke kwetsbaarheidsdatabases (NVD, OSV) via een geautomatiseerde scanner. Let daarbij specifiek op componenten zonder actieve maintainer en op cryptografische bibliotheken ouder dan twee jaar, omdat die doorgaans geen PQC-ondersteuning bevatten. Leg vervolgens in het contract vast dat de leverancier binnen een gedefinieerde termijn, maximaal 30 dagen na publicatie van een kritieke CVE, een bijgewerkte SBOM levert.
CISA omschrijft de SBOM als volgt: “An SBOM is a key building block in software security and software supply chain risk management.” Die formulering is functioneel: de SBOM is geen doel op zich, maar een instrument dat zijn waarde pas bewijst wanneer u er actief mee werkt in het inkoopproces en de doorlopende leveranciersbeoordeling.
FAQ: SBOM, CRA en soevereine software-inkoop
Is een SBOM verplicht voor alle Europese softwareleveranciers onder de CRA?
Ja. De Cyber Resilience Act verplicht fabrikanten van producten met digitale elementen (artikel 13 lid 3) om een software bill of materials op te stellen en kwetsbaarheden daarin te documenteren. De CRA is in 2024 aangenomen; de meeste verplichtingen gelden voor producten die na de overgangsperiode (verwacht eind 2027) op de EU-markt worden gebracht. Producten die vóór die datum al op de markt zijn, vallen buiten de directe verplichting, maar leveranciers die willen meedingen aan aanbestedingen in gereguleerde sectoren zullen eerder aan de vereisten moeten voldoen.
Welk SBOM-format vraag ik als compliance-officer op bij een leverancier: SPDX of CycloneDX?
Beide formats zijn breed ondersteund en machine-leesbaar. SPDX (ISO/IEC 5962:2021) is een ISO-norm en sterk gericht op licentie-informatie; CycloneDX (OWASP) biedt rijkere ondersteuning voor kwetsbaarheidsdata en is daardoor breder inzetbaar voor beveiligingsbeoordelingen. Vraag voor supply-chain risicoanalyse bij voorkeur CycloneDX aan, maar accepteer ook SPDX als de leverancier dat als enige aanbiedt en combineer het met een apart VEX-document.
Hoe helpt een SBOM bij het identificeren van kwantumkwetsbare cryptografie in cloudsoftware?
Een SBOM bevat de componentversies van gebruikte cryptografische bibliotheken, zoals OpenSSL of Bouncy Castle. Door de SBOM te vergelijken met een overzicht van bibliotheken die RSA, ECDH of andere klassieke algoritmen implementeren zonder PQC-ondersteuning, stelt u vast welke versies niet aansluiten op de NIST-standaarden FIPS 203, 204 en 205. Tools zoals OWASP Dependency-Check en Google OSV-Scanner ondersteunen dit gedeeltelijk geautomatiseerd wanneer de SBOM in CycloneDX-formaat beschikbaar is.
Wat vereist NIS-2 artikel 21 lid 2 sub d concreet voor toeleveranciers zoals Nextcloud-hosters?
NIS-2 artikel 21 lid 2 sub d verplicht essentiële en belangrijke entiteiten om de beveiliging van hun toeleveringsketen te adresseren, inclusief de beveiligingsaspecten van de relaties met directe leveranciers. In de praktijk betekent dit dat u van een Nextcloud-hoster minimaal een componentoverzicht (SBOM), een gedocumenteerd kwetsbaarheidsbeleid en aantoonbaar patchbeheer moet kunnen opvragen. Ontbreekt deze documentatie, dan draagt u als afnemende organisatie het NIS-2-nalevingsrisico.
Wat onderscheidt een AI-SBOM van een gewone SBOM bij inkoop van een on-premise AI-systeem?
De G7 AI-SBOM Minimum Elements vragen naast softwarecomponenten ook om documentatie van trainingsdata-herkomst, modelgewichten en hun versienummers, finetuning-stappen en externe API-afhankelijkheden die tijdens inferentie worden aangeroepen. Bij een on-premise of private AI-systeem in een gereguleerde sector beoordeelt u op basis van de AI-SBOM of de leverancier de oorsprong van trainingsdata kan verantwoorden en of er verborgen cloud-afhankelijkheden zijn die de soevereiniteit van de oplossing ondermijnen.
