De meeste fabrikanten ontdekken SBOM-tekortkomingen pas tijdens hun eerste compliancebeoordeling, niet daarvoor. Tegen die tijd is de handhavingsdeadline dichterbij en is de omvang van herstelwerk groter. De SBOM-verplichting uit Bijlage I is eenvoudig te omschrijven: machineleesbaar formaat, afhankelijkheden van de producten op het hoogste niveau als minimum, opgeslagen in uw technisch dossier van Bijlage VII. Wat fabrikanten struikelt is de formulering "ten minste". Dit artikel behandelt zes fouten die de grootste kloof veroorzaken tussen een formele SBOM en een die een audit door een markttoezichtautoriteit zou doorstaan.
Samenvatting
- Stoppen bij directe afhankelijkheden laat transitieve kwetsbaarheden buiten de SBOM
- Een eenmalig opgestelde SBOM is binnen weken verouderd doordat nieuwe CVE's worden gepubliceerd
- Ontbrekende hashwaarden en PURL-identificatoren halen de kwaliteitscontroles van BSI TR-03183 niet
- Handmatige SBOM-aanmaak voldoet niet aan de doorlopende updateverplichting van de CRA
- Interne en eigen componenten moeten naast opensourcebibliotheken worden opgenomen
- SBOM's van leveranciers zijn grondstof, geen afgerond complianceartefact
Fouten in een oogopslag
| # | Fout | Waarom het faalt | Oplossing |
|---|---|---|---|
| 1 | Stoppen bij directe afhankelijkheden | Transitieve CVE's onzichtbaar voor scanners | Lockfiles plus scanning van bouwartefacten |
| 2 | SBOM als eenmalig document behandelen | Binnen weken verouderd door nieuwe CVE's | CI/CD-generatie per build |
| 3 | Ontbrekende identiteitsvelden | Geen CVE-koppeling, TR-03183 mislukt | Exacte versie, SHA-256, PURL, leverancier |
| 4 | Handmatige generatie | Kan releasefrequentie niet bijhouden | Automatisering via Syft, Trivy of cdxgen |
| 5 | Interne of eigen componenten overslaan | Bijlage I maakt dat onderscheid niet | Interne ID's, eigen organisatie als leverancier, SHA-256 |
| 6 | SBOM's van leveranciers als eindproduct behandelen | Fabrikant draagt de Bijlage I-verplichting | Samenvoegen tot één product-SBOM |
Fout 1: stoppen bij directe afhankelijkheden
Bijlage I, Deel II, punt (1) stelt de wettelijke ondergrens bij afhankelijkheden van de producten op het hoogste niveau. Veel fabrikanten stoppen precies daar. Het probleem is niet het halen van het wettelijk minimum. Het probleem is het risico dat het minimum buiten uw zicht laat. Een transitieve afhankelijkheid (een bibliotheek waarvan uw directe afhankelijkheid afhankelijk is) is net zo uitbuitbaar als een directe. Wanneer een CVE wordt gepubliceerd tegen een transitief pakket dat uw SBOM niet vermeldt, kunt u het niet koppelen, niet melden en bent u blootgesteld zonder het te weten.
Uw product
+-- Bibliotheek A (direct) <- wettelijk minimum, Bijlage I-ondergrens
| +-- Bibliotheek B (transitief) <- buiten SBOM, onzichtbaar voor kwetsbaarhedenscanners
| \-- Bibliotheek C (transitief) <- buiten SBOM, onzichtbaar voor kwetsbaarhedenscanners
\-- Bibliotheek D (direct) <- wettelijk minimum, Bijlage I-ondergrens
De oplossing is tooling en configuratie. Gebruik lockfiles en scan bouwartefacten in plaats van alleen broncode. Trivy, Syft en cdxgen ondersteunen alle transitieve afhankelijkheidsvastlegging als ze correct zijn geconfigureerd. BSI TR-03183 behandelt volledige transitieve dekking als de kwaliteitsindicator die een minimumcompliant SBOM onderscheidt van een echt bruikbare. Zie BSI TR-03183-kwaliteitsniveaus voor de veldvereisten per laag.
Fout 2: de SBOM als eenmalig document behandelen
Een eenmalig gegenereerde en nooit bijgewerkte SBOM geeft een vals veiligheidsgevoel. Dagelijks worden nieuwe CVE's gepubliceerd tegen componenten die al in uw product zitten. Een SBOM die op het moment van de build accuraat was, is binnen weken verouderd. De verplichting uit Bijlage I is doorlopend: de SBOM moet de actuele staat van het product weerspiegelen gedurende de gehele ondersteuningsperiode.
Verplichte updatetriggers onder de CRA:
| Trigger | Wat verandert | SBOM-update vereist? |
|---|---|---|
| Nieuwe firmware- of softwareversie | Nieuw bouwartefact | Ja, volledige regeneratie |
| Beveiligingspatchrelease | Componentversie verhoogd | Ja, getroffen componenten |
| Kwetsbaarheid ontdekt en verholpen | VEX of uitbuitbaarheidsstatus | Ja, VEX-velden |
| Component toegevoegd, verwijderd of vervangen | Afhankelijkheidsgraph | Ja, volledige regeneratie |
| Ontwerpwijziging die beveiliging raakt | Componenten en architectuur | Ja, volledige regeneratie |
De oplossing is CI/CD-integratie. Elke build moet een actueel SBOM-artefact opleveren dat naast de release wordt opgeslagen. Een handmatige export kan de updatefrequentie die de CRA vereist niet bijhouden. Zie CRA SBOM-vereisten voor de volledige lijst van triggers en de 10-jarige bewaartermijnklok.
Vanaf 11 september 2026 moet u actief uitgebuite kwetsbaarheden binnen 24 uur melden aan ENISA. Een verouderde SBOM betekent dat u niet kunt bepalen of uw product getroffen is voordat de klok start. U heeft actuele componentgegevens nodig vóór het incident, niet erna.
Fout 3: ontbrekende identiteitsvelden
Een SBOM zonder accurate versie-, hash- en identificatorvelden is vrijwel nutteloos voor kwetsbaarheidskoppeling. Deze velden verbinden een componentvermelding met een CVE-record in de National Vulnerability Database (NVD), OSV of CISA KEV. Zonder ze kunnen kwetsbaarhedenscanners uw componenten niet koppelen en zullen de kwaliteitscontroles van BSI TR-03183 mislukken.
Elk component moet bevatten:
| Veld | Waarom het belangrijk is | Bron |
|---|---|---|
| Exact versienummer | Vereist voor CVE/NVD/OSV-koppeling (niet "latest" of bereiken) | Bijlage I; TR-03183 verplicht |
| SHA-256-hash | Integriteitsverificatie voor binaire componenten | TR-03183 verplicht |
| PURL-identificator | Koppelt het component aan zijn registerrecord | TR-03183 verplicht |
| Leveranciersnaam | Vereist op elk kwaliteitsniveau | Bijlage I; TR-03183 |
Een veelgemaakte versiefout is het gebruik van CycloneDX 1.3 of eerder. Kernondersteuning voor VEX werd toegevoegd in CycloneDX 1.4 (januari 2022) en de uitgebreidere component evidence-structuur (identity, occurrences) die wordt gebruikt om CRA-traceerbaarheid aan te tonen, arriveerde in 1.5 (juni 2023). Streef naar CycloneDX 1.6 of later voor CRA-conformiteit. Controleer de uitvoerversie van uw tool voordat u compliance aanneemt.
Fout 4: SBOM's handmatig genereren
Handmatige SBOM-aanmaak is foutgevoelig en schaalt niet over productversies. Een handmatig opgestelde SBOM mist componenten die geautomatiseerde tools wel zouden vinden, bevat typefouten in versiestrings en kan niet betrouwbaar worden gegenereerd wanneer een component verandert. Belangrijker nog: een handmatig proces kan niet voldoen aan de doorlopende updateverplichting van de CRA: elke release, elke patch en elke componentwijziging vereist een bijgewerkte SBOM.
Automatiseer generatie met Syft, Trivy of cdxgen. Handmatige vermeldingen moeten worden voorbehouden aan componenten die geautomatiseerde tools niet kunnen detecteren, zoals commerciële bibliotheken zonder pakketdatabasevermeldingen of eigen firmwareblobs. Al het andere moet uit de build komen. Markttoezichtautoriteiten kunnen de SBOM op elk moment opvragen; deze moet de actuele staat van het product weerspiegelen.
Fout 5: interne en eigen componenten negeren
Een veelgebruikte afkorting is het documenteren van alleen opensource-afhankelijkheden en het weglaten van interne bibliotheken, eigen modules of firmwareblobs. Bijlage I maakt dat onderscheid niet. Als een component in het product zit, hoort het in de SBOM.
Interne componenten hebben vaak geen PURL of registervermeldingen. De juiste aanpak is het toewijzen van een interne identificator, het vermelden van uw eigen organisatie als leverancier en het opnemen van de SHA-256-hash van het binaire artefact. BSI TR-03183 dekt eigen componenten uitdrukkelijk op alle kwaliteitsniveaus.
Voor producten met ingebedde firmware van een ODM of chipverkoper kunt u niet auditen wat u niet hebt gebouwd. De oplossing is contractueel: vereis SBOM-levering van uw firmwareleveranciers. Onder de CRA bent u verantwoordelijk voor het volledige product, ongeacht wie de code heeft geschreven. Voor hardware-softwareproducten, zie HBOM onder de CRA voor wanneer een Hardware Bill of Materials naast de SBOM nodig is.
Fout 6: SBOM's van leveranciers als het eindproduct behandelen
SBOM's van leveranciers zijn een geldig uitgangspunt en de CRA verwacht dat fabrikanten stroomopwaartse documentatie benutten. Ze zijn geen vervanging voor een geïntegreerde product-SBOM. De Bijlage I-verplichting rust op de fabrikant van het product dat op de EU-markt wordt gebracht: u moet SBOM's van leveranciers samenvoegen met uw eigen eerste-partijcomponenten, bouwafhankelijkheden en verbindingscode tot één SBOM voor het geïntegreerde product.
Als een leveranciers-SBOM velden mist die BSI TR-03183 vereist (PURL, hash, licentie), bent u verantwoordelijk voor het aanvullen van die hiaten voordat uw product wordt geleverd. Behandel SBOM's van leveranciers als grondstof. Uw product-SBOM is het afgeronde complianceartefact.
Veelgestelde vragen
Kan ik SBOM's van mijn leveranciers hergebruiken om aan de CRA te voldoen?
Gedeeltelijk. SBOM's van leveranciers zijn een geldig uitgangspunt voor de componenten die zij leveren en de CRA verwacht dat fabrikanten stroomopwaartse documentatie benutten in plaats van die opnieuw op te stellen. Maar de verplichting op grond van Bijlage I rust op de fabrikant van het product dat op de EU-markt wordt gebracht: u moet een SBOM produceren en onderhouden voor het geïntegreerde product, wat inhoudt dat u SBOM's van leveranciers combineert met uw eigen eerste-partijcomponenten, uw bouwafhankelijkheden en eventuele verbindingscode. Als een leveranciers-SBOM velden mist die BSI TR-03183 vereist (PURL, hash, licentie), bent u verantwoordelijk voor het aanvullen van die hiaten voordat uw product wordt geleverd. Behandel SBOM's van leveranciers als grondstof, niet als een afgerond complianceartefact.
Wat is het wettelijk minimum voor SBOM-afhankelijkheidsdekking onder de CRA?
Bijlage I, Deel II, punt (1) stelt de ondergrens bij afhankelijkheden van de producten op het hoogste niveau. De officiële tekst luidt: "kwetsbaarheden en componenten in producten met digitale elementen vaststellen en documenteren, onder meer door een softwarestuklijst op te stellen in een algemeen gebruikt en machineleesbaar formaat waarin ten minste de afhankelijkheden van de producten op het hoogste niveau worden aangegeven". Dit betekent dat directe afhankelijkheden het wettelijk minimum zijn. Transitieve afhankelijkheden zijn niet wettelijk verplicht maar worden sterk aanbevolen als best practice: ze zijn wat kwetsbaarhedenscanners daadwerkelijk nodig hebben om CVE's nauwkeurig te koppelen en BSI TR-03183 telt transitieve dekking als kwaliteitsindicator.
Moet een SBOM bij elke patchrelease worden bijgewerkt?
Ja. Elke beveiligingspatchrelease is een verplichte SBOM-updatetrigger onder de CRA. Het technisch dossier, inclusief de SBOM, moet actueel blijven gedurende de gehele productlevenscyclus. Als u een kwetsbaar component patcht, moet uw SBOM de nieuwe versie weerspiegelen. Automatiseer SBOM-generatie in CI/CD zodat patchreleases automatisch een bijgewerkt SBOM-artefact opleveren, zonder een handmatige stap die onder deadlinedruk kan worden overgeslagen.