SBoM

Een SBoM, voluit Software Bill of Materials, is een gestructureerde, machineleesbare lijst van alle componenten, libraries, frameworks en afhankelijkheden waaruit een softwareproduct is opgebouwd. Je kunt het vergelijken met een ingredientenlijst op een voedselproduct: het vertelt je precies wat er in de software zit. Een SBoM bevat informatie over elke component, zoals de naam, versie, licentie en herkomst. Dit is essentieel voor het beheersen van risico’s in de software supply chain, omdat kwetsbaarheden in een enkele component miljoenen systemen wereldwijd kunnen treffen.

De relevantie van SBoM’s is de afgelopen jaren explosief gegroeid. Na grootschalige supply chain aanvallen zoals Log4Shell, waarbij een kwetsbaarheid in de veelgebruikte Log4j-library miljoenen systemen trof, bleek dat de meeste organisaties geen overzicht hadden van welke componenten in hun software zaten. In september 2025 publiceerden CISA, de NSA en negentien internationale partners gezamenlijke richtlijnen voor SBoM’s, wat een significante stap voorwaarts markeert in het versterken van transparantie in de software supply chain. De EU Cyber Resilience Act (CRA) verplicht softwarefabrikanten om SBoM’s te produceren en bij te houden in een gestandaardiseerd, machineleesbaar formaat.

Waarom is een SBoM belangrijk?

Moderne software bestaat voor 70 tot 90 procent uit open-source componenten. Elke component kan kwetsbaarheden bevatten die op elk moment ontdekt kunnen worden. Zonder een SBoM heb je geen zicht op welke componenten je gebruikt, laat staan welke versies en of daar bekende kwetsbaarheden in zitten. Wanneer een nieuwe kwetsbaarheid wordt gepubliceerd, moet je binnen uren kunnen vaststellen of je software is getroffen. Met een actuele SBoM is dat een kwestie van seconden, zonder SBoM kan het dagen tot weken duren.

SBoM’s zijn ook cruciaal voor compliance. De EU Cyber Resilience Act vereist dat fabrikanten van producten met digitale elementen een SBoM beschikbaar stellen. NIS2 benadrukt het belang van supply chain security, waarvan SBoM’s een fundamenteel onderdeel vormen. In de Verenigde Staten heeft een Executive Order uit 2021 al geleid tot SBoM-vereisten voor software die aan de overheid wordt geleverd. CISA publiceerde in augustus 2025 een geactualiseerde draft van de SBoM Minimum Elements, die de eisen uit 2021 bijwerkt op basis van praktijkervaringen.

Daarnaast verbeteren SBoM’s het licentiebeheer. Open-source componenten vallen onder verschillende licenties, van permissief (MIT, Apache) tot restrictief (GPL). Een SBoM maakt direct inzichtelijk welke licenties van toepassing zijn op je software, waardoor je juridische risico’s kunt identificeren voordat ze problemen veroorzaken. Dit is vooral relevant voor organisaties die eigen software distribueren of als SaaS aanbieden.

Hoe pas je een SBoM toe?

Het genereren van een SBoM begint in het ontwikkelproces. Geautomatiseerde tools scannen de broncode, build-configuraties en package managers om alle directe en transitieve afhankelijkheden te identificeren. Transitieve afhankelijkheden zijn componenten die worden meegetrokken door de libraries die je direct gebruikt. In een typisch softwareproject zijn er vaak tientallen directe afhankelijkheden en honderden transitieve afhankelijkheden.

Twee standaardformaten domineren het SBoM-landschap. SPDX (Software Package Data Exchange), ontwikkeld door de Linux Foundation, en CycloneDX, ontwikkeld door OWASP. Beide formaten zijn machineleesbaar en worden breed ondersteund door tooling. CISA’s geactualiseerde richtlijnen vereisen het gebruik van een van deze formaten om automatisering van SBoM-generatie en -consumptie in ontwikkelpipelines te faciliteren.

Integreer SBoM-generatie in je CI/CD-pipeline zodat bij elke build automatisch een actuele SBoM wordt aangemaakt. Koppel de SBoM aan een vulnerability database zoals de National Vulnerability Database (NVD) of OSV om automatisch te worden gewaarschuwd wanneer een component in je software een nieuw ontdekte kwetsbaarheid bevat. Sla SBoM’s op als versioned artifacts naast je softwarereleases, zodat je voor elke versie kunt nagaan welke componenten erin zaten. Deel SBoM’s met afnemers van je software als onderdeel van transparante communicatie over supply chain security.

