CRA SBOM-misstag: 7 praktiska åtgärder för tillverkare

SBOM-generatorn körs, filen validerar och ändå kan nästa produktgranskning hitta luckor. De återkommande CRA-problemen är sällan obskyra juridiska gränsfall. Det handlar om grunda beroendeträd, källbaserade inventarier, inaktuella poster och komponenter som skannrar inte kan matcha mot en sårbarhet. Cyberresiliensförordningen kräver ett SBOM i ett allmänt använt, maskinläsbart format som täcker åtminstone dina direkta beroenden och förvaras tillsammans med den tekniska dokumentationen. Den här artikeln går igenom de sju luckorna mellan en SBOM som tekniskt sett finns och en som kan stödja sårbarhetshantering. Det är den SBOM en marknadskontrollmyndighet förväntar sig att se.

Misstag i korthet

• Källträd, inte levererad artefakt: generera från den byggda artefakten eller imagen så att kompilerad kod, OS-paket och firmware syns.
• Tunna identitetsfält: använd exakta versioner, hashvärden och PURL-identifierare där tillgängliga, samt leverantörsnamn så att skannrar kan matcha CVE:er.
• Enbart direkta beroenden: lägg till skanning av låsfiler och byggda artefakter så att indirekta och paketerade beroenden ingår i SBOM:en.
• Engångsfil: regenerera och arkivera SBOM:en vid varje version och håll sårbarhetsmatchningen aktuell.
• Utelämnad produktkod: interna, proprietära, kommersiella och firmware-komponenter behöver fortfarande identifierare och dokumentationsunderlag.
• Leverantörskopiera-klistra: leverantörers SBOM:ar är underlag. Stäm av dem mot egenproducerad kod och den slutliga releaserartefakten.
• SBOM-spridning: ha en auktoritativ produkt-SBOM per version så att version 1.4.2 har ett enda försvarbart underlag.

Vad som spelar roll för SBOM-underlag

Det juridiska minimigolvet är inte detsamma som ett operativt minimigolv för sårbarhetshantering. En SBOM med enbart direkta beroenden kan uppfylla den minimiformulering som gäller beroenden men vara för grund för att snabbt identifiera berörda produkter. BSI TR-03183, ENISA:s vägledning, CISA:s SBOM-vägledning och aktuell verktygspraxis är bäst att läsa som kvalitetsmått som hjälper tillverkare att omsätta CRA-skyldigheten i praktiken.

Misstag 1: din SBOM beskriver källträdet, inte den produkt du levererade

Källmanifest är praktiska, men de är inte produkten. En källsökning kan överapportera utvecklingsberoenden och missa det som bara uppstår efter bygge, paketering, containerlagerläggning, statisk länkning eller firmware-integration. För en tillverkare ska SBOM:en svara på vad som ingick i produktversionen, inte bara vad som deklarerades i en paketfil.

Skillnaden spelar störst roll för inbyggda och containeriserade produkter. En sökning på språknivå kan missa OS-paket i ett containers baslager. En Yocto- eller Buildroot-export kan missa kiselleverantörers firmware, bootloaders, kärnmoduler eller binära blobbar som kom in utanför byggsystemet. Om dessa komponenter finns i den levererade artefakten hör de hemma i releaseunderlaget, även när en automatisk paketskanner inte kan härleda dem.

Lösningen är att generera från releaserartefakten eller imagen och sedan jämföra med utdata från källkod och låsfiler. För containrar, skanna den slutliga imagen via digest. För firmware, kombinera byggsystemets SBOM-utdata med binäranalys och manuella poster för komponenter som verktyg inte kan identifiera automatiskt.

Misstag 2: saknade hashvärden och PURL-identifierare gör komponenter omatchningsbara

En SBOM utan korrekta versions-, hash-, leverantörs- och paketidentifierare är svår att använda för sårbarhetsmatchning. Filen kan vara maskinläsbar, men en skanner behöver ändå stabil komponentidentitet för att avgöra om en CVE, ett OSV-råd, ett GitHub Security Advisory eller en CISA KEV-post gäller.

Varje komponent bör bära tillräcklig identitet för att klara automatisk matchning:

Det handlar inte bara om hygien. NIST meddelade den 15 april 2026 att NVD-berikandet nu prioriteras för utvalda CVE:er eftersom volymen sårbarheter har överskridit kapaciteten för fullständig berikning. Det gör CPE-baserad matchning till ett svagare alternativ för framtida sårbarhetsarbete. Använd PURL där det finns, behåll hashvärden för levererade artefakter och behandla inte ett komponentnamn ensamt som tillräckligt.

Ett vanligt formatmisstag är att använda CycloneDX 1.3 eller tidigare. Grundläggande VEX-stöd kom i CycloneDX 1.4, och den rikare evidence-strukturen för komponenter kom i CycloneDX 1.5. För aktuell CRA-förberedelse, sikta på CycloneDX 1.6 eller senare, eller en aktuell SPDX-profil som dina verktyg kan använda tillförlitligt. Kontrollera ditt generators utdata innan du antar att formatet stödjer de fält din process behöver.

