Uw klant wil een SBOM: een gids voor leveranciers van componenten en software

Deze gids is voor leveranciers binnen een productieketen: ECU's, displays, controllers, gateways, aandrijvingen, embedded Linux-stacks en firmwaremodules. Verkoopt u software en stuurde een klant een eenmalig verzoek, begin dan met hoe u een SBOM-verzoek van een klant beantwoordt, dat die situatie behandelt.

Waarom OEM's er nu om vragen

Het SBOM-verzoek van een OEM is meestal de regelgeving van die OEM die via een contract bij u aanklopt. Welke regelgeving dat is, bepaalt wat de OEM moet hebben en hoeveel daarvan aan u wordt doorgegeven.

De Cyber Resilience Act

Onder de Cyber Resilience Act, Verordening (EU) 2024/2847, omvat een product met digitale elementen ook software- of hardwarecomponenten die afzonderlijk in de handel worden gebracht (artikel 3, punt 1). Een component dat u zelfstandig in de EU verkoopt, is een product op zich, en u bent de fabrikant, met uw eigen SBOM-verplichting: bijlage I, deel II, punt 1, vraagt om een SBOM in een algemeen gebruikt, machineleesbaar formaat dat ten minste de afhankelijkheden op het hoogste niveau van de producten dekt. Is het component bedoeld om in andere producten te worden geïntegreerd, dan moeten uw instructies ook de informatie geven die de integrator nodig heeft om aan de essentiële eisen te voldoen (bijlage II, punt 8, f)).

De OEM heeft verplichtingen die u ook raken. Hij moet gepaste zorgvuldigheid betrachten bij het integreren van componenten van derden (artikel 13, lid 5), en als hij een kwetsbaarheid vindt in een component dat hij heeft geïntegreerd, moet hij die melden aan de persoon of entiteit die het component maakt of onderhoudt (artikel 13, lid 6). De CRA-richtsnoeren van de Commissie van juli 2026 zeggen dat bewijs van zorgvuldigheid "may consist of documentation obtained from the component manufacturer", en noemen geen SBOM's; in de praktijk is een SBOM vaak de documentatie waar OEM's om vragen. De meldplichten gelden vanaf 11 september 2026 en de verordening geldt volledig vanaf 11 december 2027. Reserveonderdelen die volgens dezelfde specificatie zijn gemaakt als de componenten die ze vervangen, zijn uitgezonderd (artikel 2, lid 6). Voor de rest van de verordening, zie wat de CRA is en de CRA-gids.

Voertuigen

De CRA geldt niet voor producten die onder Verordening (EU) 2019/2144 vallen, de verordening voor de typegoedkeuring van voertuigen (artikel 2, lid 2, punt c)). Componenten voor typegoedgekeurde voertuigen komen in plaats daarvan onder voertuigregels op de markt, en die regels noemen nergens een SBOM.

• VN-Reglement nr. 155 (cyberbeveiliging) verplicht de fabrikant informatie te verzamelen en te verifiëren "through the supply chain so as to demonstrate that supplier-related risks are identified and are managed" (5.1.1(a)), te laten zien hoe zijn managementsysteem voor cyberbeveiliging "will manage dependencies that may exist with contracted suppliers, service providers or manufacturer's sub-organizations" (7.2.2.5) en "identify and manage, for the vehicle type being approved, supplier-related risks" (7.3.2).
• VN-Reglement nr. 156 (software-updates) vereist dat alle oorspronkelijke en bijgewerkte softwareversies uniek identificeerbaar zijn (7.1.1.2) en, voor elk RX Software Identification Number (RXSWIN), "an auditable register describing all the software relevant to the RXSWIN" (7.1.2.3).
• ISO/SAE 21434 organiseert het cyberbeveiligingswerk tussen OEM en leverancier als gedistribueerde activiteiten, met de verdeling vastgelegd in een cybersecurity interface agreement.
• Het Auto-ISAC SBOM Informational Report (februari 2025) geeft de eigen richtlijnen van de sector.

In de automotive komt een SBOM binnen als contractuele eis, niet als wettelijke.

Industriële automatisering

IEC 62443-4-1 geldt voor leveranciers van producten voor industriële automatisering en besturingssystemen. De norm noemt geen SBOM's, maar practice 6, het beheer van beveiligingsgerelateerde issues (DM-1 tot en met DM-6), en practice 7, het beheer van beveiligingsupdates (SUM-1 tot en met SUM-5, inclusief SUM-3, "Dependent component or operating system security update documentation"), zijn waar een SBOM als bewijs dient.

