SBOM (softwarestuklijst) — wat de Cyber Resilience Act vereist

Een softwarestuklijst is een saai artefact met buitenproportionele gevolgen. Het is een lijst: uit welke componenten de software van een product is opgebouwd, in welke versies, van welke leveranciers, onder welke licenties. Tot voor kort was het een intern gemak van het engineeringteam. Met Verordening (EU) 2024/2847 — de Cyber Resilience Act — wordt het een essentiële eis, en wel een die markttoezichtautoriteiten kunnen opvragen.

De reden is eenvoudig. Wanneer er een kwetsbaarheid in een veelgebruikte bibliotheek wordt gepubliceerd, telt maar één vraag: raakt dit ons? Zonder stuklijst kost het antwoord weken handmatige archeologie door repository’s en buildservers. Mét stuklijst kost het één query. De CRA maakt van die operationele werkelijkheid een juridische plicht — en zoals bij vrijwel alle verplichtingen rond productdata gaat het veel minder om het eenmalig schrijven van een document dan om het over elke release heen tien jaar lang kloppend houden van gegevens. Dat is dezelfde discipline die het digitaal productpaspoort elders in het EU-productrecht verlangt.

De belangrijkste punten

De SBOM-verplichting staat in bijlage I deel II van de CRA, bij de eisen voor het omgaan met kwetsbaarheden. Zij geldt volledig vanaf 11 december 2027.
De juridische ondergrens is bescheiden: een gangbaar, machineleesbaar formaat dat ten minste de afhankelijkheden op het hoogste niveau dekt en actueel wordt gehouden. De verordening noemt geen specifiek formaat.
In de praktijk betekent dat CycloneDX (OWASP, genormeerd als ECMA-424) of SPDX (Linux Foundation, ISO/IEC 5962:2021). SWID-tags (ISO/IEC 19770-2) zijn een identificatie voor softwarebeheer, geen volledige inventaris van afhankelijkheden.
Er is geen plicht om de SBOM aan klanten te publiceren. Zij moet op verzoek beschikbaar zijn voor markttoezichtautoriteiten en maakt deel uit van de technische documentatie uit bijlage VII.
De technische documentatie moet ten minste tien jaar na het in de handel brengen ter beschikking van de autoriteiten blijven, of gedurende de ondersteuningsperiode als die langer is.
De Duitse BSI TR-03183-2 gaat aanzienlijk verder dan de CRA-ondergrens: recursieve resolutie van de volledige afhankelijkheidsboom, SHA-512-hashes en een vastgelegde veldenset. Het is geen bindend recht, maar wel de meest concrete gepubliceerde referentie — en inkopers beroepen zich er steeds vaker op.
Een SBOM die niet aan een concrete productversie is gekoppeld, bewijst niets. Versioneren in plaats van overschrijven is de hele kern.
De CRA vereist geen SBOM in het digitaal productpaspoort. Wat zij wel vereist is productdata op versieniveau die een decennium meegaat — hetzelfde probleem, opgelost met hetzelfde gereedschap.

Wat een SBOM eigenlijk is

Zonder het acroniem is een SBOM een inventaris met herkomst. Voor elke component die in het geleverde product terechtkomt legt zij minimaal vast hoe de component heet, welke versie het is en wie hem geleverd heeft. Betere stuklijsten voegen de licentie toe, een cryptografische hash waarmee de component eenduidig te identificeren is, en de afhankelijkheidsrelaties — welke component welke andere heeft binnengehaald.

Het onderscheid dat het meest telt is diepte. Een SBOM op hoogste niveau somt op wat de eigen code direct declareert: de twaalf bibliotheken in het manifestbestand. Een transitieve SBOM lost op wat die twaalf meebrengen, en wat díe weer meebrengen, tot aan de bladeren. In echte toepassingen worden twaalf gedeclareerde afhankelijkheden routinematig enkele honderden feitelijke. Kwetsbaarheden zitten net zo vaak vier niveaus diep als aan de oppervlakte — precies daarom is het verschil tussen de CRA-ondergrens en wat een bruikbare SBOM bevat niet academisch.

Het tweede onderscheid is wanneer zij wordt gemaakt. Een SBOM die uit de broncode wordt gegenereerd beschrijft wat de ontwikkelaars bedoelden. Een SBOM die uit het buildresultaat wordt gegenereerd beschrijft wat er werkelijk is uitgeleverd, inclusief componenten die het buildsysteem, de basiscontainerimage of het binaire pakket van een leverancier hebben ingebracht. Die twee lopen vaker uiteen dan teams verwachten, en alleen de tweede is bewijs.

