CRA SBOM-fouten: 7 praktische oplossingen voor fabrikanten

Uw SBOM-generator draait, het bestand valideert, en de volgende productbeoordeling kan toch tekortkomingen aan het licht brengen. De terugkerende CRA-gereedheidsproblemen zijn doorgaans geen obscure juridische randgevallen. Het zijn ondiepe afhankelijkheidsbomen, inventarisaties op broncodeniveau, verouderde records en componenten die scanners niet kunnen koppelen aan een kwetsbaarheid. De Cyberveerkrachtwet vraagt om een veelgebruikte, machineleesbare SBOM die ten minste de afhankelijkheden op het hoogste niveau omvat en wordt bewaard in de technische documentatie. Dit artikel behandelt de zeven tekortkomingen tussen een SBOM die technisch bestaat en een die kwetsbaarheidsafhandeling kan onderbouwen. Dat is de SBOM die een markttoezichtautoriteit verwacht te zien.

Fout in een oogopslag

• Bronboom, niet het geleverde artefact: genereer vanuit het gebouwde artefact of de image zodat gecompileerde code, OS-pakketten en firmware zichtbaar zijn.
• Dunne identiteitsvelden: gebruik exacte versies, hashes, PURL's waar beschikbaar en leveranciersnamen zodat scanners CVE's kunnen koppelen.
• Alleen directe afhankelijkheden: voeg lockfile- en bouwartefactscanning toe zodat indirecte en verpakte afhankelijkheden in de SBOM terechtkomen.
• Eenmalig bestand: genereer de SBOM opnieuw en archiveer hem voor elke release en houd kwetsbaarheidsmatching actueel.
• Productcode weggelaten: interne, eigen, commerciële en firmwarecomponenten hebben nog steeds identificatoren en bewijsmateriaal nodig.
• Kopiëren van leveranciers: SBOM's van leveranciers zijn invoer. Reconcilieer ze met eerste-partijcode en het definitieve releaseartefact.
• SBOM-versnippering: houd één gezaghebbende product-SBOM per release zodat versie 1.4.2 één verdedigbaar record heeft.

Wat van belang is voor SBOM-bewijsmateriaal

Die juridische ondergrens is niet hetzelfde als een bruikbare ondergrens voor kwetsbaarheidsbeheer. Een SBOM met alleen directe afhankelijkheden voldoet misschien aan de minimale formulering, maar is te ondiep om getroffen producten snel te identificeren. BSI TR-03183, ENISA-richtlijnen, CISA SBOM-richtlijnen en de huidige toolpraktijk zijn het best te lezen als kwaliteitsbenchmarks die fabrikanten helpen de CRA-verplichting operationeel te maken.

Fout 1: uw SBOM beschrijft de bronboom, niet het product dat u hebt geleverd

Bronmanifesten zijn handig, maar ze zijn niet het product. Een bronscan kan ontwikkelingsafhankelijkheden te ruim rapporteren en missen wat alleen na het bouwen, verpakken, containerlagen, statisch linken of firmwareintegratie verschijnt. Voor een fabrikant moet de SBOM de vraag beantwoorden wat er in de productrelease zat, niet alleen wat er in een pakketbestand was gedeclareerd.

Het verschil telt het meest bij ingebedde en gecontaineriseerde producten. Een scan op taalniveau kan OS-pakketten in een containerbasislayer missen. Een Yocto- of Buildroot-export kan silicon-vendor-firmware, bootloaders, kernelmodules of binaire blobs missen die buiten het buildsysteem zijn binnengekomen. Als die componenten in het geleverde artefact zitten, horen ze in het releasemateriaal, ook als een geautomatiseerde pakketscanner ze niet automatisch kan afleiden.

De oplossing is genereren vanuit het releaseartefact of de image en dat vervolgens vergelijken met broncode- en lockfile-uitvoer. Scan voor containers de definitieve image op digest. Combineer voor firmware de SBOM-uitvoer van het buildsysteem met binaire analyse en handmatige records voor componenten die tools niet automatisch kunnen identificeren.

Fout 2: ontbrekende hashes en PURL's maken componenten niet te koppelen

Een SBOM zonder accurate versie-, hash-, leveranciers- en pakketidentificatoren is moeilijk te gebruiken voor kwetsbaarheidsmatching. Het bestand kan machineleesbaar zijn, maar een scanner heeft nog steeds stabiele componentidentiteit nodig om te bepalen of een CVE, OSV-advisory, GitHub Security Advisory of CISA KEV-vermelding van toepassing is.

Elk component moet voldoende identiteit bevatten om geautomatiseerde matching te doorstaan:

Dit is niet puur hygiëne. NIST kondigde op 15 april 2026 aan dat NVD-verrijking nu prioriteit krijgt voor geselecteerde CVE's omdat het kwetsbaarheidsvolume de capaciteit voor volledige verrijking heeft overschreden. Dat maakt matching op alleen CPE een zwakker plan voor toekomstige kwetsbaarheidsbeheeroperaties. Gebruik PURL waar beschikbaar, bewaar hashes voor geleverde artefacten en beschouw een componentnaam alleen niet als voldoende.

Een veelgemaakte formatfout is het gebruik van CycloneDX 1.3 of eerder. Kernondersteuning voor VEX arriveerde in CycloneDX 1.4 en de rijkere component evidence-structuur arriveerde in CycloneDX 1.5. Voor de huidige CRA-voorbereiding streeft u naar CycloneDX 1.6 of later, of een huidig SPDX-profiel dat uw tools betrouwbaar kunnen gebruiken. Controleer de uitvoer van uw generator voordat u aanneemt dat de indeling de velden ondersteunt die uw proces nodig heeft.