Machines

Verordening (EU) 2023/1230 betreffende machines geldt vanaf 20 januari 2027 en noemt geen SBOM's. De essentiële eisen voor bescherming tegen corruptie (bijlage III, 1.1.9) vragen dat software die kritiek is voor de naleving wordt geïdentificeerd en beschermd, dat de machine de daarop geïnstalleerde software kan identificeren die nodig is om veilig te werken, en dat bewijs van ingrepen in die software wordt verzameld. Machines met digitale elementen vallen ook onder de CRA, anders dan typegoedgekeurde voertuigen, en daarom vragen machinebouwers hun leveranciers nu om SBOM's. Zie CRACI voor machinebouwers en industriële IoT.

NIS2 en gecertificeerde klanten

Levert u aan essentiële of belangrijke entiteiten, bijvoorbeeld in de halfgeleiderindustrie, dan verplicht NIS2 artikel 21, lid 2, punt d), uw klant om ketenbeveiliging aan te pakken. Het noemt geen SBOM's. Klanten vertalen het in vragenlijsten, en de Annex A-controls 5.21 en 8.8 van ISO/IEC 27001 zijn waar een SBOM als bewijs dient. Zie SBOM's als bewijs voor ISO 27001, SOC 2 en NIS2.

De regimes naast elkaar

Regime	Geldt voor	Noemt een SBOM?	Wat de leverancier bereikt
Cyber Resilience Act	Producten met digitale elementen op de EU-markt, inclusief afzonderlijk verkochte componenten	Ja, bijlage I, deel II (1)	Rechtstreeks als u het component in de handel brengt; via de zorgvuldigheid van de OEM (art. 13, lid 5) en meldingen van kwetsbaarheden (art. 13, lid 6)
UN R155 en R156	Voertuigfabrikanten die typegoedkeuring aanvragen	Nee	Risicobeheer voor leveranciers (R155 7.2.2.5, 7.3.2) en software-identificatie (R156), via contracten
ISO/SAE 21434	Cyberbeveiligingsengineering van wegvoertuigen, OEM's en leveranciers	Niet in de openbare beschrijving	Gedistribueerde activiteiten en een cybersecurity interface agreement
IEC 62443-4-1	Leveranciers van producten voor industriële automatisering en besturingssystemen	Nee	Rechtstreeks als u de productleverancier bent; SBOM's dienen als bewijs voor DM en SUM
Verordening machines	Machines en aanverwante producten op de EU-markt	Nee	Identificatie en bescherming van software (bijlage III 1.1.9); de CRA geldt ernaast
NIS2	Essentiële en belangrijke entiteiten	Nee	Vragenlijsten over ketenbeveiliging en contractvoorwaarden (art. 21, lid 2, punt d), en lid 3)

Welke route het ook is, de klant heeft hetzelfde nodig: een nauwkeurige SBOM voor elke softwareversie die u levert.

Waar OEM's doorgaans om vragen

De eisen verschillen per OEM, maar komen uit op dezelfde lijst. Controleer uw SBOM ertegen vóór de eerste levering.

Eis	Gebruikelijke verwachting
Formaat	CycloneDX of SPDX, JSON of XML, met een minimale specversie. BSI TR-03183-2 stelt CycloneDX 1.6 of hoger, of SPDX 3.0.1 of hoger.
Velden	In lijn met de CISA 2026 Minimum Elements of BSI TR-03183-2: auteur, tijdstempel, en per component een naam, versie, producent en identifiers
Identifiers	Een package URL waar het ecosysteem er een heeft, een CPE waar niet, zodat componenten met kwetsbaarheidsdatabases kunnen worden gematcht
Licenties	SPDX-licentie-identifiers. De licentiespecialist van de OEM leest ze om copyleft en ander licentierisico te beoordelen.
Hashes	Een hash van elke geleverde binary, zodat de OEM kan bevestigen dat de SBOM het ontvangen bestand beschrijft. BSI vraagt om SHA-512.
Diepte	Transitieve afhankelijkheden, niet alleen het hoogste niveau
Granulariteit	Eén SBOM per geleverde softwareversie of onderdeelnummer
Levering en reactie	Een leveringskanaal, en reactietijden voor vragen over kwetsbaarheden

