CRA SBOM-vereisten: formaat, reikwijdte, updates en bewaarplicht
De CRA verplicht elk product met digitale elementen tot een machineleesbare Software Bill of Materials (SBOM) die de softwarecomponenten opsomt en ten minste de afhankelijkheden op het hoogste niveau dekt. De SBOM hoort in uw technische documentatie en moet op verzoek klaarstaan voor een markttoezichtautoriteit, niet vooraf worden ingediend.
Samenvatting
- Elk product met digitale elementen heeft een machineleesbare SBOM nodig als onderdeel van het bewijs voor kwetsbaarheidsbehandeling. Het is verplicht, zonder vrijstelling op basis van omvang.
- De wettelijke ondergrens is afhankelijkheden op het hoogste niveau. Transitieve dekking is sterkere praktijk en wat de meeste SBOM-kwaliteitskaders verwachten.
- Eén product betekent één geheel aan SBOM-bewijs, ook als het product uit veel repository's of componenten is opgebouwd.
- Houd de SBOM actueel tijdens de ondersteuningsperiode, vooral na releases, componentwijzigingen en kwetsbaarheidsbeslissingen.
- Bewaar de SBOM bij de technische documentatie gedurende ten minste 10 jaar, of de ondersteuningsperiode als die langer is.
- Kwetsbaarheidsmelding wordt verplicht op 11 september 2026; de volledige CRA-toepassing geldt vanaf 11 december 2027.
Wat is een SBOM?
Een Software Bill of Materials (SBOM) is een gestructureerde inventaris van de software in een product: bibliotheken, frameworks, besturingssysteempakketten en de afhankelijkheden daartussen. Voor de CRA is het de registratie waarmee een markttoezichtautoriteit zou nagaan welke van uw componenten geraakt worden door een gemelde kwetsbaarheid. Daarom moet het machineleesbaar zijn en niet een document in lopende tekst.
Wat de CRA in een SBOM vereist
De SBOM-verplichting heeft twee praktische lagen: wat de inventaris moet dekken en waar het bewijs in het technisch dossier moet staan.
Welke componenten moet de SBOM dekken?
Fabrikanten moeten de componenten en kwetsbaarheden in hun producten met digitale elementen identificeren en documenteren, en een SBOM opstellen in een algemeen gebruikt, machineleesbaar formaat dat ten minste de afhankelijkheden van het product op het hoogste niveau dekt.
Dit betekent:
- De SBOM moet machineleesbaar zijn en in een algemeen gebruikt formaat. Een pdf of spreadsheet kan helpen om de inventaris te beoordelen, maar vervangt het SBOM-bestand niet.
- Ze moet minimaal de afhankelijkheden op het hoogste niveau dekken. Transitieve dekking gaat verder dan de wettelijke ondergrens en is de betere basis voor kwetsbaarheidsmonitoring.
Elk product met digitale elementen dat op de EU-markt wordt gebracht, moet een machineleesbare SBOM hebben. Er is geen opt-out en geen omvangsdrempel waaronder de verplichting vervalt. Hoeveel detail u documenteert, schaalt mee met het risico van het product, maar de plicht om een SBOM op te stellen niet.
Nu vragen de regels alleen om een algemeen gebruikt, machineleesbaar formaat dat ten minste de afhankelijkheden op het hoogste niveau dekt. Ze noemen geen specifiek formaat en geen vaste veldenlijst. Die ondergrens kan worden verhoogd: de CRA laat ruimte voor de Commissie om later een precies SBOM-formaat en bijbehorende velden vast te stellen. Nu een goed ondersteund formaat kiezen, CycloneDX of SPDX, en meer vastleggen dan het strikte minimum, is de veiligste hedge tegen een toekomstig voorgeschreven formaat.
Waar de SBOM in het technisch dossier zit
De SBOM hoort bij uw technische documentatie, naast de rest van het bewijs voor kwetsbaarheidsbehandeling: het beleid voor gecoördineerde openbaarmaking van kwetsbaarheden, een contactadres voor meldingen en de manier waarop u updates veilig verspreidt. U dient ze niet vooraf in. Ze moet bestaan wanneer het product op de EU-markt wordt gebracht en klaarstaan voor een markttoezichtautoriteit als die een met redenen omkleed verzoek doet.
In de praktijk moet de SBOM kwetsbaarheidstracking op componentniveau, leverancier- en herkomstcontroles, licentiebeoordeling en end-of-life-planning mogelijk maken.
Hoeveel SBOM's heeft één product nodig?
Een product is vaak opgebouwd uit veel repository's en componenten, en elk daarvan kan zijn eigen SBOM genereren. De CRA legt de bewijseenheid vast op het product, niet op de repository of de build.
De CRA omschrijft een SBOM als een registratie van de componenten in de software van een product en hoe die samenhangen, en verwacht dat die registratie ten minste de afhankelijkheden op het hoogste niveau dekt. Het bewijsobject is het product dat u op de EU-markt brengt, geïdentificeerd op product en versie. Een product dat uit tien repository's is samengesteld, is niet gedekt door tien losse component-SBOM's die niets met elkaar verbindt. U bent SBOM-bewijs verschuldigd dat het product weergeeft zoals het wordt geleverd.
De CRA verplicht geen enkel fysiek bestand en verbiedt het bewaren van component-SBOM's niet. Twee routes werken allebei, zolang het resultaat machineleesbaar is, op productniveau zit en ten minste de afhankelijkheden op het hoogste niveau dekt:
- Samenstellen. Houd component-SBOM's als aparte documenten en koppel ze in een product-SBOM, met CycloneDX-assembly-componenten en BOM-Link-verwijzingen, of SPDX-relaties met externe-documentverwijzingen.
- Samenvoegen. Vlak elk component af tot één CycloneDX- of SPDX-document voor de productversie.
Omdat de SBOM bedoeld is om vast te leggen hoe componenten samenhangen, is een platte lijst met pakketnamen op zichzelf niet genoeg. Welke route u ook kiest, de SBOM moet tonen hoe componenten van elkaar afhangen en elkaar bevatten, wat zowel CycloneDX-afhankelijkheidsgrafen als SPDX-relaties bieden. Voor de mechaniek van het formaat, zie CycloneDX vs. SPDX.
Wie moet de SBOM ontvangen?
De SBOM is materiaal voor het technisch dossier, geen openbaar document. De CRA verplicht u niet om ze te publiceren, en de enige partij die ze kan afdwingen is een markttoezichtautoriteit, die ze kan opvragen met een met redenen omkleed verzoek wanneer ze uw naleving moet controleren. De SBOM met gebruikers delen is optioneel. Kiest u er wel voor om ze met gebruikers te delen, dan moet u hun vertellen waar ze die kunnen vinden.
| Wie | Wat de CRA verwacht |
|---|---|
| Markttoezichtautoriteit | Kan de SBOM opvragen met een met redenen omkleed verzoek, wanneer dat nodig is om naleving te controleren |
| Gebruikers en het publiek | Geen plicht om te publiceren of af te geven; delen is uw keuze |
| Importeurs en distributeurs | Geen recht op de SBOM zelf; zij moeten uw technische documentatie op verzoek aan autoriteiten kunnen verstrekken |
| Integrators die op uw product voortbouwen | Waar uw product bedoeld is om in het hunne te worden geïntegreerd, geeft u hun de informatie die zij nodig hebben om hun eigen verplichtingen na te komen, wat niet automatisch de volledige SBOM is |
Wij raden u aan de SBOM niet standaard te publiceren of naar gebruikers te sturen. Een SBOM is een precieze kaart van uw componenten en versies, precies wat een aanvaller wil, en de CRA legt u geen plicht op om ze breed te verspreiden. Geef ze af aan een markttoezichtautoriteit wanneer die een met redenen omkleed verzoek doet, en aan zakelijke klanten die op uw product voortbouwen, onder een NDA of contract, omdat zij ze nodig hebben om hun eigen SBOM op productniveau samen te stellen en hun eigen verplichtingen na te komen. Houd bij wie welke versie heeft ontvangen.
Wat de SBOM moet bevatten
Scheid de wettelijke CRA-ondergrens van de velden die de SBOM bruikbaar maken in echte kwetsbaarheidsprocessen. De verordening stelt het minimum. TR-03183, CycloneDX/SPDX-tooling en klantverwachtingen leggen de operationele lat meestal hoger.
| Gebied | CRA-ondergrens | Sterke implementatie |
|---|---|---|
| Formaat | Algemeen gebruikt en machineleesbaar | CycloneDX JSON/XML of SPDX JSON/tag-value, gegenereerd door buildtools |
| Reikwijdte | Ten minste afhankelijkheden op het hoogste niveau | Directe en transitieve afhankelijkheden, interne bibliotheken, firmware en OS-pakketten waar van toepassing |
| Componenten | Componenten in het product | Componentnaam, versie, leverancier, PURL of CPE, hash en relatiedata |
| Kwetsbaarheden | Componenten en kwetsbaarheden geïdentificeerd en gedocumenteerd | Huidige kwetsbaarheidsstatus, VEX- of exploiteerbaarheidsbeslissing, herstelreferentie en beoordelingsdatum |
| Technisch bewijs | SBOM opgenomen bij bewijs voor kwetsbaarheidsbehandeling | Stabiele bestandsreferentie per productversie, tool, generatiedatum en validatieresultaat |
| Toegang autoriteiten | Beschikbaar waar nodig bij een met redenen omkleed markttoezichtverzoek | Beveiligd archief met eigenaar voor retrieval, integriteitscontroles en dekking van de ondersteuningsperiode |
De CRA verplicht u kwetsbaarheden te identificeren en te documenteren, maar dat betekent niet dat de kwetsbaarheids- of VEX-gegevens in het SBOM-bestand zelf moeten staan. Ze daar opnemen is goede praktijk, geen ondergrens. Voor de veldvereisten die verder gaan dan deze checklist (PURL-identificatoren, hashwaarden, documentmetadata), zie hoe BSI TR-03183 de CRA uitbreidt. Voor een vergelijking van CycloneDX- en SPDX-tooling, zie CycloneDX vs. SPDX.
Hoe een SBOM-samenvatting in het technisch dossier eruitziet
Een sterk technisch dossier combineert de machineleesbare SBOM met een korte samenvattingsregistratie. De samenvatting is een voorblad voor menselijke beoordeling. De eigenlijke SBOM is het bijgevoegde CycloneDX- of SPDX-bestand waarnaar ze verwijst.
SBOM-SAMENVATTING TECHNISCH DOSSIER
Product: SmartSense Pro (SSP-3000)
Firmware Version: 2.4.1
SBOM Format: CycloneDX 1.6
Generated: 2027-01-15
Tools: Syft (generatie), Trivy (scanning)
SBOM-BESTAND:
sbom-ssp3000-v2.4.1.json (bijgevoegd, machineleesbaar)
COMPONENTOVERZICHT:
-------------------------------------------------------------
Total Components: 127
Direct Dependencies: 23
Transitive Dependencies: 104
Per type:
Libraries: 98
Frameworks: 12
Operating System: 1 (FreeRTOS)
Firmware Modules: 16
KWETSBAARHEIDSSTATUS BIJ BEOORDELING:
-------------------------------------------------------------
Scan Date: 2027-01-17
Scanner: Trivy v0.48.0
Critical: 0
High: 0
Medium: 2 (geaccepteerd - zie hieronder)
GEACCEPTEERDE KWETSBAARHEDEN:
CVE-2026-15432 (Medium): libexpat 2.5.0
Status: Niet exploiteerbaar in onze configuratie
Justification: Functie niet ingeschakeld, code path niet bereikbaar
Review Date: 2027-04-15
-------------------------------------------------------------
Wanneer u uw SBOM moet bijwerken
De SBOM is geen eenmalig document. Uw technische documentatie moet worden opgesteld voordat het product op de markt komt en worden bijgewerkt, waar passend, ten minste tijdens de ondersteuningsperiode. De ondersteuningsperiode weerspiegelt hoe lang het product naar verwachting in gebruik zal zijn, en bedraagt ten minste vijf jaar, tenzij het product werkelijk korter in gebruik zal zijn.
Beoordeel of regenereer de SBOM wanneer:
| Trigger | Wat verandert | Praktische actie |
|---|---|---|
| Nieuwe firmware- of softwareversie | Nieuw buildartefact | SBOM voor die productversie opnieuw genereren |
| Beveiligingspatch | Componentversie wijzigt | Getroffen componenten bijwerken en nieuwe SBOM archiveren |
| Kwetsbaarheid ontdekt en beoordeeld | VEX- of exploiteerbaarheidsstatus wijzigt | Kwetsbaarheidsstatus en beslisbewijs bijwerken |
| Component toegevoegd, verwijderd of vervangen | Afhankelijkheidsgraaf wijzigt | SBOM opnieuw genereren en valideren |
| Beveiligingsrelevante ontwerpwijziging | Componenten of architectuur wijzigen | SBOM opnieuw genereren en technische referenties bijwerken |
| Toegepaste normen of specificaties gewijzigd | Compliance-metadata wijzigen | Metadata en gekoppeld bewijs beoordelen |
Periodieke beoordelingen. De CRA legt geen vast beoordelingsinterval op. Deze cadansen zijn een praktische basislijn:
| Cadans | Reikwijdte |
|---|---|
| Driemaandelijks | SBOM en kwetsbaarheidsstatus |
| Jaarlijks | Volledige beoordeling van het technisch dossier |
| Voor het einde van de ondersteuningsperiode | Definitieve documentatieblokkering |
Elke build moet een actueel SBOM-artefact opleveren, zodat het bewijs in de pas blijft met wat u uitlevert. Zie veelgemaakte SBOM-fouten voor wat er misgaat wanneer teams automatisering overslaan.
Hoe lang SBOM-bewijs moet worden bewaard
Bewaar de SBOM met de technische documentatie gedurende ten minste 10 jaar nadat het product met digitale elementen op de markt is gebracht, of gedurende de ondersteuningsperiode als die langer is. Dezelfde bewaarplicht geldt voor de technische documentatie en de EU-conformiteitsverklaring. Dit gaat over het bewaren van de documentatie. Het staat los van de plicht om de beveiligingsupdates zelf beschikbaar te houden, die voor elke update tien jaar loopt vanaf het moment dat die wordt uitgeleverd.
Voor een productlijn die langere tijd wordt verkocht, bewaart u bewijs voor de versies en exemplaren die op de markt zijn gebracht. Behandel de eerste lanceringsdatum niet als praktisch einde van de bewijsplicht zolang latere exemplaren of versies nog worden geleverd.
| Mijlpaal | Voorbeelddatum |
|---|---|
| Product voor het eerst op de markt gebracht | maart 2027 |
| Laatste exemplaar op de markt gebracht | december 2030 |
| Praktische bewijsdekking | Tot december 2040 of langer als de ondersteuningsperiode dat vereist |
De klok loopt vanaf het laatste exemplaar dat op de markt is gebracht, dus december 2030 plus tien jaar reikt tot ten minste december 2040, langer als de ondersteuningsperiode daar voorbij gaat. Bewaar de SBOM op een veilige plek met back-ups en integriteitsbescherming, zodat u de juiste versie kunt ophalen en verstrekken bij een met redenen omkleed verzoek.
Datums en handhaving
Volledige CRA-toepassing geldt vanaf 11 december 2027. De verplichting tot kwetsbaarheidsmelding start eerder, op 11 september 2026. Die eerdere datum is geen aparte SBOM-indieningsdeadline, maar vereist wel dat u snel kunt bepalen welke productversies en componenten geraakt zijn door een meldingsplichtige kwetsbaarheid of incident. Voor producten die na de volledige toepassing op de EU-markt worden gebracht, maakt de SBOM deel uit van de bewijsbasis achter conformiteitsbeoordeling, EU-conformiteitsverklaring en CE-markering. Voor de meldingsstroom, zie CRA-kwetsbaarheids- en incidentmelding. Voor de algemene CRA-tijdlijn, zie wat de CRA is; voor de boetetabel, zie CRA-boetes en handhaving.
Veelgestelde vragen
Vereist de CRA een machineleesbare SBOM of is een pdf acceptabel?
De SBOM moet in een algemeen gebruikt, machineleesbaar formaat zijn. Een pdf of spreadsheet kan het bestand begeleiden voor menselijke beoordeling, maar vervangt de SBOM niet. CycloneDX of SPDX geserialiseerd als JSON of XML is de praktische route.
Vereist de CRA een SBOM voor opensourcecomponenten?
Ja. Opensourcecomponenten blijven componenten in het product en horen dus in de SBOM met versie- en identificatiegegevens. De CRA verwacht ook dat u passende zorgvuldigheid betracht ten aanzien van de geïntegreerde componenten van derden, met inbegrip van opensourcesoftware die niet in het kader van een handelsactiviteit aan u is aangeboden, en dat u elke kwetsbaarheid die u in een geïntegreerd component aantreft, ook een opensourcecomponent, meldt aan wie dat component onderhoudt.
Wanneer moet een SBOM worden ingediend: bij marktintroductie of op verzoek?
De SBOM wordt normaal niet proactief ingediend. Ze moet deel uitmaken van de technische documentatie, klaar en beschikbaar zijn voor markttoezichtautoriteiten bij een met redenen omkleed verzoek, en bestaan wanneer het product op de EU-markt wordt gebracht.
Wat zijn de NTIA-minimumelementen en voldoen die aan de CRA-eisen?
De NTIA-minimumelementen (leveranciersnaam, componentnaam, versie, unieke identificatoren, afhankelijkheidsrelaties, SBOM-auteur en tijdstempel) zijn een redelijk startpunt. Op zichzelf beantwoorden ze niet elke CRA-bewijsvraag of elke TR-03183-kwaliteitsverwachting. Voor CRA-werk valideert u het gegenereerde bestand tegen het gekozen formaat, legt u kwetsbaarheidsstatus vast en vult u rijkere velden zoals PURL/CPE, hashes en relatiedata in wanneer uw kwaliteitskader dat vereist.
Kan ik SBOM's van mijn leveranciers hergebruiken om aan de CRA te voldoen?
Gedeeltelijk. Leveranciers-SBOM's zijn geldige input voor de onderdelen die zij leveren, maar u heeft nog steeds één SBOM nodig voor het product zoals het op de markt wordt gebracht. Dat betekent leveranciers-SBOM's samenvoegen met uw eigen componenten en buildafhankelijkheden tot bewijs op productniveau, zoals hierboven beschreven in hoeveel SBOM's één product nodig heeft. Behandel leveranciers-SBOM's als grondstof, niet als het afgeronde complianceartefact.
Wat u nu kunt doen
- Kies een formaat: CycloneDX voor beveiligingsfocus en native VEX-ondersteuning, SPDX voor licentienaleving en bredere adoptie. Zie CycloneDX vs. SPDX.
- Automatiseer generatie in CI/CD met Syft, Trivy, cdxgen of tools voor analyse van softwaresamenstelling (SCA). Een eenmalige export voldoet niet aan de doorlopende verplichting.
- Valideer veldkwaliteit tegen BSI TR-03183 of uw interne SBOM-quality gate: naam en versie, leverancier, PURL/CPE, afhankelijkheden, hashes en licenties.
- Koppel SBOM's aan kwetsbaarheidsmonitoring (NVD, OSV, GitHub Advisory Database, CISA KEV) vóór de meldverplichtingen die starten op 11 september 2026.
- Plaats de SBOM in uw technisch dossier. De gids voor technische documentatie legt uit waar ze in past. Als u SBOM-inname niet zelf wilt opzetten, verwerkt CRA Evidence CycloneDX/SPDX-inname en TR-03183-kwaliteitsscoring over productversies.