Veelgemaakte CRA SBOM-fouten: zo voorkomt u non-compliance
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-512, 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-512 |
| 6 | SBOM's van leveranciers als eindproduct behandelen | Fabrikant is verantwoordelijk voor de geïntegreerde product-SBOM | Samenvoegen tot één product-SBOM |
Fout 1: stoppen bij directe afhankelijkheden
Directe afhankelijkheden zijn het minimum waarmee u kunt wegkomen, maar ze zijn niet genoeg voor nuttig kwetsbaarheidsbeheer. Veel fabrikanten stoppen daar en laten transitieve afhankelijkheden buiten de SBOM. Een transitieve afhankelijkheid is een bibliotheek waarvan uw directe afhankelijkheid afhangt, en die kan net zo goed misbruikt worden 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) ← directe afhankelijkheid vermeld
| +-- Bibliotheek B (transitief) <- buiten SBOM, onzichtbaar voor kwetsbaarhedenscanners
| \-- Bibliotheek C (transitief) <- buiten SBOM, onzichtbaar voor kwetsbaarhedenscanners
\-- Bibliotheek D (direct) ← directe afhankelijkheid vermeld
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-veldcategorieën voor de vereiste, aanvullende en optionele veldvereisten.
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 het coördinerend CSIRT en 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) | TR-03183 verplicht |
| SHA-512-hash | Integriteitsverificatie voor binaire componenten | TR-03183 verplicht |
| PURL-identificator | Koppelt het component aan zijn registerrecord | TR-03183 Aanvullend (indien beschikbaar) |
| Leveranciersnaam | Vereist voor elk component | 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-512-hash van het binaire artefact. BSI TR-03183 dekt eigen componenten uitdrukkelijk, en de vereiste velden zijn ook op hen van toepassing.
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 vervangen geen geïntegreerde product-SBOM. U moet SBOM's van leveranciers nog steeds samenvoegen met uw eigen eerste-partijcomponenten, bouwafhankelijkheden en verbindingscode tot één SBOM voor het product dat u op de EU-markt brengt.
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 u moet ze gebruiken in plaats van upstreamdocumentatie opnieuw op te stellen. Op zichzelf zijn ze niet genoeg: u hebt één SBOM nodig voor het geïntegreerde product, waarin leveranciers-SBOM's worden gecombineerd met uw eigen eerste-partijcomponenten, bouwafhankelijkheden en verbindingscode. Als een leveranciers-SBOM BSI TR-03183-velden mist, zoals PURL, hash of licentie, vul die gaten dan voordat het product wordt geleverd. Behandel leveranciers-SBOM's als grondstof, niet als het afgeronde complianceartefact.
Wat is het wettelijk minimum voor SBOM-afhankelijkheidsdekking onder de CRA?
De wettelijke ondergrens is top-level afhankelijkheden, dus directe afhankelijkheden. Dat is alleen het minimum. Transitieve afhankelijkheden worden sterk aanbevolen omdat kwetsbaarheidsscanners ze nodig hebben om CVE's nauwkeurig te koppelen, en BSI TR-03183 behandelt transitieve dekking als kwaliteitsindicator. Genereer uw SBOM in de praktijk uit lockfiles en gebouwde artefacten, zodat directe en transitieve afhankelijkheden worden vastgelegd.
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.