Veel OEM's controleren dit automatisch bij ontvangst. Zie de SBOM-kwaliteitschecklist voor wat uw klant controleert en met welke tools, en SBOM-voorbeelden voor hoe de velden er in een bestand uitzien.

Uw SBOM als er weinig of geen open source in zit

Een bare-metal ECU of controller met propriëtaire firmware uit modelgebaseerde codegeneratie heeft een eerlijke SBOM die kort kan zijn: de propriëtaire applicatie, uw bootloader, libraries of kalibratie van een chipleverancier, en eventuele open source zoals een cryptografische library. Dat is een geldig antwoord. De regels:

• Vermeld propriëtaire componenten met uw eigen identifiers: naam, versie en uzelf als producent.
• Vermeld de bekende onbekenden, zoals een library van een leverancier waarvan u de inhoud niet kunt zien.
• Blaas de SBOM nooit op om grondig te lijken, en laat nooit een open-sourcelibrary weg omdat hij klein is.

Voor displays en gateways op basis van Linux geldt het omgekeerde: honderden of duizenden componenten, inclusief de kernel, de bootloader en de basissysteempakketten (zie verbonden apparaten). Een SBOM die alleen uw applicatie en een paar libraries vermeldt, is het eerste wat een ontvangend team aanmerkt. Bouwt u met Yocto, zie dan waarom scanners missen wat in Yocto-builds zit.

Contracten: wat u vóór de eerste levering afspreekt

Voorwaarde	Waarom het ertoe doet
Producten en softwareversies die eronder vallen	Zodat niemand later discussieert over de vraag of een variant of een servicerelease een SBOM nodig had
Formaat en specversie	Hun intakepipeline kan al het andere afwijzen
Velden en het framework dat ze volgen	"BSI TR-03183-2 v2.1.0" of "CISA 2026 Minimum Elements" is toetsbaar; "een volledige SBOM" niet
Aanleiding voor levering	Elke release, elke softwareversie die aan de OEM wordt geleverd, en elke correctie
Leveringskanaal	Het leveranciersportaal van de OEM, beveiligde bestandsuitwisseling of e-mail onder NDA
Vertrouwelijkheid	Een NDA of de bestaande leveringsovereenkomst, waarin de SBOM als vertrouwelijke informatie wordt genoemd
Gebruiksbeperkingen	Alleen voor kwetsbaarheidsbeheer en naleving, niet verder delen zonder toestemming
Melding van kwetsbaarheden, in beide richtingen	De OEM meldt kwetsbaarheden die hij in uw component vindt (CRA art. 13, lid 6); u meldt de uwe aan hem
Verwachtingen rond VEX	Welk formaat, en hoe snel u een nieuwe CVE beoordeelt
Bewaartermijn	Hoelang u de SBOM van elke versie bewaart, afgestemd op de ondersteuningsperiode van het product
Nauwkeurigheid en bekende onbekenden	Een eerlijke clausule over wat de SBOM wel en niet kan dekken, beschermt beide partijen

De SBOM Sharing Primer van CISA beschrijft de automotive op dezelfde manier: SBOM-verzoeken "would be included in standard information exchange agreements (e.g., non-disclosure agreement, cybersecurity interface agreement, development interface agreement)".

Delen zonder IP prijs te geven

Een SBOM is niet uw broncode. Hij vermeldt namen, versies, producenten, licenties, hashes en relaties van componenten. Hij bevat niet uw code, uw algoritmes, uw kalibratiedata of uw ontwerp.

• De CRA verplicht fabrikanten niet om de SBOM openbaar te maken (overweging 77). Hij gaat op een met redenen omkleed verzoek naar een markttoezichtautoriteit (bijlage VII, punt 8).
• De richtlijnen van CISA voor delen beschrijven de gebruikelijke kanalen voor propriëtaire software: e-mail onder een NDA, het leveranciersportaal van de klant of een beveiligde documentuitwisseling, of een eigen portaal met toegangsbeheer, waarbij contracten de vertrouwelijkheid en toegang regelen.
• Praktische opties: één volledige SBOM per OEM onder contract; identifiers voor propriëtaire onderdelen die geen interne projectnamen prijsgeven; en een apart VEX-document, zodat u de status van een kwetsbaarheid kunt bijwerken zonder de SBOM opnieuw te sturen.

Hoe vaak, en wat er na de levering gebeurt

