SBOM-standaarden in toetsing: waarom softwaretransparantie steeds belangrijker wordt

Forum Standaardisatie onderzoekt of de SBOM-standaarden CycloneDX en SPDX moeten worden opgenomen op de ‘Pas toe of leg uit’-lijst. Daarvoor organiseerde het Forum een expertsessie om te toetsen of deze standaarden geschikt zijn als basis voor softwareveiligheid binnen de overheid.

Een SBOM, voluit Software Bill of Materials, is kort gezegd een onderdelenlijst van software. Het document beschrijft uit welke componenten, bibliotheken en frameworks een softwareproduct bestaat. Forum Standaardisatie benoemt CycloneDX en SPDX beide als SBOM-standaarden.

Waarom is dat relevant? Omdat organisaties bij een kwetsbaarheid in een gebruikte bibliotheek of framework sneller moeten kunnen bepalen of zij geraakt zijn. Een SBOM maakt zichtbaar welke softwarecomponenten aanwezig zijn en helpt daardoor om gerichter actie te ondernemen.

Voor Cilde raakt dit direct aan digitale weerbaarheid, leveranciersmanagement, BIO2, ITGC en governance op het digitale landschap. Wie niet weet welke softwarecomponenten worden gebruikt, kan ook moeilijk aantonen welke risico’s worden beheerst.

Een Software Bill of Materials is vergelijkbaar met een ingrediëntenlijst, maar dan voor software. In plaats van alleen te weten welk systeem of welke applicatie je gebruikt, krijg je inzicht in de onderdelen waaruit die software bestaat.

Denk aan:

• open source bibliotheken;
• frameworks;
• softwarepackages;
• afhankelijkheden;
• versies;
• licentie-informatie;
• relaties tussen componenten;
• informatie die nodig is voor kwetsbaarheidsanalyse.

Forum Standaardisatie omschrijft een SBOM als een document dat alle onderdelen, componenten, bibliotheken en frameworks beschrijft waaruit een softwareproduct bestaat.

Dat lijkt technisch, maar de impact is bestuurlijk. Zonder inzicht in softwarecomponenten is het lastig om vragen te beantwoorden als:

• Gebruiken wij een kwetsbare versie van een bepaalde bibliotheek?
• Welke applicaties zijn geraakt door een nieuw beveiligingslek?
• Welke leverancier moet actie ondernemen?
• Welke systemen zijn bedrijfskritisch en bevatten kwetsbare componenten?
• Kunnen we aantonen dat onze softwareketen beheerst wordt?
• Hoe snel kunnen we reageren bij een supply-chain-incident?

Een SBOM helpt dus niet alleen ontwikkelaars, maar ook security officers, IT-managers, inkopers, contractmanagers, auditors en bestuurders.

Forum Standaardisatie onderzoekt of CycloneDX en SPDX geschikt zijn om op te nemen op de ‘Pas toe of leg uit’-lijst. Een plaatsing op die lijst betekent dat de standaard verplicht moet worden uitgevraagd en toegepast volgens de Instructie rijksdienst bij aanschaf van ICT-diensten of ICT-producten.

De toetsing is belangrijk omdat SBOM’s pas echt waarde krijgen als organisaties, leveranciers en tooling dezelfde standaarden gebruiken. Zonder standaardisatie ontstaat versnippering: de ene leverancier levert een SBOM in het ene formaat, de andere in een ander formaat, en organisaties kunnen de informatie vervolgens moeilijk vergelijken, verwerken of hergebruiken.

CycloneDX en SPDX zijn internationaal gebruikte standaarden voor SBOM’s. In een eerder intakeadvies werden beide standaarden onder de noemer SBOM beschreven als internationaal ondersteund en technisch volwassen.

De vraag is nu of deze standaarden ook passen bij de Nederlandse overheid, de uitvoeringspraktijk, inkoopprocessen, leveranciersverplichtingen en Europese ontwikkelingen.

De toetsing van SBOM-standaarden is niet nieuw. In 2025 besloot Forum Standaardisatie om CycloneDX en SPDX nog niet in procedure te nemen, omdat Europese harmonisatie rond SBOM’s nog gaande was. De Europese Unie werkte via de Cyber Resilience Act en bijbehorende standaardisatieverzoeken aan geharmoniseerde eisen voor SBOM’s.

De zorg was logisch: als Nederland alvast één of meer standaarden verplicht zou stellen, terwijl Europa later een andere richting zou kiezen, konden organisaties te maken krijgen met dubbele implementatiekosten en verminderde interoperabiliteit.

In april 2026 werd de toetsingsprocedure hervat. Volgens Forum Standaardisatie is de eerdere onzekerheid over mogelijke Europese normconflicten weggenomen doordat NEN een conceptnorm heeft gepubliceerd ter ondersteuning van de Cyber Resilience Act. In dat concept worden CycloneDX en SPDX expliciet genoemd als gangbare formaten en worden geen exclusieve alternatieve standaarden voorgeschreven.

