Wat is een SBOM?

Waar staat SBOM voor?

SBOM staat voor software bill of materials. De term komt uit de maakindustrie, waar een bill of materials de onderdelen opsomt die in een product gaan. CISA omschrijft een SBOM als een geneste inventaris, een lijst van de ingrediënten waaruit softwarecomponenten bestaan.

De meeste code in een moderne applicatie is door iemand anders geschreven, en het grootste deel daarvan komt er indirect in: u voegt één pakket toe en dat brengt tientallen transitieve afhankelijkheden mee. Een SBOM legt dat allemaal vast, zodat u "zijn wij getroffen?" kunt beantwoorden zonder ook maar één repository te lezen.

Wat staat er in een SBOM?

Een bruikbare SBOM bestaat uit twee delen: gegevens over de SBOM zelf en gegevens over elk component. De 2026 Minimum Elements, op 29 juli 2026 gepubliceerd door CISA, de NSA en de FBI samen met internationale partners, vervangen de NTIA-lijst uit 2021 en vormen de basis waar de meeste kopers nu naar verwijzen.

Deel	Velden
Over de SBOM	Auteur en handtekening van de auteur, tijdstempel, naam en versie van het gegevensformaat, naam en versie van de tool, SBOM-versie en de generatiecontext
Over elk component	Naam, versie, producent, identificatoren zoals een package URL, hashwaarde en algoritme, licentie en afhankelijkheidsrelaties

De generatiecontext is belangrijker dan ze lijkt. Ze vermeldt wanneer de SBOM is gemaakt: vóór de build, tijdens de build, vanuit het afgeronde artefact of daarna. Precies daardoor kunnen twee SBOM's van dezelfde release verschillen. Zie SBOM-voorbeelden voor hoe deze velden er in een echt bestand uitzien.

SBOM-formaten

Twee formaten dekken bijna alle SBOM's die in gebruik zijn. CycloneDX, van OWASP, begon in de beveiliging en beschrijft ook kwetsbaarheden en services. SPDX, van de Linux Foundation, begon bij licentiecompliance. Beide kunnen de minimale elementen bevatten, en de meeste tools schrijven beide. Zie CycloneDX vs SPDX voor hoe u kiest.

Waarom SBOM's ertoe doen

• Snellere incidentrespons. Als er een kwetsbaarheid als Log4Shell opduikt, is de vraag welke van uw producten die bevatten. Met SBOM's is dat een zoekopdracht. Zonder SBOM's is het een project.
• Kwetsbaarheidsmonitoring na de release. Software die bij levering schoon was, kan morgen kwetsbaar zijn. Door opgeslagen SBOM's opnieuw te toetsen aan nieuwe advisories ziet u dat, zonder iets opnieuw te bouwen.
• Licentierisico. De gedeclareerde licentie van elk component toont copyleft- of commerciële voorwaarden voordat ze in het product belanden.
• Vragen van klanten en toezichthouders. Kopers vragen bij inkoop steeds vaker om een SBOM, en verschillende kaders verwachten een inventaris van componenten.

Wie heeft een SBOM nodig?

Iedereen die software levert, en iedereen die verantwoording moet afleggen over wat erin zit. De eis komt meestal via een van deze routes:

• Medische hulpmiddelen. FDA section 524B vereist een SBOM voor cyber devices in aanvragen voor markttoelating.
• Producten die in de EU worden verkocht. De Cyber Resilience Act vraagt fabrikanten om een SBOM. Zie SBOM-eisen van de CRA en tools.
• Federale inkoop in de VS. Het OMB-memo M-26-05 van januari 2026 laat elk agentschap zelf beslissen of het er een eist, dus reken op een beslissing per geval.
• Betaalsoftware. Eis 6.3.2 van PCI DSS 4.0 vraagt om een inventaris van maatwerksoftware en de componenten van derden daarin. De eis schrijft geen SBOM voor, maar een SBOM voldoet aan de behoefte.

Hoe genereert u een SBOM?