• Een nieuwe SBOM voor elke softwareversie die u levert, onder dezelfde identifier die de OEM flasht of registreert. Bij voertuigen sluit dat aan op de software-identificatie van R156.
• Een gecorrigeerde SBOM wanneer u een fout vindt in een SBOM die u hebt gestuurd.
• Een VEX-verklaring of een advisory wanneer u een kwetsbaarheid hebt beoordeeld.

De vervolgvraag, "bent u getroffen door CVE-X?", komt met de volgende grote kwetsbaarheid. Zorg dat u hem per geleverde versie kunt beantwoorden, wat alleen kan als u de SBOM van elke versie hebt bewaard.

VEX: wat uw klant hierna verwacht

Een VEX-document zegt of een product door een kwetsbaarheid wordt geraakt. De Minimum Requirements for VEX van CISA (april 2023) definiëren vier statussen: not_affected, affected, fixed en under_investigation. Een not_affected-verklaring hoort een van vijf onderbouwingen te geven, of anders een impactverklaring:

• component_not_present
• vulnerable_code_not_present
• vulnerable_code_not_in_execute_path
• vulnerable_code_cannot_be_controlled_by_adversary
• inline_mitigations_already_exist

Een affected-verklaring heeft een actieverklaring nodig: wat de klant moet doen. VEX bestaat in drie formaten: het VEX-profiel van CSAF 2.0, CycloneDX VEX en OpenVEX. De SPDX 3.0-uitvoer van Yocto bevat standaard VEX-gegevens (de variabele SPDX_INCLUDE_VEX).

Uitgewerkt voorbeeld. Een display op basis van Linux levert OpenSSL 3.0.8. CVE-2023-0464 beschrijft buitensporig gebruik van resources bij het verifiëren van X.509-certificaatketens met policy constraints. Policy processing staat standaard uit, en de software van het display schakelt het nooit in. De leverancier stuurt een illustratieve OpenVEX-verklaring:

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://example.com/vex/display-fw-5.3.0-2023-0464",
  "author": "Example Displays Product Security",
  "timestamp": "2026-11-11T09:00:00Z",
  "version": 1,
  "statements": [
    {
      "vulnerability": { "name": "CVE-2023-0464" },
      "products": [{ "@id": "pkg:generic/example/[email protected]" }],
      "status": "not_affected",
      "justification": "vulnerable_code_not_in_execute_path",
      "impact_statement": "X.509 policy processing is disabled by default and the firmware never enables it."
    }
  ]
}

SBOM's herhaalbaar maken

Hoe u bouwt	Realistische manier om de SBOM te maken
Software gebouwd in CI	Genereer de SBOM in de build die de geleverde software oplevert, en bewaar hem bij de release
Embedded Linux op basis van Yocto	De eigen SPDX-uitvoer van Yocto (create-spdx), gecontroleerd op wat hij weglaat, of een vastlegging van de Yocto-build
Bare-metal firmware uit modelgebaseerde tools	Een generatorlibrary of -tool, nooit een teksteditor, bijgehouden bij elke release en gevalideerd vóór verzending
Binaries van derden die u integreert	Vraag uw eigen leverancier om zijn SBOM; binaire analyse als vervanging tot die er is

Welke route het ook is, valideer het bestand voordat u het verstuurt. De SBOM-kwaliteitschecklist noemt de validators die uw klant waarschijnlijk draait, CycloneDX vs SPDX helpt bij het formaat, en SBOM-generatie standaardiseren gaat over hoe u het voor alle teams gelijk maakt.

Waar CRACI past

Voor leveranciers die op GitHub Actions bouwen, vervangt CRACI de door GitHub gehoste runners en legt het van elke build een SBOM vast, zodat elke geleverde versie er al een heeft.

• De SBOM vermeldt wat de build daadwerkelijk heeft binnengehaald, inclusief transitieve afhankelijkheden, met een package URL per pakket en de gedeclareerde licentie van elk component.
• De SBOM van elke job heeft een volledigheidsstatus, zodat u weet wat u stuurt voordat u het stuurt.
• SBOM's worden geëxporteerd als CycloneDX of SPDX, en CRACI ondersteunt VEX.
• Gemonitorde SBOM's worden opnieuw beoordeeld zodra nieuwe kwetsbaarheden worden gepubliceerd, en de buildgeschiedenis toont binnen uw bewaartermijn welke builds een kwetsbare afhankelijkheid bevatten.
• Yocto-builds draaien op CRACI-runners en zijn gedocumenteerd.
• SBOM's van derden kunnen worden toegevoegd, zodat ingekochte componenten samen met uw eigen builds worden gemonitord.