Fout 3: stoppen bij directe afhankelijkheden

Directe afhankelijkheden zijn de CRA-minimumondergrens. Ze zijn onvoldoende voor nuttig kwetsbaarheidsbeheer. Een transitieve afhankelijkheid is een component die door een ander component wordt binnengehaald en kan de kwetsbaarheid dragen die ertoe doet. Als een CVE een transitief pakket treft dat uw SBOM niet vermeldt, kan het product getroffen zijn terwijl uw matchingpipeline stil blijft.

Om dit te sluiten gebruikt u lockfiles waar het ecosysteem dat ondersteunt, scant u gebouwde artefacten naast broncode en inspecteert u pakketten die afhankelijkheden bundelen of inpakken. Behandel transitieve dekking als een auditkwaliteitspraktijk, niet als een vrijblijvende instelling die verborgen zit in een standaardinstelling van de scanner.

Fout 4: de SBOM als eenmalig document behandelen

Een eenmalig gegenereerde en nooit bijgewerkte SBOM geeft een vals veiligheidsgevoel. Nieuwe CVE's worden gepubliceerd tegen componenten die al in het product zitten. Nieuwe firmwareversies, patches en leveranciersupdates veranderen het product. De CRA verwacht ook dat de technische documentatie doorlopend wordt bijgewerkt waar van toepassing gedurende de ondersteuningsperiode.

Veelvoorkomende updatetriggers:

CI/CD is de praktische controle. Elke release moet een actueel SBOM-artefact opleveren dat naast de build wordt opgeslagen en is gekoppeld aan de technische documentatie. Handmatige vermeldingen mogen alleen bestaan voor componenten die tools niet kunnen detecteren, en die vermeldingen moeten nog steeds worden beoordeeld als het product verandert.

Fout 5: interne, eigen en firmwarecomponenten weglaten

Een veelgebruikte afkorting is het documenteren van alleen opensource-afhankelijkheden en het weglaten van interne bibliotheken, commerciële modules, eigen firmware of vendor-blobs. Dat is geen product-SBOM. Als een component in het product wordt geleverd, hoort hij in de reikwijdte, ook als hij geen openbare registerpagina heeft.

Interne componenten hebben vaak geen ecosysteem-PURL of openbare pakketvermelding. Gebruik een interne identificator, uw eigen organisatie als leverancier waar van toepassing, de exacte versie of build-ID en de hash van het binaire artefact. Houd voor commerciële componenten leveranciersnaam, versie, licentiebewijsmateriaal en contract-/bronreferenties bij in de technische documentatie.

Voor hardware-softwareproducten is firmware waar dit zichtbaar wordt. Wi-Fi-modules, modems, secure elements, bootloaders, trusted execution environment-binaries en out-of-tree kernelmodules kunnen kwetsbaarheden bevatten maar blijven onzichtbaar voor taalpakketscanner. Gebruik leveranciers-SBOM's waar beschikbaar, voeg handmatige records toe waar niet en gebruik binaire analyse als controle. Zie voor de hardwarekant van het bewijspakket HBOM onder de CRA.

Fout 6: steunen op SBOM's van leveranciers als eindresultaat

SBOM's van leveranciers zijn geldige invoer. Ze zijn niet uw eindproduct-SBOM. De fabrikant brengt het geïntegreerde product op de EU-markt. De product-SBOM moet leverancierscomponenten, eerste-partijcode, builduitvoer, firmware, integratiecode en productspecifieke afhankelijkheidsrelaties combineren.

De foutmodus is gemakkelijk te missen: één leverancier geeft u een CycloneDX-bestand, een andere geeft SPDX, een derde geeft een PDF-inventarisatie en de uiteindelijke productmap bevat koppelingen naar alle drie. Dat is leveranciersbewijsmateriaal, niet één productrecord. Een reviewer moet nog steeds weten welke componenten in productversie 1.4.2 zaten.

Reconcilieer in plaats van kopieer. Voeg leveranciers-SBOM's samen in de product-SBOM, normaliseer identiteitsvelden, leg bekende onbekenden vast en bewaar de upstream SBOM's als ondersteunend bewijsmateriaal. Als een leveranciers-SBOM PURL, hash, licentie of exacte versie mist, documenteer de leemte en sluit wat u kunt vóór de release. Een URL naar een upstream bestand is niet hetzelfde als een geïntegreerde product-SBOM.

Fout 7: veel SBOM's, geen enkel productrecord

SBOM-versnippering is de fase nadat teams tools gaan gebruiken. Er is een app-SBOM, een container-SBOM, een firmware-SBOM, meerdere leveranciers-SBOM's en een spreadsheet die door een productmanager wordt bijgehouden. Geen van hen is het gezaghebbende antwoord voor de productrelease die op de markt is gebracht.

Dat creëert audit- en operationeel risico. Als een nieuwe actief uitgebuite kwetsbaarheid verschijnt, moet het team door fragmenten zoeken voordat het kan zeggen of het product getroffen is. Als een autoriteit een gemotiveerd verzoek doet, mag het bewijspakket niet afhangen van iemand die zich herinnert welke map de laatste samenvoeging bevat.

Gebruik één gezaghebbende product-SBOM per release, met ondersteunende component-SBOM's die daaronder worden bewaard. Bewaar hem ten minste 10 jaar nadat het product op de markt is gebracht, of voor de ondersteuningsperiode, afhankelijk van wat langer is. Sla hem op waar de release, kwetsbaarheidsbewaking, VEX-beslissingen en technische documentatie allemaal naar dezelfde versie kunnen verwijzen.