Wat de CRA vereist — en wat niet

Bijlage I deel II van Verordening (EU) 2024/2847 beschrijft de eisen rond het omgaan met kwetsbaarheden waaraan een fabrikant gedurende de hele ondersteuningsperiode moet voldoen. De eerste daarvan is de stuklijst: fabrikanten moeten de in het product opgenomen componenten identificeren en documenteren, onder meer door een softwarestuklijst op te stellen in een gangbaar, machineleesbaar formaat dat ten minste de afhankelijkheden op het hoogste niveau dekt, en die actueel te houden.

Drie onderdelen van die zin verdienen nauwkeurig lezen.

„Gangbaar, machineleesbaar formaat.” De verordening noemt bewust geen formaat. Dat is standaardpraktijk in het EU-productrecht: de wettekst benoemt de eigenschap, geharmoniseerde normen vullen het technische detail in. In de praktijk is het veld ingedikt tot twee formaten, en beide keuzes zijn verdedigbaar.

„Ten minste de afhankelijkheden op het hoogste niveau.” Dat is een ondergrens, geen doel. De wet verplicht niet tot het oplossen van de volledige transitieve boom. Zij weerhoudt een autoriteit, een certificatie-instantie of een grote zakelijke klant er echter niet van meer te vragen — en zij maakt een SBOM die alleen het hoogste niveau bevat niet bruikbaar voor het doel waarvoor zij bestaat. Behandel de ondergrens als het nalevingsminimum en de transitieve boom als de operationele eis.

„Actueel houden.” De verplichting is doorlopend en loopt over de ondersteuningsperiode. Een stuklijst die eenmalig voor het technisch dossier is gemaakt en nooit opnieuw gegenereerd, wijkt bij de eerste patchrelease al af van de werkelijkheid.

Wat de CRA niet vereist is even belangrijk:

Geen publicatieplicht. De SBOM openbaar maken is een commerciële beslissing. De juridische plicht is: op verzoek beschikbaar stellen aan het markttoezicht. Sommige sectoren en grote inkopers zullen haar contractueel eisen — dat is een andere druk, geen juridische.
Geen voorgeschreven formaat of profiel. Geen gebod CycloneDX tegenover SPDX, geen minimumlijst van velden in de verordening zelf.
Geen SBOM in het productpaspoort. De CRA creëert geen paspoort, geen gegevensdrager en geen register.

Formaten: CycloneDX, SPDX en SWID

	CycloneDX	SPDX	SWID-tags
Herkomst	OWASP	Linux Foundation	ISO/IEC
Norm	ECMA-424	ISO/IEC 5962:2021	ISO/IEC 19770-2
Ontworpen voor	applicatiebeveiliging	licentienaleving en herkomst	softwarebeheer
Typische sterkte	kwetsbaarheidsprocessen, CI/CD, VEX	bestands- en fragmentniveau, inkoop	identificatie van geïnstalleerde software
Volledige afhankelijkheidsinventaris	ja	ja	niet het doel

CycloneDX komt uit de applicatiebeveiliging en is vanaf het begin voor beveiligingstoepassingen gebouwd. Het praktische voordeel is het ecosysteem eromheen: het strekt zich uit tot stuklijsten voor hardware, SaaS, machine learning en cryptografie, en het draagt VEX — Vulnerability Exploitability eXchange — waarmee je machineleesbaar kunt vastleggen dat een bekende kwetsbaarheid in een genoemde component in jouw product helemaal niet uitbuitbaar is. Voor een fabrikant met CRA-verplichtingen rond kwetsbaarheden is „aanwezig maar niet uitbuitbaar, en dit is waarom” in machineleesbare vorm heel veel bespaard werk waard.

SPDX komt uit de licentienaleving en draagt die erfenis als diepte: het beschrijft software tot op het niveau van afzonderlijke bestanden en codefragmenten, en is de natuurlijke keuze wanneer inkoop, juridische toetsing en formele documentatie de eis aanjagen.

SWID-tags duiken op in vrijwel elke formaatvergelijking en in sommige officiële richtsnoeren, maar lossen een ander probleem op: het identificeren van geïnstalleerde software op een machine. Zij vervangen geen inventaris van afhankelijkheden.