Daarmee is de weg vrijgemaakt om opnieuw te beoordelen of CycloneDX en SPDX geschikt zijn voor opname op de lijst met open standaarden.

Software wordt steeds vaker opgebouwd uit componenten van derden. Dat is efficiënt, maar maakt organisaties ook afhankelijk van softwareketens die zij niet volledig zelf beheren. Een kwetsbaarheid in één veelgebruikte bibliotheek kan daardoor impact hebben op honderden of duizenden systemen.

Een SBOM helpt om sneller antwoord te geven op de vraag: zijn wij geraakt?

Bij een kwetsbaarheid in een bibliotheek of framework stelt een SBOM overheidsorganisaties in staat om direct en gericht actie te ondernemen, aldus Forum Standaardisatie.

Zonder SBOM moet een organisatie vaak handmatig uitzoeken:

• welke applicaties de kwetsbare component gebruiken;
• welke versie aanwezig is;
• welke leverancier verantwoordelijk is;
• of er een patch beschikbaar is;
• welke systemen prioriteit hebben;
• welke risico’s tijdelijk geaccepteerd worden.

Met een goed ingerichte SBOM-aanpak kan dit proces veel sneller, consistenter en beter aantoonbaar verlopen.

SBOM’s passen in een bredere ontwikkeling: meer aandacht voor software supply chain security. Organisaties moeten niet alleen hun eigen infrastructuur beveiligen, maar ook inzicht krijgen in de softwareketen waar zij afhankelijk van zijn.

Dat raakt onder meer aan:

• inkoop van software;
• ontwikkeling van maatwerkapplicaties;
• gebruik van open source;
• SaaS-diensten;
• leveranciersmanagement;
• kwetsbaarhedenbeheer;
• licentiebeheer;
• incidentrespons;
• audit en compliance.

Voor overheidsorganisaties is dit extra relevant. Digitale dienstverlening is afhankelijk van software die vaak door meerdere partijen wordt gebouwd, gehost, onderhouden en doorontwikkeld. Een SBOM kan helpen om die afhankelijkheden zichtbaar en beheersbaar te maken.

CycloneDX en SPDX zijn beide standaarden om SBOM-informatie gestructureerd vast te leggen en uit te wisselen. Ze hebben hetzelfde hoofddoel: transparantie geven over softwarecomponenten en afhankelijkheden.

CycloneDX wordt veel gebruikt in security- en DevSecOps-contexten. De standaard is sterk gericht op software supply chain security, kwetsbaarhedeninformatie en integratie met moderne ontwikkelprocessen.

SPDX, voluit Software Package Data Exchange, heeft een sterke basis in licentie-informatie, open source compliance en softwarecomponentdocumentatie. SPDX is inmiddels breder inzetbaar voor SBOM’s en softwareketeninformatie.

Forum Standaardisatie onderzoekt beide standaarden onder de noemer SBOM. De vraag is dus niet alleen welke standaard technisch het beste is, maar ook hoe beide standaarden kunnen bijdragen aan interoperabiliteit, herbruikbaarheid en uitvoerbaarheid binnen de overheid.

Als een standaard op de ‘Pas toe of leg uit’-lijst staat, moeten overheidsorganisaties die standaard uitvragen en toepassen bij de aanschaf van ICT-diensten of ICT-producten. Afwijken mag alleen als daarvoor een goede uitleg wordt gegeven.

Als SBOM-standaarden op deze lijst komen, kan dat grote gevolgen hebben voor software-inkoop en leveranciersafspraken. Organisaties zullen dan bijvoorbeeld moeten nadenken over vragen als:

• Moeten leveranciers standaard een SBOM aanleveren?
• In welk formaat moet die SBOM worden geleverd?
• Hoe vaak moet de SBOM worden geactualiseerd?
• Wie controleert de kwaliteit van de SBOM?
• Hoe wordt SBOM-informatie gekoppeld aan kwetsbaarhedenbeheer?
• Wat gebeurt er als een leverancier geen SBOM kan leveren?
• Hoe wordt SBOM-informatie opgeslagen, beveiligd en gebruikt?

Daarmee wordt SBOM niet alleen een technisch artefact, maar een onderdeel van professioneel opdrachtgeverschap.

SBOM raakt direct aan meerdere normenkaders en beheersprocessen.

BIO2

BIO2 legt nadruk op risicogestuurd werken. Om softwareketenrisico’s goed te beoordelen, moet een organisatie weten welke softwarecomponenten worden gebruikt en welke kwetsbaarheden daarbij horen. Een SBOM kan helpen om die informatie aantoonbaar beschikbaar te maken.

