SBOM

Wat is een SBOM?

Een SBOM (Software Bill of Materials) is een formele, machineleesbare lijst van alle softwarecomponenten, bibliotheken en hun onderlinge afhankelijkheden in een softwareproduct, firmware of embedded systeem, met per component de leverancier, naam, versie en een unieke identificatie. Een SBOM is te vergelijken met de ingrediëntenlijst op een voedselverpakking of de stuklijst (bill of materials) van een machine: hij beschrijft niet wat software doet, maar waaruit zij is opgebouwd. In OT-omgevingen, waar een PLC, HMI-paneel of gateway vaak tien tot twintig jaar meegaat, is dat inzicht nodig om bij een nieuwe kwetsbaarheid snel te weten welke installaties geraakt zijn.

Moderne software bestaat grotendeels uit hergebruikte open-source- en commerciële componenten. Zonder SBOM weet u niet welke daarvan in uw industriële systemen draaien.

🧠 Waarom is een SBOM belangrijk?

Leveranciers bouwen hun producten zelden van de grond af op. Een HMI-runtime bevat al snel een besturingssysteem, een webserver, een cryptografische bibliotheek zoals OpenSSL, een database en een TCP/IP-stack van een derde partij. Wanneer in één van die componenten een kwetsbaarheid wordt gevonden, moet u weten welke producten haar bevatten. Enkele bekende voorbeelden:

De voordelen van een SBOM op een rij:

• Transparantie - inzicht in alle gebruikte open-source- en commerciële componenten
• Snelle kwetsbaarheidsanalyse - CVE’s koppelen aan bekende bibliotheken en afhankelijkheden
• Beheer van leveranciersrisico’s - begrip van de herkomst van software bij derde partijen, inclusief onderleveranciers en hoog-risicoleveranciers
• Snellere incidentrespons - bij een lek als Log4Shell binnen uren in plaats van weken vaststellen of uw assets geraakt zijn
• Licentiebeheer - zicht op open-sourcelicenties en de verplichtingen die daarbij horen

🔧 Welke gegevens staan in een SBOM?

De Amerikaanse NTIA publiceerde op 12 juli 2021 de Minimum Elements for a Software Bill of Materials, als uitwerking van presidentieel decreet 14028 van mei 2021. Dat document noemt zeven minimale gegevensvelden en is wereldwijd het vertrekpunt geworden:

Naast die velden vraagt NTIA om automatiseringsondersteuning (een machineleesbaar formaat) en vaste werkwijzen: een nieuwe SBOM bij elke nieuwe softwareversie, een duidelijke diepte en een eerlijke vermelding van bekende hiaten. In augustus 2025 publiceerde CISA een conceptupdate die onder meer een hash per component, licentie-informatie, de gebruikte tool en de context van het genereren toevoegt.

CISA onderscheidt verder zes soorten SBOM’s naar het moment van opstellen: Design (gepland ontwerp), Source (uit de broncode), Build (tijdens het compileren), Analyzed (achteraf uit een binair bestand afgeleid), Deployed (wat op een systeem is geïnstalleerd) en Runtime (wat daadwerkelijk wordt geladen). Voor OT-firmware ziet u in de praktijk vooral Build-SBOM’s van de fabrikant en Analyzed-SBOM’s die een asset owner zelf maakt.

🧩 Welke formaten en standaarden zijn er?

Leveranciers leveren een SBOM meestal aan als JSON- of XML-bestand in SPDX- of CycloneDX-formaat. De Duitse BSI-richtlijn TR-03183-2, die vaak als voorbeeld voor de Cyber Resilience Act wordt gebruikt, eist sinds versie 2.1.0 (augustus 2025) minimaal CycloneDX 1.6 of SPDX 3.0.1.

🏭 Hoe ziet een SBOM eruit in de OT-context?

OT kent enkele eigen uitdagingen. Firmware bevat vaak gecompileerde code zonder pakketbeheerder, zodat een Analyzed-SBOM uit binaire analyse onvolledig kan zijn. Veel apparaten in het veld dateren van vóór het SBOM-tijdperk, en een SBOM van de fabrikant beschrijft een productversie, niet uw specifieke installatie met haar eigen firmwarestand. Koppel de SBOM daarom altijd aan de exacte firmware- en softwareversie in uw asset inventory.

🔐 Hoe gebruikt u een SBOM voor cybersecurity?

Een SBOM alleen levert vaak een lange lijst met CVE’s op, waarvan de meeste in het product niet bereikbaar zijn. Pas met VEX-informatie van de fabrikant en context uit uw eigen netwerk ontstaat een werkbare prioriteitenlijst. Een SBOM voorkomt bovendien geen aanval: hij verkort de tijd tussen bekendmaking van een kwetsbaarheid en uw maatregel.

⚖️ Welke wet- en regelgeving vraagt om een SBOM?