Het eerlijke antwoord over de keuze: beide leidende formaten naderen elkaar, gereedschappen ondersteunen ze allebei en converters bestaan. Kies wat je bestaande toolchain het betrouwbaarst genereert en standaardiseer daarop. Een kapotte SBOM in het „betere” formaat is slechter dan een correcte in een van beide.

De gegevensvelden — drie referentiepunten

De CRA geeft een ondergrens. Drie gepubliceerde documenten zeggen wat een serieuze SBOM werkelijk bevat.

De Duitse referentie: BSI TR-03183-2

Het Duitse federale bureau voor informatiebeveiliging publiceert de Technische richtlijn TR-03183: cyberweerbaarheidseisen voor fabrikanten en producten, deel 2: softwarestuklijst (SBOM). Het is geen bindend recht, maar wel de meest concrete openbare specificatie die uitdrukkelijk tegen de CRA is geschreven, en zij wordt steeds vaker aangehaald in Duitse leveranciersvragenlijsten. Versie 2.1.0 verscheen in augustus 2025.

Vereist is serialisatie in JSON of XML, in CycloneDX versie 1.6 of hoger of SPDX versie 3.0.1 of hoger. De velden vallen in drie categorieën: verplicht (altijd), aanvullend (verplicht zodra het onderliggende gegeven bestaat) en optioneel.

Verplicht op documentniveau:

opsteller van de SBOM — e-mailadres of URL die de producent identificeert,
tijdstempel in ISO 8601-formaat.

Verplicht per component:

naam van de component,
versie van de component,
opsteller van de component, dus de leverancier,
bestandsnaam van de component,
afhankelijkheden van andere componenten — recursief opgelost,
distributielicenties,
hash van de uitrolbare component, SHA-512,
of de component uitvoerbaar is, of het een archief is, of het gestructureerd is.

Let op de afstand tot de CRA-tekst. Recursieve resolutie van de hele afhankelijkheidsboom is aanzienlijk meer werk dan alleen het hoogste niveau, en de SHA-512-eis dwingt de SBOM uit echte buildartefacten te genereren in plaats van uit een manifestbestand. Wie aan de Duitse markt levert, plant beter tegen deze referentie dan tegen de ondergrens van de verordening.

De Amerikaanse basislijn: NTIA-minimumelementen

De NTIA-publicatie Minimum Elements for a Software Bill of Materials uit 2021 definieerde zeven basisvelden waar de meeste gereedschappen nog steeds op mikken: naam van de leverancier, naam van de component, versie, andere unieke identificatoren, afhankelijkheidsrelatie, auteur van de SBOM-gegevens en tijdstempel. De Amerikaanse richtsnoeren zijn sindsdien herzien — CISA hield een openbare consultatie over een geactualiseerde set minimumelementen die velden toevoegt zoals componenthash, licentie en generatiecontext. Wie al SBOM’s produceert voor Amerikaanse federale klanten zit dicht bij de CRA-ondergrens, maar nog niet bij de Duitse referentie.

De geharmoniseerde normen, nog in bewerking

Het normalisatieverzoek van de Commissie voor de CRA is op 3 april 2025 aanvaard door CEN, CENELEC en ETSI en omvat een programma van horizontale en verticale normen. Relevant is hier de horizontale EN 40000-reeks, in het bijzonder de norm over het omgaan met kwetsbaarheden, waarin de SBOM-praktijk wordt vastgelegd. Op het moment van schrijven bevinden deze normen zich nog in de ontwerp- en goedkeuringsfase, en de Commissie heeft geopperd de opleverdata naar achteren te schuiven.

Het praktische gevolg: wacht niet op de geharmoniseerde norm. De inhoud ervan wordt tegen dezelfde tekst van bijlage I geschreven, en het operationele werk — de build zo inrichten dat die per release een SBOM uitgeeft — verandert niet naargelang welke veldenlijst wint. Wachten kost het jaar aan releasehistorie dat je anders al zou hebben.

Waar SBOM’s in de praktijk misgaan

Handmatig gemaakt, eenmalig

De meest voorkomende fout is een spreadsheet die voor het technisch dossier is samengesteld, naar JSON geëxporteerd en daarna nooit meer aangeraakt. Op de dag van schrijven klopt hij, bij de eerste versiesprong van een afhankelijkheid niet meer. De CRA-plicht luidt: de stuklijst actueel houden. Een verouderde SBOM is dus geen gedeeltelijke naleving, maar een gedocumenteerde schending van een doorlopende verplichting.

Niet aan een versie gekoppeld