ITGC

Binnen IT General Controls gaat het onder meer om wijzigingsbeheer, toegangsbeheer, incidentbeheer, continuïteit en security management. SBOM-informatie kan vooral waardevol zijn bij wijzigingsbeheer, kwetsbaarhedenbeheer en incidentrespons. Als software wordt aangepast of geüpdatet, wil je weten welke componenten veranderen en welke risico’s daarmee samenhangen.

Leveranciersmanagement

Veel organisaties zijn afhankelijk van softwareleveranciers, SaaS-platformen en ontwikkelpartners. SBOM maakt het mogelijk om concretere afspraken te maken over transparantie, patching, kwetsbaarheden, open source gebruik en verantwoordelijkheid in de keten.

Inkoop en contractmanagement

Als SBOM-standaarden verplicht of aanbevolen worden, moeten inkoopvoorwaarden, aanbestedingsdocumenten, contracten en acceptatiecriteria daarop worden aangepast. Organisaties die hier nu al op voorsorteren, voorkomen dat zij later veel herstelwerk moeten doen.

Een belangrijk punt: een SBOM is geen wondermiddel. Het hebben van een SBOM betekent nog niet automatisch dat software veilig is. De waarde ontstaat pas als SBOM-informatie wordt gebruikt in processen.

Denk aan:

• periodieke actualisatie;
• controle op volledigheid en juistheid;
• koppeling aan kwetsbaarhedendatabases;
• prioritering op basis van risico;
• opvolging van kwetsbaarheden;
• rapportage aan management;
• afspraken met leveranciers;
• integratie in CI/CD-processen;
• gebruik bij incidentrespons.

Ook uit onderzoek blijkt dat SBOM-gebaseerde kwetsbaarheidsscans complex zijn en dat tools verschillend kunnen omgaan met geldige SBOM’s, wat kan leiden tot inconsistente resultaten of een vals gevoel van veiligheid.

De les is duidelijk: SBOM moet worden ingebed in governance, processen en monitoring.

Ook voordat duidelijk is of CycloneDX en SPDX op de ‘Pas toe of leg uit’-lijst komen, kunnen organisaties zich voorbereiden.

1. Breng je softwarelandschap in kaart

Begin met inzicht. Welke applicaties, websites, portalen, SaaS-diensten en maatwerkoplossingen zijn er? Welke zijn bedrijfskritisch? Welke verwerken gevoelige gegevens? Welke leveranciers zijn betrokken?

2. Vraag leveranciers naar SBOM-mogelijkheden

Onderzoek welke leveranciers al SBOM’s kunnen leveren, in welk formaat, hoe vaak en met welke kwaliteit. Dit hoeft niet direct als harde verplichting te beginnen; het kan ook als volwassenheidsvraag in leveranciersgesprekken.

3. Neem SBOM op in nieuwe aanbestedingen

Bij nieuwe softwaretrajecten is het verstandig om SBOM-eisen alvast mee te nemen. Denk aan formaat, actualisatie, versiebeheer, kwetsbaarhedeninformatie en verantwoordelijkheden.

4. Koppel SBOM aan kwetsbaarhedenbeheer

Een SBOM is pas waardevol als deze kan worden gebruikt om kwetsbaarheden te identificeren, prioriteren en opvolgen. Zorg daarom voor aansluiting op securityprocessen.

5. Maak eigenaarschap expliciet

Wie is verantwoordelijk voor SBOM-informatie? De leverancier, het ontwikkelteam, functioneel beheer, security, inkoop of contractmanagement? Zonder eigenaarschap blijft SBOM een technisch bestand zonder bestuurlijke waarde.

6. Start klein, maar structureel

Begin bijvoorbeeld met één kritisch systeem, één nieuw aanbestedingstraject of één ontwikkelstraat. Gebruik die ervaring om eisen, processen en verantwoordelijkheden verder aan te scherpen.

De toetsing van CycloneDX en SPDX door Forum Standaardisatie is een belangrijke stap richting meer transparantie in de softwareketen van de overheid. Als SBOM-standaarden breder worden toegepast, kunnen organisaties sneller inzicht krijgen in kwetsbare componenten, betere afspraken maken met leveranciers en hun digitale weerbaarheid versterken.

Voor organisaties is dit het moment om zich voor te bereiden. Niet door te wachten tot SBOM verplicht wordt, maar door nu al te onderzoeken waar softwareafhankelijkheden zitten, welke leveranciers SBOM’s kunnen leveren en hoe SBOM-informatie kan worden gekoppeld aan bestaande processen voor security, compliance en risicomanagement.

Cilde helpt organisaties om dit soort ontwikkelingen te vertalen naar praktische governance: inzicht in het digitale landschap, duidelijke eigenaarschap, samenhang tussen normenkaders en blijvende borging.