De flesta tillverkare upptäcker luckor i sin SBOM under den första efterlevnadsgranskningen, inte innan. Då är tidsgränsen för tillämpning närmare och åtgärdsarbetet mer omfattande. CRA:s SBOM-skyldighet enligt Bilaga I är enkel att formulera: maskinläsbart format, åtminstone produktens viktigaste (top-level) beroenden, lagrad i din tekniska fil enligt Bilaga VII. Det som skapar problem för tillverkare är formuleringen "åtminstone". Den här artikeln behandlar sex misstag som skapar den största klyftan mellan en formell SBOM och en som klarar granskning från en marknadskontrollmyndighet.
Sammanfattning
- Att stanna vid direkta beroenden lämnar transitiva sårbarheter utanför SBOM:en
- En SBOM som skapas en gång blir inaktuell inom veckor när nya CVE:er publiceras
- Saknade hashvärden och PURL-identifierare klarar inte BSI TR-03183:s kvalitetskontroller
- Manuell SBOM-skapning uppfyller inte CRA:s löpande uppdateringsskyldighet
- Interna och proprietära komponenter måste finnas med vid sidan av bibliotek med öppen källkod
- Leverantörers SBOM:ar är råmaterial, inte en färdig efterlevnadsartefakt
Misstag i korthet
| # | Misstag | Varför det brister | Åtgärd |
|---|---|---|---|
| 1 | Stannar vid direkta beroenden | Transitiva CVE:er osynliga för skannrar | Låsfiler och skanning av byggartefakter |
| 2 | Behandlar SBOM som engångsdokument | Inaktuell inom veckor vid nya CVE:er | CI/CD-generering per bygge |
| 3 | Saknade identitetsfält | Ingen CVE-matchning, TR-03183 misslyckas | Exakt version, SHA-256, PURL, leverantör |
| 4 | Manuell generering | Håller inte jämna steg med versioner | Automatisering med Syft, Trivy eller cdxgen |
| 5 | Hoppar över interna eller proprietära komponenter | Bilaga I gör ingen sådan åtskillnad | Interna ID:n, dig själv som leverantör, SHA-256 |
| 6 | Behandlar leverantörers SBOM:ar som färdiga | Tillverkaren äger Bilaga I-skyldigheten | Konsolidera till en produkt-SBOM |
Misstag 1: stanna vid direkta beroenden
Bilaga I, del II, punkt 1 sätter den rättsliga minimumnivån vid produktens viktigaste (top-level) beroenden. Många tillverkare stannar precis där. Problemet är inte att uppfylla den rättsliga minimumnivån. Problemet är den risk som minimumnivån lämnar utanför din synlighet. Ett transitivt beroende (ett bibliotek som ditt direkta beroende i sin tur beror på) är lika möjligt att utnyttja som ett direkt. När en CVE publiceras mot ett transitivt paket som din SBOM inte listar kan du inte matcha den, inte rapportera den, och du är exponerad utan att veta om det.
Din produkt
+-- Bibliotek A (direkt) ← rättslig minimumnivå, Bilaga I-golvet
| +-- Bibliotek B (transitivt) ← utanför SBOM, osynligt för sårbarhetsskannrar
| \-- Bibliotek C (transitivt) ← utanför SBOM, osynligt för sårbarhetsskannrar
\-- Bibliotek D (direkt) ← rättslig minimumnivå, Bilaga I-golvet
Åtgärden är rätt verktyg och konfiguration. Använd låsfiler och skanna byggartefakter snarare än enbart källkod. Trivy, Syft och cdxgen stöder alla insamling av transitiva beroenden när de konfigureras korrekt. BSI TR-03183 behandlar full transitivtäckning som den kvalitetsindikator som skiljer en minimalt godkänd SBOM från en genuint användbar. Se BSI TR-03183 kvalitetsnivåer för fältkraven på varje nivå.
Misstag 2: 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 dagligen mot komponenter som redan finns i din produkt. En SBOM som var korrekt vid byggtillfället blir inaktuell inom veckor. CRA:s skyldighet enligt Bilaga I är löpande: SBOM:en måste återspegla produktens aktuella tillstånd under hela supportperioden.
Obligatoriska uppdateringstriggers under CRA:
| Trigger | Vad som förändras | SBOM-uppdatering krävs? |
|---|---|---|
| Ny firmware- eller programvaruversion | Ny byggartefakt | Ja, fullständig regenerering |
| Säkerhetskorrigering | Komponentversion höjd | Ja, berörda komponenter |
| Sårbarhet upptäckt och åtgärdad | VEX eller exploaterbarhetsstatus | Ja, VEX-fält |
| Komponent tillagd, borttagen eller ersatt | Beroendeträd | Ja, fullständig regenerering |
| Designändring som påverkar säkerheten | Komponenter och arkitektur | Ja, fullständig regenerering |
Åtgärden är CI/CD-integration. Varje bygge bör producera en aktuell SBOM-artefakt lagrad tillsammans med versionen. En manuell export kan inte hålla jämna steg med den uppdateringsfrekvens CRA kräver. Se CRA SBOM-krav för den fullständiga listan av triggers och 10-årslagringsklockan.
Från och med 11 september 2026 måste du rapportera aktivt utnyttjade sårbarheter till ENISA inom 24 timmar. En inaktuell SBOM innebär att du inte kan avgöra om din produkt är drabbad innan klockan börjar ticka. Du behöver aktuella komponentdata innan incidenten inträffar, inte efter.
Misstag 3: saknade identitetsfält
En SBOM utan korrekta versions-, hash- och identifierarfält är nästan värdelös för sårbarhetsmatchning. Dessa fält kopplar en komponentpost till en CVE-post i National Vulnerability Database (NVD), OSV eller CISA KEV. Utan dem kan sårbarhetsskannrar inte matcha mot dina komponenter, och BSI TR-03183:s kvalitetskontroller misslyckas.
Varje komponent måste innehålla:
| Fält | Varför det spelar roll | Källa |
|---|---|---|
| Exakt versionsnummer | Krävs för CVE/NVD/OSV-matchning (inte "latest" eller intervall) | Bilaga I; TR-03183 obligatoriskt |
| SHA-256-hash | Integritetskontroll för binära komponenter | TR-03183 obligatoriskt |
| PURL-identifierare | Kopplar komponenten till sin registerpost | TR-03183 obligatoriskt |
| Leverantörsnamn | Krävs på varje kvalitetsnivå | Bilaga I; TR-03183 |
Ett vanligt versionsmisstag är att använda CycloneDX 1.3 eller tidigare. Grundläggande VEX-stöd tillkom i CycloneDX 1.4 (januari 2022), och den rikare evidence-strukturen (identity, occurrences) som används för att visa CRA-spårbarhet kom i 1.5 (juni 2023). Sikta på CycloneDX 1.6 eller senare för CRA-konformitet. Kontrollera ditt verktygs utdataversion innan du antar att efterlevnad uppnåtts.
Misstag 4: generera SBOM:ar manuellt
Manuell SBOM-skapning är felbenägen och skalerar inte över produktversioner. En handgjord SBOM missar komponenter som automatiserade verktyg skulle hitta, innehåller stavfel i versionssträngar och kan inte genereras tillförlitligt om en komponent ändras. Viktigare: en manuell process kan inte uppfylla CRA:s löpande uppdateringsskyldighet. Varje version, varje korrigering och varje komponentändring kräver en uppdaterad SBOM.
Automatisera genereringen med Syft, Trivy eller cdxgen. Manuella poster bör reserveras för komponenter som automatiserade verktyg inte kan identifiera, till exempel kommersiella bibliotek utan paketdatabasposter eller proprietära firmware-blobbar. Allt annat ska komma från bygget. Marknadskontrollmyndigheter kan begära SBOM:en när som helst; den måste återspegla produktens aktuella tillstånd.
Misstag 5: ignorera interna och proprietära komponenter
En vanlig genväg är att dokumentera bara beroenden med öppen källkod och utelämna interna bibliotek, proprietära moduler eller firmware-blobbar. Bilaga I gör ingen sådan åtskillnad. Om en komponent finns i produkten hör den hemma i SBOM:en.
Interna komponenter saknar ofta PURL eller registerpost. Rätt tillvägagångssätt är att tilldela en intern identifierare, lista din egen organisation som leverantör och ta med SHA-256-hashen för binärartefakten. BSI TR-03183 täcker uttryckligen proprietära komponenter på alla kvalitetsnivåer.
För produkter med inbyggd firmware från en ODM eller chipleverantör kan du inte granska det du inte byggt. Åtgärden är avtalsmässig: kräv SBOM-leverans från dina firmwareleverantörer. Under CRA är du ansvarig för hela produkten oavsett vem som skrev koden. För hårdvaru-mjukvaruprodukter, se HBOM under CRA för när en Hardware Bill of Materials behövs vid sidan av SBOM:en.
Misstag 6: förlita sig på leverantörers SBOM:ar som den färdiga artefakten
Leverantörers SBOM:ar är ett giltigt underlag, och CRA förväntar sig att tillverkare utnyttjar dokumentation från uppströmsledet. De ersätter inte en integrerad produkt-SBOM. Bilaga I-skyldigheten vilar på tillverkaren av den produkt som släpps ut på EU-marknaden: du måste konsolidera leverantörers SBOM:ar med dina egna förstapartskomponenter, byggberoenden och limkod till en enda SBOM för den integrerade produkten.
Om en leverantörs SBOM saknar fält som krävs av BSI TR-03183 (PURL, hash, licens) är du ansvarig för att fylla de luckorna innan din produkt skickas. Behandla leverantörers SBOM:ar som råmaterial. Din produkt-SBOM är den färdiga efterlevnadsartefakten.
Vanliga frågor
Kan jag återanvända SBOM:ar från mina leverantörer för att uppfylla CRA?
Delvis. Leverantörers SBOM:ar är ett giltigt underlag för de komponenter de levererar, och CRA förväntar sig att tillverkare utnyttjar dokumentation från uppströmsledet. Men skyldigheten enligt Bilaga I ligger på tillverkaren av den produkt som släpps ut på EU-marknaden: du måste producera och underhålla en SBOM för den integrerade produkten, vilket innebär att du konsoliderar leverantörers SBOM:ar med dina egna förstapartskomponenter, dina byggberoenden och eventuell limkod. Om en leverantörs SBOM saknar fält som krävs av BSI TR-03183 (PURL, hash, licens) är du ansvarig för att fylla de luckorna innan din produkt skickas. Behandla leverantörers SBOM:ar som råmaterial, inte som en färdig efterlevnadsartefakt.
Vad är den rättsliga minimumnivån för SBOM-beroendekäckning under CRA?
Bilaga I, del II, punkt 1 sätter golvet vid produktens viktigaste (top-level) beroenden. Den officiella texten lyder: "identifiera och dokumentera sårbarheter och komponenter i produkter med digitala element, bland annat genom att upprätta en programvaruförteckning för material i ett allmänt använt och maskinläsbart format som åtminstone täcker produktens viktigaste (top-level) beroenden". Det innebär att direkta beroenden är den rättsliga minimumnivån. Transitiva beroenden är inte rättsligt obligatoriska men rekommenderas starkt som bästa praxis: de är vad sårbarhetsskannrar faktiskt behöver för att matcha CVE:er korrekt, och BSI TR-03183 räknar transitivtäckning som en kvalitetsindikator.
Behöver en SBOM uppdateras vid varje korrigeringsversion?
Ja. Varje säkerhetskorrigering är en obligatorisk SBOM-uppdateringstrigger under CRA. Den tekniska filen, som inkluderar SBOM:en, måste hållas aktuell under hela produktlivscykeln. Om du korrigerar en sårbar komponent måste din SBOM återspegla den nya versionen. Automatisera SBOM-generering i CI/CD så att korrigeringsversioner automatiskt producerar en uppdaterad SBOM-artefakt, utan ett manuellt steg som kan missas under tidspress.