Een SBOM zonder eenduidige vermelding van welk product, welke versie en welke build hij beschrijft, bewijst niets. Als een autoriteit vraagt of de in maart 2028 geleverde eenheden een kwetsbare bibliotheek bevatten, heb je de stuklijst van díe build nodig, niet de huidige. Dit is de meest voorkomende structurele fout, en het is een probleem van datamodellering, niet van beveiliging.

Uit de broncode gebouwd, niet uit het artefact

Manifestbestanden beschrijven bedoelingen. Het geleverde artefact bevat wat de build heeft geproduceerd: de basisimage, de statisch gelinkte bibliotheek, de als binair pakket meegeleverde leveranciers-SDK. SBOM’s die alleen uit de broncode worden gegenereerd rapporteren stelselmatig te weinig, en de componenten die zij missen zijn onevenredig vaak juist die welke niemand patcht.

Componenten van derden en ingebedde componenten ontbreken

Levert een toeleverancier je een module, dan zitten diens componenten in jouw product. De CRA maakt het niet uit dat jij ze niet geschreven hebt. SBOM’s van leveranciers krijgen is een inkoopprobleem met lange doorlooptijd — contracten moeten worden aangepast en kleine leveranciers hebben vaak helemaal geen capaciteit. Hiermee kun je het beste het vroegst beginnen.

Nergens om het te bewaren

Eén SBOM per release, tien jaar of de ondersteuningsperiode lang bewaard, over productfamilies heen, is een geversioneerde gegevensverzameling die migraties van gereedschap, verhuizingen van repository’s en het vertrek van degene die het opzette moet overleven. Een buildartefact in een CI-systeem dat over drie jaar wordt vervangen, is geen bewaarstrategie.

SBOM-generatie in het releaseproces inbouwen — vijf stappen

Genereer automatisch uit de build. Voeg SBOM-generatie toe aan de pipelinestap die het leverbare artefact maakt, zodat er geen SBOM kan bestaan zonder build en geen build zonder SBOM. Handmatig genereren loopt altijd uit de pas.
Koppel de SBOM aan een identiteit. Product, versie, buildkenmerk, tijdstempel. Dat maakt van een bestand een bewijsstuk, en het is de stap die teams het vaakst overslaan.
Leg diepte en formaat vast, en schrijf het op. Kies CycloneDX of SPDX, beslis of je transitief oplost (dat zou je moeten doen) en documenteer de keuze, zodat niemand die zes releasecycli later stilletjes wijzigt.
Duw de eis de toeleveringsketen in. Pas leveranciersovereenkomsten aan zodat per geleverde versie een SBOM in het gekozen formaat wordt vereist. Begin bij de leveranciers van componenten die je zelf niet kunt inspecteren.
Bewaar het waar het over tien jaar nog leesbaar is. Geversioneerd, geïndexeerd op product en release, opvraagbaar zonder het oorspronkelijke buildsysteem. Bewaring is de eis die elk gereedschap overleeft waarmee je eraan voldoet.

Het bredere dataprogramma waar dit in past behandelt onze DPP-implementatiechecklist.

Wat dit betekent voor productdata

De grens duidelijk getrokken: de CRA zet geen SBOM in een digitaal productpaspoort. De verordening bevat geen paspoortplicht, en geen enkele lezing maakt van een stuklijst een openbaar veld. Paspoortplichten komen uit de ESPR en uit sectorale rechtshandelingen die ze uitdrukkelijk opleggen.

Wat beide regimes delen is de vorm. Beide vragen om gegevens die

aan een versie gekoppeld zijn, niet aan een productlijn. De SBOM verandert met elke release, precies zoals paspoortgegevens veranderen met elke specificatieherziening. Systemen die het huidige record overschrijven kunnen geen vraag beantwoorden over een drie jaar geleden verkochte eenheid;
van meet af aan machineleesbaar zijn. Geen pdf die toevallig een tabel bevat, maar een gestructureerd document dat een ander systeem zonder mens ertussen kan verwerken;
een decennium bewaard blijven. Tien jaar technische documentatie onder de CRA is dezelfde infrastructuurtoezegging als langdurige paspoortbeschikbaarheid onder de ESPR;
consistent zijn over kanalen heen. De einddatum van de ondersteuning, het contactpunt voor kwetsbaarheden en de informatie over updates moeten hetzelfde zeggen in je eigen webshop, bij een distributeur en in de documentatie.