Er zijn drie manieren om er een te maken, en de methode bepaalt wat er in het bestand terechtkomt.

Methode	Wat ze leest	Typisch hiaat
De broncode scannen	Manifests en lockfiles in de repository	Alles wat de build ophaalt en dat in geen enkele lockfile staat
De output scannen	Een afgeronde containerimage of binary	Gecompileerde code is ambigu, en buildtools laten geen spoor na
De build vastleggen	Wat de build daadwerkelijk heeft opgehaald terwijl hij draaide	Verkeer dat buiten de vastlegging om gaat; dat hoort te worden gemeld

Open-sourcegeneratoren zoals Syft, Trivy en cdxgen gebruiken de eerste twee methoden. Ze spreken elkaar tegen op dezelfde commit, omdat elk zijn eigen regels heeft voor wat er gelezen wordt. Voor de opties naast elkaar, zie de beste SBOM-tools.

SBOM vs SCA vs VEX

• Een SBOM is een inventaris. Hij zegt wat er is, niet of het veilig is.
• Software composition analysis is de analyse. Die spoort componenten op en controleert ze op risico's, en veel SCA-tools produceren daarbij ook een SBOM.
• VEX is een verklaring over de impact. Die zegt of een bekende kwetsbaarheid uw product daadwerkelijk raakt, wat de ruis vermindert die een SBOM op zichzelf oplevert.

Een SBOM genereren is het makkelijke deel

Een bestand dat niemand leest, verandert niets. De waarde zit in één SBOM per release bewaren, ze monitoren en ze kunnen vinden wanneer het erop aankomt. Dat werk heet SBOM-beheer, en SBOM best practices beschrijft hoe u dat aanpakt.

Hoe CRACI SBOM's maakt

CRACI is een GitHub Actions-runner die elk pakket vastlegt dat een job ophaalt, op elk niveau van de boom en inclusief pakketten die uit CI-caches zijn teruggezet. Het resultaat is een SBOM van de build die de release heeft opgeleverd, met een volledigheidsstatus die aangeeft wat de job niet kon zien. Hij wordt geëxporteerd als CycloneDX of SPDX, en CRACI blijft hem opnieuw beoordelen zodra nieuwe kwetsbaarheden worden gepubliceerd. Zie build-time SBOM-generatie.

SBOM: veelgestelde vragen

Wat is een SBOM in eenvoudige woorden?

Een SBOM is een ingrediëntenlijst voor software. Hij noemt elk component in een product, met versie, producent en licentie, in een formaat dat machines kunnen lezen.

Waar staat SBOM voor?

SBOM staat voor software bill of materials.

Waarom hebt u een SBOM nodig?

Zodat u snel kunt zien of een nieuw gepubliceerde kwetsbaarheid raakt wat u levert, licentierisico's vóór de release ziet, en klanten en toezichthouders kunt antwoorden die vragen wat er in uw product zit.

Wat zijn de twee belangrijkste SBOM-formaten?

CycloneDX en SPDX. CycloneDX komt van OWASP en begon in de beveiliging. SPDX komt van de Linux Foundation en begon bij licentiecompliance. Beide kunnen de minimale elementen bevatten.

Is een SBOM wettelijk verplicht?

Dat hangt af van het product en de markt. FDA section 524B vereist er een voor cyber devices, en de EU Cyber Resilience Act vraagt fabrikanten erom. Bij federale inkoop in de VS beslist nu elk agentschap zelf. Voor veel andere bedrijven is het eerder een eis van klanten dan een wettelijke eis.

Hoe vaak moet een SBOM worden bijgewerkt?

Genereer voor elke release een nieuwe SBOM, omdat elke build andere versies kan binnenhalen. De SBOM van een release verandert daarna niet meer, maar u moet hem wel blijven toetsen aan nieuwe kwetsbaarheden.

Wie maakt de SBOM?

Meestal het team dat de software bouwt, bij voorkeur in CI, zodat elke release er automatisch een krijgt. Software die u koopt, hoort met een SBOM van de leverancier te komen.