Een SBOM (Software Bill of Materials) bij soevereine softwareinkoop is een gestructureerde, machineleesbare inventaris van alle softwarecomponenten, bibliotheken en afhankelijkheden in een product of dienst, inclusief hun versies, licenties en herkomst. Voor organisaties die bewust kiezen voor soevereine cloudoplossingen buiten de invloedssfeer van Amerikaanse jurisdictie, is de SBOM geen administratieve bijlage maar een aantoonbaar instrument voor toeleveringsketenverantwoordelijkheid, incidentrespons en regulatoire naleving.
Wat eisen CRA, NIS-2 en CISA 2026 van een SBOM bij soevereine inkoop
Drie regelgevende kaders bepalen samen de minimumbodem voor SBOM-eisen bij inkoop van cloudoplossingen door Europese organisaties in gereguleerde sectoren.
De Cyber Resilience Act (CRA), artikel 13, verplicht fabrikanten van producten met digitale elementen een SBOM op te stellen die ten minste de top-level afhankelijkheden van het product dekt. De CRA trad in werking in december 2024 (Verordening (EU) 2024/2847), met een overgangsperiode voor de meeste verplichtingen tot 2027. Artikel 13 benoemt expliciet dat de SBOM beschikbaar moet zijn voor bevoegde autoriteiten op verzoek en dat fabrikanten kwetsbaarheden in de gedekte componenten actief moeten monitoren.
De NIS-2-richtlijn (2022/2555), artikel 21 lid 2 sub e, verplicht essentiële en belangrijke entiteiten maatregelen te nemen voor beveiliging in de toeleveringsketen, inclusief de beoordeling van de beveiligingspraktijken van directe leveranciers. Een SBOM is het minimuminstrument om die beoordeling te objectiveren: zonder componentenlijst is ketenverantwoordelijkheid niet aantoonbaar.
De CISA Minimum Elements for a Software Bill of Materials (gepubliceerd 2021, leidend voor de 2026 CISA/BSI-richtlijnen) definieert zeven verplichte velden: naam van de leverancier, componentnaam, versienummer, unieke identifier (zoals CPE of PURL), afhankelijkheidsrelaties, auteur van de SBOM-data, en een tijdstempel. Het BSI (Bundesamt für Sicherheit in der Informationstechnik) sluit in zijn eigen technische richtlijnen aan bij deze elementen. Organisaties die software inkopen voor overheids- of kritieke infrastructuurtoepassingen, moeten contractueel bedingen dat leveranciers deze zeven elementen aanleveren bij elke nieuwe versie.
SBOM en het EU Cloud Sovereignty Framework: hoe verhouden de eisen zich?
Het EU Cloud Sovereignty Framework en de bijbehorende CADA-auditvereisten (Cloud Audit Data Assurance) voegen aan de SBOM-eis een jurisdictionele dimensie toe.
Het framework vereist dat organisaties kunnen aantonen waar data wordt opgeslagen, welke softwarestack die data verwerkt, en welke derde partijen toegang hebben tot die stack. Een SBOM maakt de softwarelaag van die driehoek aantoonbaar. Concreet betekent dit dat een SBOM bij een soevereine inkoop niet alleen de applicatielaag moet dekken, maar ook middleware, containerruntimes, orchestratietools en eventuele telemetrie-bibliotheken die data naar externe endpoints kunnen sturen.
Bij een CADA-audit moet de SBOM vergezeld gaan van een aantoonbaar proces voor SBOM-updates: hoe snel na een nieuwe release of na publicatie van een CVE wordt de SBOM bijgewerkt? De ENISA Good Practices for Supply Chain Cybersecurity (2023) beveelt aan dit proces te contractualiseren met maximale responstermijnen van 72 uur voor kritieke kwetsbaarheden.
“Supply chain security is not optional under NIS-2. Article 21 explicitly requires measures addressing risks in supplier relationships, and an SBOM is the minimum instrument to make those risks visible.”
ENISA, Good Practices for Supply Chain Cybersecurity 2023
Statistisch beeld: volgens het ENISA Threat Landscape 2023 had 58% van de NIS-2-plichtige organisaties in de EU onvoldoende inzicht in de softwarecomponenten van kritieke leveranciers. Dat getal illustreert de operationele kloof die een SBOM-verplichting bij inkoop moet dichten.
SBOM-verificatie inrichten als compliance officer
Een SBOM-verificatieproces is effectief wanneer het aansluit op bestaande vendor risk assessment-cycli en niet als afzonderlijk spoor wordt georganiseerd.
Praktisch betekent dit: voeg SBOM-aanlevering toe als contractuele leveringsvoorwaarde bij elke softwarerelease. Koppel de ontvangen SBOM aan de vulnerability scanner die de organisatie al gebruikt (zoals Trivy, Grype of Dependency-Track), zodat nieuwe CVE-matches automatisch worden gesignaleerd. Leg in het vendor risk assessment-formulier vast welke SBOM-velden verplicht zijn, hoe Unknown Information-velden worden behandeld (zie volgende sectie), en binnen welke termijn de leverancier een bijgewerkte SBOM moet leveren na een beveiligingsincident.
Voor NIS-2-ketenverantwoordelijkheid geldt: de compliance officer is verantwoordelijk voor het aantoonbaar vastleggen van dit proces, niet alleen voor het uitvoeren ervan. Bewaar ontvangen SBOM-bestanden, verificatielogboeken en leveranciersresponsen minimaal vijf jaar, in lijn met gangbare auditretentieperiodes.
“A software bill of materials is a foundational element of software security and cybersecurity risk management. Without it, organizations cannot know what they are running, let alone whether it is safe.”
Jen Easterly, voormalig directeur CISA
SBOM-formaten voor soevereine open-source werkpleksoftware
Voor open-source werkpleksoftware zoals Nextcloud zijn drie formaten relevant: SPDX, CycloneDX en SWID. Ze zijn niet inwisselbaar.
| Formaat | Standaard | Sterkste toepassing | VEX-ondersteuning | AI-componenten |
|---|---|---|---|---|
| SPDX | ISO/IEC 5962:2021 | Licentiecompliance, CI/CD-integratie | Beperkt (via externe koppeling) | Niet standaard |
| CycloneDX | OWASP | Security, VEX, AI-SBOM | Ingebouwd (eigen VEX-schema) | Ja (MLflow, model-metadata) |
| SWID | ISO/IEC 19770-2 | Geïnstalleerde softwarepakketten (endpoint) | Nee | Nee |
Voor een soevereine Nextcloud-omgeving is CycloneDX het meest toekomstvaste formaat vanwege de ingebouwde VEX-ondersteuning en de groeiende ondersteuning voor AI-componenten. SPDX is de voorkeur wanneer licentiecompliance de primaire driver is of wanneer de CI/CD-tooling SPDX al genereert.
Unknown Information (componenten waarvan versie of licentie niet aantoonbaar is) moet in beide formaten expliciet worden gemarkeerd, niet stilzwijgend worden weggelaten. In CycloneDX gebeurt dit via het unknown-veld binnen de component-metadata; in SPDX via NOASSERTION. Een SBOM met ongemarkeerde ontbrekende velden is juridisch onbetrouwbaar bij een audit.
Concrete cijfers onderstrepen waarom volledigheid telt: het Synopsys OSSRA 2023-rapport toonde dat 84% van de onderzochte codebases minimaal één bekende kwetsbaarheid bevatte in open-source afhankelijkheden, en 91% van de codebases bevatte componenten die meer dan vier jaar achterliepen op de actuele versie. Zonder een SBOM die ook transitieve afhankelijkheden dekt, zijn zulke risico’s structureel onzichtbaar.
SBOM gekoppeld aan VEX: de kern van incidentrespons
Een SBOM inventariseert componenten; een VEX (Vulnerability Exploitability eXchange) vertelt per CVE of een component in de specifieke deploymentconfiguratie daadwerkelijk exploiteerbaar is.
De vier VEX-statussen zijn: not affected, affected, fixed en under investigation. Bij een soevereine infrastructuur, waar geen externe telemetrie aanwezig is en patchcycli handmatig worden beheerd, is een actueel VEX-document per release essentieel om tijdens een incident binnen minuten te bepalen welke systemen prioriteit hebben. Zonder VEX leidt elke nieuwe CVE-publicatie tot handmatig doorzoeken van componentversies, een proces dat bij complexe Nextcloud-omgevingen met tientallen PHP-bibliotheken en plug-ins onwerkbaar traag is.
CycloneDX ondersteunt VEX als ingebed document binnen dezelfde SBOM-structuur, wat de koppeling tijdens incidentrespons operationeel vereenvoudigt. SPDX vereist een externe koppeling via aparte VEX-bestanden, wat beheer complexer maakt maar technisch evengoed mogelijk is.
AI-SBOM: aanvullende vereisten voor soevereine LLM-inzet
Wanneer een organisatie een lokaal gehoste LLM (Large Language Model) inzet zonder datadeling, gelden boven op de standaard SBOM-elementen aanvullende AI-specifieke velden die het G7 Hiroshima AI Process (2023) heeft gedefinieerd als AI-SBOM Minimum Elements.
De aanvullende verplichte velden zijn: het gebruikte trainingsraamwerk en versie (bijvoorbeeld PyTorch 2.1.0), de versie en herkomst van het basismodel inclusief licentie (bijvoorbeeld Llama 2, Meta, licentie: Llama 2 Community License), de gebruikte trainings- en fine-tuningdatasets met hun licentie-informatie en eventuele privacyclassificatie, en de inferentie-infrastructuur inclusief hardwareplatform en besturingssysteemversie.
Voor soevereine inzet is het vijfde element even belangrijk: een expliciete verklaring dat het model geen externe API-aanroepen doet en geen klantdata verzendt naar externe endpoints, inclusief een technische beschrijving van hoe dat is gewaarborgd (netwerksegmentatie, absence of outbound connections in de SBOM-metadata). Dit veld is niet standaard in CISA Minimum Elements, maar is noodzakelijk om aan GDPR-verwerkersverplichtingen en NIS-2-ketenverantwoordelijkheid te voldoen wanneer het model klantdata verwerkt.
CycloneDX versie 1.5 en hoger ondersteunt AI/ML-componenttypen als eerste klasse objecten in het schema, wat AI-SBOM-generatie in geautomatiseerde pipelines praktisch haalbaar maakt voor organisaties die Nextcloud combineren met een lokale AI-assistent.
Veelgestelde vragen over SBOM en soevereine softwareinkoop
Is een SBOM wettelijk verplicht bij inkoop van cloudsoftware voor NIS-2-plichtige organisaties?
NIS-2 artikel 21 lid 2 sub e verplicht maatregelen voor beveiliging in de toeleveringsketen, maar noemt een SBOM niet bij naam. De CRA artikel 13 stelt dat fabrikanten van producten met digitale elementen een SBOM moeten opstellen en beschikbaar stellen. In combinatie maken beide kaders een SBOM bij inkoop van kritieke software feitelijk onvermijdbaar voor aantoonbare ketenverantwoordelijkheid.
Welk SBOM-formaat heeft de voorkeur voor open-source werkpleksoftware zoals Nextcloud?
CycloneDX biedt de meeste ondersteuning voor VEX-koppeling en AI-componenten en is daarmee het meest toekomstvaste formaat. SPDX (ISO/IEC 5962:2021) is de internationale standaard en wordt breed ondersteund door package managers en CI/CD-tooling. Voor overheidsinkoop in de EU worden beide formaten als gelijkwaardig beschouwd. SWID is primair bedoeld voor geïnstalleerde softwarepakketten en minder geschikt voor complexe open-source afhankelijkheidsbomen.
Wat moet een compliance officer opnemen in een vendor risk assessment op basis van SBOM-criteria?
Verlang minimaal de zeven CISA Minimum Elements: naam leverancier, naam component, versie, unieke identifier, afhankelijkheidsrelaties, auteur van de SBOM-data en tijdstempel. Voeg hieraan toe: een VEX-document per release, een proces voor tijdige SBOM-updates bij nieuwe kwetsbaarheden, en een verklaring over de behandeling van Unknown Information-velden. Koppel dit aan de contractuele auditrechten die NIS-2-toeleveringsketen-vereisten ondersteunen.
Hoe verschilt een AI-SBOM van een gewone SBOM en wanneer is die verplicht?
Een AI-SBOM voegt aan de standaard SBOM-elementen toe: het gebruikte trainingsraamwerk, de versie en herkomst van het basismodel, de trainings- en fine-tuningdatasets met licentie-informatie, en de inferentie-infrastructuur. De G7 Hiroshima AI Process beschrijft deze velden als minimumvereisten voor transparante AI-systemen. Bij een soevereine LLM-inzet zonder datadeling zijn deze velden essentieel om aan te tonen dat het model geen externe connectiviteit heeft en geen klantdata deelt.
Wat is het verschil tussen een SBOM en een VEX, en hoe werken ze samen bij incidentrespons?
Een SBOM inventariseert alle softwarecomponenten en hun versies. Een VEX-document koppelt aan die componenten een exploitability-status per CVE: ‘not affected’, ‘affected’, ‘fixed’ of ‘under investigation’. Bij een incident in een soevereine infrastructuur kan het beveiligingsteam via de VEX binnen minuten bepalen welke componenten daadwerkelijk kwetsbaar zijn in de specifieke deploymentconfiguratie, zonder handmatig alle CVE-feeds te doorzoeken.