Voor elektronica stapelt het argument zich op. Hetzelfde product valt tegelijk onder de ESPR, de RoHS-richtlijn, de WEEE-richtlijn en de CRA. Een bedrijf dat stofgegevens in het ene systeem, repareerbaarheidsgegevens in het tweede en softwarecomponentgegevens in het derde bijhoudt, onderhoudt vier registers over één product. De onderliggende redenering om productdata als infrastructuur te behandelen staat in DPP en PIM, en de aansluiting op de markering in CE-markering en digitaal productpaspoort.

Een eerlijke kanttekening over waar een paspoortplatform ophoudt: myDPP genereert geen SBOM’s, scant geen code of containers, valideert geen stuklijst tegen een build, voert geen kwetsbaarheidsanalyse uit en beoordeelt geen CRA-conformiteit. Dat hoort bij je engineering-toolchain en, waar vereist, bij een aangemelde instantie. Wat een paspoortplatform doet is geversioneerde productdata opslaan, die jarenlang opvraagbaar houden en de delen publiceren die openbaar horen te zijn. De verantwoordelijkheid voor naleving blijft bij de fabrikant.

Tijdlijn

Datum	Wat er gebeurt
10 december 2024	Verordening (EU) 2024/2847 treedt in werking
3 april 2025	CEN, CENELEC en ETSI aanvaarden het normalisatieverzoek
11 juni 2026	bepalingen over aangemelde instanties gelden
11 september 2026	meldingsverplichtingen gelden — ook voor producten die al op de markt zijn
11 december 2027	volledige toepassing — de SBOM-eis uit bijlage I wordt bindend

De meldplicht komt ruim een jaar vóór de SBOM-plicht, en die volgorde is leerzaam. Vanaf september 2026 kun je verplicht zijn een actief uitgebuite kwetsbaarheid binnen 24 uur te melden. De vraag „welke van onze producten bevatten deze component” binnen dat venster beantwoorden is precies het probleem waarvoor een SBOM bestaat — waarmee de praktische deadline ruim vóór de juridische ligt.

Veelgestelde vragen

Moet ik mijn SBOM publiceren?

Nee. De CRA verplicht je haar op te stellen, actueel te houden en op verzoek beschikbaar te stellen aan markttoezichtautoriteiten. Zij wordt onderdeel van de technische documentatie. Publicatie aan klanten is een commerciële keuze — en steeds vaker een contractuele eis van grote inkopers, wat losstaat van de juridische plicht.

Is een lijst met afhankelijkheden op het hoogste niveau genoeg?

Die voldoet aan de letter van bijlage I deel II. Zij voldoet niet aan de Duitse BSI TR-03183-2, die recursieve resolutie van de afhankelijkheidsboom vereist, en zij beantwoordt niet de vraag die je werkelijk moet beantwoorden wanneer een kwetsbaarheid vier niveaus dieper opduikt. Hoogste niveau is de ondergrens, transitief is het doel.

CycloneDX of SPDX?

Onder de CRA, die geen formaat noemt, zijn beide verdedigbaar. CycloneDX heeft het sterkere beveiligingsecosysteem en draagt VEX; SPDX heeft meer diepte voor licentie- en herkomstwerk. BSI TR-03183-2 accepteert CycloneDX 1.6+ of SPDX 3.0.1+. Doorslaggevend zou moeten zijn welke je bestaande toolchain betrouwbaar produceert.

Hoe lang moet ik SBOM’s bewaren?

De SBOM maakt deel uit van de technische documentatie, die ten minste tien jaar na het in de handel brengen ter beschikking van markttoezichtautoriteiten moet blijven, of gedurende de ondersteuningsperiode als die langer is. Omdat elke release een nieuwe SBOM oplevert, gaat het om een geversioneerd archief en niet om één bestand.

Hoort een SBOM in het digitaal productpaspoort?

Juridisch niet. De CRA creëert geen paspoortplicht en geen enkele geldende paspoortregeling vereist een stuklijst als gegevensveld. De overlap zit in de infrastructuur: beide hebben machineleesbare productdata op versieniveau nodig, een decennium bewaard en bereikbaar via een stabiele identificatie.

Lees verder

Bronnen

Verordening (EU) 2024/2847 — Cyber Resilience Act — EUR-Lex
The Cyber Resilience Act — samenvatting van de wettekst — Europese Commissie
BSI TR-03183-2: Software Bill of Materials (SBOM) — Bundesamt für Sicherheit in der Informationstechnik
CycloneDX — ECMA-424 — OWASP
SPDX — ISO/IEC 5962:2021 — Linux Foundation
Minimum Elements for a Software Bill of Materials — CISA