Misstag 3: stanna vid direkta beroenden

Direkta beroenden är CRA:s minimigolv. De räcker inte för användbar sårbarhetshantering. Ett transitivt beroende är en komponent som dras in av en annan komponent och kan bära den sårbarhet som spelar roll. När en CVE träffar ett transitivt paket som din SBOM inte listar kan produkten vara drabbad medan din matchningspipeline är tyst.

För att stänga den här luckan, använd låsfiler där ekosystemet stöder det, skanna byggda artefakter liksom källkod och granska paket som buntar eller skuggar beroenden. Behandla transitiv täckning som en revisionskvalitetsstandard, inte som en slapp inställning dold i en skanners standardvärden.

Misstag 4: behandla SBOM:en som ett engångsdokument

En SBOM som genereras en gång och aldrig uppdateras skapar en falsk trygghet. Nya CVE:er publiceras mot komponenter som redan finns i produkten. Nya firmwareversioner, patchar och leverantörsuppdateringar förändrar produkten. Cyberresiliensförordningen förväntar sig också att teknisk dokumentation uppdateras löpande där det är lämpligt under supportperioden.

Vanliga uppdateringstriggers:

CI/CD är den praktiska kontrollen. Varje version bör producera en aktuell SBOM-artefakt lagrad tillsammans med bygget och länkad till den tekniska dokumentationen. Manuella poster bör bara finnas för komponenter som verktyg inte kan identifiera, och dessa poster behöver fortfarande granskning när produkten ändras.

Misstag 5: utelämna interna, proprietära och firmware-komponenter

En vanlig genväg är att bara dokumentera beroenden med öppen källkod och utelämna interna bibliotek, kommersiella moduler, proprietär firmware eller leverantörsblobbar. Det är inte en produkt-SBOM. Om en komponent levereras med produkten hör den till räckvidden, även när den saknar en offentlig registersida.

Interna komponenter saknar ofta ekosystem-PURL eller offentlig paketpost. Använd en intern identifierare, din organisation som leverantör där det är lämpligt, den exakta versionen eller bygg-ID:t och hashen för binärartefakten. För kommersiella komponenter, behåll leverantörsnamn, version, licensbevis och kontraktshänvisningar i den tekniska dokumentationen.

För produkter med hårdvara och mjukvara är firmware det ställe där detta tydliggörs. Wi-Fi-moduler, modem, säkra element, bootloaders, trusted execution environment-binärer och out-of-tree-kärnmoduler kan bära sårbarheter men förblir osynliga för skannrar på paketspråksnivå. Använd leverantörers SBOM:ar där de finns, lägg till manuella poster där de inte finns och använd binäranalys som kontroll. För hårdvarusidan av dokumentationspaketet, se HBOM under CRA.

Misstag 6: förlita sig på leverantörers SBOM:ar som den färdiga artefakten

Leverantörers SBOM:ar är giltiga underlag. De är inte din färdiga produkt-SBOM. Tillverkaren släpper ut den integrerade produkten på EU-marknaden. Produkt-SBOM:en måste kombinera leverantörskomponenter, egenproducerad kod, byggesutdata, firmware, integrationskod och produktspecifika beroendeförhållanden.

Felbeteendet är lätt att missa: en leverantör ger dig en CycloneDX-fil, en annan ger SPDX, en tredje ger en PDF-inventering och produktmappen innehåller länkar till alla tre. Det är leverantörsunderlag, inte ett produktunderlag. En granskare behöver fortfarande veta vilka komponenter som ingick i produktversion 1.4.2.

Stäm av istället för att kopiera. Slå samman leverantörers SBOM:ar i produkt-SBOM:en, normalisera identitetsfält, registrera kända oklarheter och behåll uppströms-SBOM:arna som stödunderlag. Om en leverantörs-SBOM saknar PURL, hash, licens eller exakt version, dokumentera luckan och åtgärda vad du kan innan lanseringen. En URL till en uppströmsfil är inte samma sak som en integrerad produkt-SBOM.

Misstag 7: många SBOM:ar, inget enda produktunderlag

SBOM-spridning är det stadium som uppstår efter att team börjat använda verktyg. Det finns en app-SBOM, en container-SBOM, en firmware-SBOM, flera leverantörs-SBOM:ar och ett kalkylblad som underhålls av en produktansvarig. Ingen av dem är det auktoritativa svaret för den produktversion som släpptes ut på marknaden.

Det skapar revisions- och driftsrisk. När en ny aktivt utnyttjad sårbarhet dyker upp måste teamet söka igenom fragment innan det kan avgöra om produkten är drabbad. När en myndighet gör en välgrundad begäran ska dokumentationspaketet inte bero på att någon minns vilken mapp som innehåller den senaste sammanfogningen.

Använd en auktoritativ produkt-SBOM per version, med stödjande komponent-SBOM:ar bevarade under den. Spara den i minst 10 år efter att produkten släppts ut på marknaden, eller under supportperioden, beroende på vilket som är längst. Förvara den där versionen, sårbarhetsbevakningen, VEX-besluten och den tekniska dokumentationen alla kan referera till samma version.