Wanneer CRACI niet het antwoord is

• U hebt geen CI, of u bouwt op GitLab, Jenkins of een buildserver. CRACI ondersteunt vandaag alleen GitHub Actions; andere CI-systemen staan op de roadmap.
• Uw firmware wordt gegenereerd uit modelgebaseerde tools zonder dat er pakketten worden opgehaald. Een buildrecorder voegt daar weinig toe.
• U moet SBOM's voor veel OEM's in een deelportaal hosten, of SBOM's ondertekenen. CRACI biedt geen van beide.
• Uw builds moeten op uw eigen infrastructuur draaien. Door de klant gehoste runners staan op de roadmap.
• Uw klant wil bewijs van het beveiligingsmanagement van uw organisatie, zoals een ISO 27001-certificaat of antwoorden op een NIS2-vragenlijst. Een SBOM is bewijs voor een deel daarvan, geen certificering. Het eigen ISO 27001-certificaat van CRACI dekt de dienst van CRACI, niet de uwe.

SBOM's voor leveranciers: veelgestelde vragen

Mijn klant, een OEM, vroeg om een SBOM. Ben ik verplicht er een te leveren?

Vaak eist het contract het, eerder dan de wet. Brengt u zelf een component met digitale elementen op de EU-markt, dan vereist de Cyber Resilience Act uw eigen SBOM. Anders ligt de verplichting bij de OEM, die haar via zorgvuldigheidsonderzoek en de leveringsovereenkomst aan u doorgeeft.

Geldt de CRA voor componenten die ik aan een fabrikant verkoop?

Als u het component afzonderlijk op de EU-markt brengt, ja: artikel 3, punt 1, omvat software- of hardwarecomponenten die afzonderlijk in de handel worden gebracht. Komt het alleen in het product van de OEM op de markt, dan is de OEM de fabrikant en moet die gepaste zorgvuldigheid betrachten bij uw component (artikel 13, lid 5). Componenten van typegoedgekeurde voertuigen vallen buiten de CRA (artikel 2, lid 2, punt c)).

Vereist UN R155 of ISO/SAE 21434 een SBOM?

Nee. R155 noemt nergens een SBOM; het verplicht de voertuigfabrikant om risico's bij leveranciers te beheren. ISO/SAE 21434 organiseert het cyberbeveiligingswerk met leveranciers via interface agreements. In de automotive komen SBOM's binnen als contractuele eis.

Welk formaat en welke velden verwacht een OEM?

Meestal CycloneDX of SPDX in JSON of XML, in lijn met de CISA 2026 Minimum Elements of BSI TR-03183-2: auteur en tijdstempel, en per component een naam, versie, producent, package URL of CPE, licentie en hash, met transitieve afhankelijkheden.

Hoe vaak moet ik een bijgewerkte SBOM sturen?

Voor elke softwareversie die u levert, telkens als u een fout corrigeert, en met een VEX-verklaring of advisory als u een kwetsbaarheid hebt beoordeeld. Leg de aanleiding vast in het contract.

Geven we met het delen van een SBOM ons intellectueel eigendom prijs?

Nee. Een SBOM vermeldt namen, versies, producenten, licenties, hashes en relaties van componenten, geen broncode, algoritmes of kalibratiedata. Deel hem onder een NDA of de leveringsovereenkomst, met gebruik beperkt tot kwetsbaarheidsbeheer en naleving. De CRA eist niet dat hij openbaar is.

Wat is VEX, en gaat mijn klant erom vragen?

VEX geeft aan of een product door een kwetsbaarheid wordt geraakt: not_affected, affected, fixed of under_investigation, met een onderbouwing bij not_affected. Reken erop dat u er een moet leveren na de volgende breed uitgemeten kwetsbaarheid in een component dat u levert.

Onze ECU-firmware bevat geen open source. Hoe ziet onze SBOM eruit?

Kort en eerlijk: de propriëtaire applicatie, de bootloader, eventuele libraries of kalibratie van een chipleverancier, en eventuele open source zoals een cryptografische library, elk met uw eigen identifiers, plus de bekende onbekenden. Blaas hem niet op.