SBoM in de praktijk

In de praktijk worstelen veel organisaties nog met de adoptie van SBoM’s. Volgens onderzoek uit 2026 zijn experts het niet eens over de bruikbaarheid: in theorie zijn SBoM’s waardevol, maar in de praktijk genereren zelfs organisaties met volwassen ontwikkelprocessen onvolledige SBoM’s. De snelle verandering van software-ecosystemen en de complexiteit van het creeren van een end-to-end geverifieerde keten van code belemmeren brede adoptie.

Desondanks groeit het momentum. In het eerste kwartaal van 2026 identificeerde CISA verdere SBoM-toepassingen voor SaaS en AI-systemen. De combinatie van regulatoire druk via de CRA en NIS2, toenemende supply chain aanvallen, en verbeterde tooling maakt dat SBoM’s steeds meer een standaardonderdeel worden van het secure coding proces. Organisaties die nu investeren in SBoM-capaciteit, zijn beter voorbereid op de verplichtingen die eraan komen en kunnen sneller reageren op supply chain kwetsbaarheden.

Begin klein: genereer een SBoM voor je meest kritieke applicatie en analyseer de resultaten. Je zult waarschijnlijk verrast zijn door het aantal componenten en de leeftijd van sommige afhankelijkheden. Gebruik deze inzichten om je patch management voor open-source componenten te verbeteren en verouderde libraries systematisch te updaten.

Naast de technische implementatie is het belangrijk om een SBoM-beleid vast te stellen dat beschrijft hoe je organisatie omgaat met software supply chain security. Dit beleid definieert welke software een SBoM moet hebben, hoe SBoM’s worden opgeslagen en gedeeld, wie verantwoordelijk is voor het monitoren van kwetsbaarheden in dependencies, en hoe snel je reageert wanneer een kritieke kwetsbaarheid wordt ontdekt. Integreer dit beleid in je bredere informatiebeveiligingsbeleid en toets het periodiek aan actuele wet- en regelgeving. Het NCSC biedt richtlijnen voor supply chain security die je kunt gebruiken als uitgangspunt voor je beleid.

Veelgestelde vragen over SBoM

Wat bevat een SBoM precies?

Een SBoM bevat per component minimaal de naam, versie, leverancier, unieke identifier en de relatie tot andere componenten. Daarnaast kunnen licentie-informatie, checksums voor integriteitscontrole en bekende kwetsbaarheden worden opgenomen. De CISA Minimum Elements uit 2025 specificeren de verplichte velden.

Is een SBoM verplicht onder de EU Cyber Resilience Act?

Ja, de CRA verplicht fabrikanten van producten met digitale elementen om een SBoM te produceren en bij te houden in een gestandaardiseerd, machineleesbaar formaat. Dit geldt voor alle software die op de Europese markt wordt gebracht, inclusief open-source componenten.

Welk SBoM-formaat moet je kiezen?

SPDX en CycloneDX zijn beide geaccepteerde standaarden. SPDX wordt meer gebruikt in de open-source wereld en is een ISO-standaard. CycloneDX is populairder in de security-community en biedt uitgebreidere kwetsbaarhedeninformatie. Kies op basis van je tooling en de voorkeuren van je afnemers.

Hoe vaak moet je een SBoM updaten?

Genereer een nieuwe SBoM bij elke softwarerelease of build. In een CI/CD-pipeline betekent dit automatische generatie bij elke commit of merge. Voor productieomgevingen is het belangrijk om SBoM’s periodiek te reconcilieren met actuele vulnerability databases.

Kan een SBoM helpen bij incident response?

Absoluut. Bij een nieuw ontdekte kwetsbaarheid zoals Log4Shell kun je met een SBoM binnen seconden vaststellen welke systemen de getroffen component bevatten. Zonder SBoM moet je handmatig elk systeem onderzoeken, wat bij grote organisaties dagen kan duren en kostbare responstijd verspilt.

Meer weten over software supply chain security? Bekijk Governance, Risk & Compliance oplossingen op IBgidsNL.