Onder de CRA hoeft de fabrikant de SBOM niet openbaar te maken; markttoezichthouders kunnen hem wel opvragen. De Europese Commissie mag via een uitvoeringshandeling het formaat en de minimale inhoud nader vastleggen. Voor afnemers in Nederland ligt de waarde vooral in inkoop: wie onder de Cyberbeveiligingswet valt, moet risico’s in de toeleveringsketen beheersen, en een SBOM is daarvoor een concreet middel. In september 2025 publiceerden 21 cyberbeveiligingsinstanties uit vijftien landen, waaronder CISA, de NSA, het Duitse BSI en het Nederlandse NCSC, een gezamenlijke visie op SBOM’s voor cybersecurity.

✅ Hoe voert u SBOM’s stapsgewijs in?

1. Neem SBOM-eisen op in inkoop - vraag bij elke nieuwe leverancier om een SBOM in SPDX- of CycloneDX-formaat bij elke release, plus VEX- of CSAF-adviezen; leg dit vast in uw Third Party Risk Management en contracten volgens IEC 62443-2-4 en ISO 27036.
2. Koppel SBOM’s aan uw inventaris - sla ze op naast de asset- en versiegegevens in uw Asset Inventory of CMDB, zodat u per installatie weet welke componenten er draaien.
3. Automatiseer de vergelijking - laat een tool zoals het open-source OWASP Dependency-Track de SBOM’s dagelijks met kwetsbaarheidsdatabases vergelijken.
4. Prioriteer met context - combineer de uitkomst met VEX, de KEV-lijst en de netwerkpositie van het apparaat voordat u een patch of compenserende maatregel plant.
5. Vul hiaten aan - voor oudere apparatuur zonder SBOM kunt u een Analyzed-SBOM laten opstellen of de leverancier om een componentenoverzicht vragen.
6. Borg integriteit - combineer SBOM’s met Code Signing, Secure Boot en gecontroleerde updates voor grip op de hele toeleveringsketen.

❓ Veelgestelde vragen

Is een SBOM verplicht?

Een SBOM is verplicht voor fabrikanten van producten met digitale elementen onder de Cyber Resilience Act vanaf 11 december 2027 en in de VS voor medische cyber devices onder de FDA-regels. NIS2 en de Cyberbeveiligingswet verplichten afnemers niet tot een SBOM, maar vragen wel om beheersing van risico’s in de toeleveringsketen. Veel organisaties nemen de SBOM daarom als eis op in hun inkoopvoorwaarden.

Wat is het verschil tussen SPDX en CycloneDX?

SPDX is een SBOM-formaat van de Linux Foundation dat als ISO/IEC 5962 is genormeerd en oorspronkelijk uit licentiebeheer komt. CycloneDX is een SBOM-formaat van OWASP, genormeerd als ECMA-424, dat vanaf het begin op security is gericht en ook VEX ondersteunt. Beide formaten worden door de meeste tools en door de Duitse BSI-richtlijn TR-03183-2 geaccepteerd.

Wat is het verschil tussen een SBOM en VEX?

Een SBOM vertelt welke softwarecomponenten in een product zitten, maar niet of een kwetsbaarheid in zo’n component in dat product ook misbruikt kan worden. Een VEX-document van de fabrikant geeft per kwetsbaarheid aan of het product wel of niet geraakt is. Samen voorkomen SBOM en VEX dat u tijd verliest aan valse positieven.

Moet een fabrikant de SBOM openbaar maken?

Onder de Cyber Resilience Act hoeft een fabrikant de SBOM niet openbaar te maken; hij hoort in het technisch dossier en moet op verzoek aan markttoezichthouders worden gegeven. Afnemers krijgen een SBOM daarom meestal alleen als zij dat contractueel afspreken. Sommige fabrikanten bieden SBOM’s aan via een klantenportaal.

Hoe maakt u een SBOM van bestaande OT-apparatuur?

Voor bestaande OT-apparatuur zonder SBOM van de fabrikant kunt u met binaire analysetools een Analyzed-SBOM afleiden uit firmware-images. Zo’n afgeleide SBOM is vaak onvolledig, omdat statisch gelinkte of aangepaste code moeilijk te herkennen is. Vraag daarom altijd eerst de leverancier om een componentenoverzicht.

Hoe vaak moet een SBOM worden bijgewerkt?

Een SBOM moet worden bijgewerkt bij elke nieuwe software- of firmwareversie, omdat elke release andere componenten of versies kan bevatten. De lijst met bekende kwetsbaarheden verandert echter dagelijks, dus de vergelijking van bestaande SBOM’s met kwetsbaarheidsdatabases moet continu of minimaal dagelijks gebeuren. De SBOM zelf verandert alleen als het product verandert.

📌 Samengevat

Een SBOM is de machineleesbare ingrediëntenlijst van software en firmware: hij maakt zichtbaar wat er écht in uw industriële systemen draait, zodat u bij een nieuwe kwetsbaarheid binnen uren weet welke installaties geraakt zijn.

SPDX en CycloneDX zijn de gangbare formaten, de NTIA-minimumelementen bepalen de basisinhoud en de Cyber Resilience Act maakt de SBOM vanaf december 2027 verplicht voor fabrikanten. Gecombineerd met VEX, een actuele asset inventory en kwetsbaarheidsbeheer vormt de SBOM een fundament voor leverancierstransparantie, cybersecurity en compliance in OT.