Kort antwoord: ja. De Cyber Resilience Act, Verordening (EU) 2024/2847, vereist van elke fabrikant van een product met digitale elementen binnen de reikwijdte dat hij een softwarestuklijst opstelt. Het is een van de acht eisen voor kwetsbaarheidsbeheer in bijlage I, deel II, die voor elk product binnen de reikwijdte gelden zonder "waar van toepassing" en zonder omvangsdrempel, vanaf 11 december 2027.

Het langere antwoord zijn drie zinnen in de verordening, en elk beslecht een vraag die mensen blijven stellen.

De eis: bijlage I, deel II, punt 1

Fabrikanten moeten "de kwetsbaarheden en componenten in producten met digitale elementen identificeren en documenteren, onder meer door een softwarestuklijst op te stellen in een gangbaar en machineleesbaar formaat die ten minste de afhankelijkheden op het hoogste niveau van de producten dekt".

Vier dingen liggen vast in die zin.

Ze is verplicht. De SBOM is het genoemde middel om componenten te identificeren en te documenteren. Er is geen weg naar punt 1 zonder.

Het formaat is "gangbaar en machineleesbaar". De verordening noemt CycloneDX noch SPDX, en dat hoeft ook niet: beide zijn gangbaar en machineleesbaar, en elk voldoet aan de tekst. Een spreadsheet is in zwakke zin machineleesbaar en niet gangbaar voor dit doel; vertrouw er niet op.

De diepte is "ten minste de afhankelijkheden op het hoogste niveau". Dat is de ondergrens, niet de aanbeveling. Hoogste niveau betekent de pakketten die uw product rechtstreeks declareert. Transitieve afhankelijkheden zijn waar de meeste bekende kwetsbaarheden werkelijk zitten, dus een SBOM met alleen het hoogste niveau voldoet aan de letter en laat de helft van punt 1, het identificeren van kwetsbaarheden, zwak. De meeste tooling produceert toch de volledige graaf.

Ze dekt "de producten", meervoud, per product. Eén SBOM per product met digitale elementen, per versie die de conformiteit beïnvloedt (bijlage VII, punt 1, onder b), vraagt om de versies). Eén organisatiebrede SBOM voldoet niet.

Waar ze hoort: bijlage VII, punt 2, onder b), en punt 8

De SBOM is onderdeel van de technische documentatie. Bijlage VII, punt 2, onder b), noemt "de softwarestuklijst" onder de specificaties van het kwetsbaarheidsbeheer die het dossier moet bevatten. Het is een document dat u gedateerd bij het dossier bewaart, tien jaar of de ondersteuningsperiode, wat langer is.

Punt 8 van dezelfde bijlage beantwoordt de vraag die iedereen daarna stelt: moeten we haar publiceren? Nee. De SBOM wordt verstrekt "op gemotiveerd verzoek van een markttoezichtautoriteit, mits dat nodig is om die autoriteit in staat te stellen de naleving van de essentiële cyberbeveiligingseisen van bijlage I te controleren". Ze wordt aan een autoriteit bekendgemaakt, op verzoek, met een reden. Niets in de verordening vereist publicatie aan klanten of het publiek, maar niets verbiedt het ook: bijlage II, punt 9, zegt dat als de fabrikant besluit de SBOM aan gebruikers beschikbaar te stellen, de gebruikersinformatie moet vermelden waar ze te vinden is. De beveiligingsvragenlijst van een klant kan er hoe dan ook om vragen.

Wat dit niet beslecht

Formaatdetails. De Commissie kan het formaat en de elementen van de SBOM bij uitvoeringshandeling vastleggen (artikel 13, lid 24). Tot dan is "gangbaar en machineleesbaar" de maatstaf, en de twee open formaten voldoen eraan.

Diepte voorbij het hoogste niveau. De verordening stelt een ondergrens. Of een autoriteit, een aangemelde instantie of een klant alleen het hoogste niveau accepteert, is een praktische vraag met een voorspelbaar antwoord: hoe dieper de SBOM, hoe minder vragen.

Hardwarecomponenten. Punt 1 zegt "kwetsbaarheden en componenten", en de SBOM is een softwarestuklijst. Voor een hardwareproduct moet het dossier nog steeds componenten identificeren (bijlage VII, punt 1, onder c), wil de interne indeling), maar de eis van machineleesbaarheid is voor software geformuleerd.

Wat te doen

Genereer de SBOM uit de build, niet met de hand, in CycloneDX of SPDX, voor elk product en elke conformiteitsrelevante versie, en bewaar haar bij het technische dossier. Houd de generatie in de releasepipeline zodat de SBOM in het dossier die van het geleverde product is en niet die van vorig kwartaal. Schrijf een SBOM-procedure van één pagina die zegt welke tool, welk formaat, welke diepte, waar ze wordt bewaard en wie een gemotiveerd verzoek beantwoordt; die procedure is een van de vier operationele documenten die deel II veronderstelt, en het is wat een auditor wil zien vóór de SBOM zelf.

En houd de kwetsbaarhedenkant in het oog: punt 1 luidt "kwetsbaarheden en componenten identificeren en documenteren". De SBOM is de componentenhelft. De kwetsbaarhedenhelft is de scanning die haar leest, en op het moment dat die scanning een uitgebuite kwetsbaarheid toont, is de klok van 24 uur van artikel 14 het volgende om over na te denken.

Wat de verordening u vervolgens vraagt voor elk component op die lijst, zorgvuldigheid onder artikel 13(5), stroomopwaarts melden onder artikel 13(6) en de toets van 'bekende uitbuitbare kwetsbaarheden' bij de release, staat in het bijbehorende artikel, uit de richtsnoeren van de Commissie.

Bronnen

  • Verordening (EU) 2024/2847, bijlage I, deel II, punt 1 (geciteerd); bijlage II, punt 9; bijlage VII, punten 1, onder b), 1, onder c), 2, onder b), en 8; artikel 13, lid 24, over de uitvoeringshandeling voor het SBOM-formaat; artikel 71, lid 2, voor de datums. Gelezen in de tekst van het Publicatieblad op EUR-Lex op 11 september 2026.

Dit is geen juridisch advies. De drie zinnen hierboven zijn kort genoeg om in de verordening zelf te lezen, en daar hoort een beslissing over uw product op te rusten.