SBOM-krav enligt EU:s Cyber Resilience Act (CRA)

EU:s CRA SBOM-krav förklarade: godkända format, obligatoriska fält, BSI TR-03183 kvalitetsnivåer och efterlevnadsdeadlines för tillverkare.

CRA Evidence Team Publicerad 20 december 2025 Uppdaterad 11 april 2026
SBOM-sköldsikon med EU Cyber Resilience Act (CRA)-varumärke mot en teal kretskortsbakgrund
I denna artikel

Varje produkt med digitala element som säljs på EU-marknaden måste från och med december 2027 ha en Software Bill of Materials (SBOM). Det är ett lagkrav enligt EU:s Cyber Resilience Act (CRA). Den här guiden förklarar vad CRA och BSI TR-03183 kräver, vilka format som godkänns, vilka fält din SBOM måste innehålla och när deadlines gäller.

Sammanfattning

  • SBOM:er är obligatoriska enligt CRA. Varje produkt med digitala element behöver en.
  • Godkända format: CycloneDX (säkerhetsfokuserat) eller SPDX (licensfokuserat)
  • Måste inkludera alla beroenden (direkta och transitiva), inte bara toppnivåkomponenter
  • BSI TR-03183 sätter kvalitetsstandarden. Använd den som ditt efterlevnadsmål.
  • Automatisera SBOM-generering i CI/CD. Manuella processer skalas inte.
  • SBOM:er måste underhållas under hela supportperioden (minst 5 år)

Viktigt: SBOM:er är obligatoriska enligt CRA, inte valfria. Varje produkt med digitala element som placeras på EU-marknaden måste ha en maskinläsbar SBOM.

Vad är en SBOM?

En Software Bill of Materials (SBOM) är ett strukturerat register över alla programvarukomponenter i en produkt: bibliotek, ramverk, operativsystempaket och deras beroenden. Tänk på det som en innehållsförteckning för programvara: den listar exakt vad som finns inuti så att köpare och tillsynsmyndigheter kan bedöma risker, spåra sårbarheter och kontrollera licenser.

Vad kräver CRA för SBOM:er?

CRA refererar till SBOM:er i två kritiska avsnitt:

Bilaga I: Väsentliga krav

"Tillverkare ska identifiera och dokumentera sårbarheter och komponenter i produkter, bland annat genom att upprätta en programvarulista i ett vanligt förekommande och maskinläsbart format."

Det innebär att:

  • SBOM:er är obligatoriska, inte valfria
  • De måste vara i maskinläsbart format (inte PDF:er eller kalkylblad)
  • De måste täcka alla komponenter, inklusive transitiva beroenden

Bilaga VII: Teknisk dokumentation

Den tekniska filen måste innehålla SBOM-information som möjliggör:

  • Sårbarhetsspårning på komponentnivå
  • Identifiering av leverantörer
  • Kontroll av licensefterlevnad
  • Planering för livscykelns slut

Vilka SBOM-format godkänns enligt CRA?

CRA kräver "vanligt förekommande och maskinläsbara" format. I praktiken kvalificerar sig två standarder:

Format Standard Passar bäst för
CycloneDX OWASP Säkerhetsfokuserat, inbyggt VEX-stöd
SPDX Linux Foundation Licensefterlevnad, bredare användning

Båda formaten godkänns, men CycloneDX föredras alltmer för säkerhetsändamål tack vare inbyggt stöd för:

  • Vulnerability Exploitability eXchange (VEX)
  • Säkerhetsrådgivningar
  • Beroendegraf
graph TD
    SBOM((SBOM))
    SCN[Component Names] --> SBOM
    VS[Versions] --> SBOM
    SUP[Supplier Info] --> SBOM
    DEP[Dependencies] --> SBOM
    LIC[Licenses] --> SBOM
    PURL[Package URLs] --> SBOM
    HASH[Hash Values] --> SBOM
    OSC[Open Source Components] --> SBOM
    style SBOM fill:#008080,color:#fff,stroke:#006666,stroke-width:4px
    style SCN fill:#e8f4f8,stroke:#008080,color:#333
    style VS fill:#e8f4f8,stroke:#008080,color:#333
    style SUP fill:#e8f4f8,stroke:#008080,color:#333
    style DEP fill:#e8f4f8,stroke:#008080,color:#333
    style LIC fill:#e8f4f8,stroke:#008080,color:#333
    style PURL fill:#e8f4f8,stroke:#008080,color:#333
    style HASH fill:#e8f4f8,stroke:#008080,color:#333
    style OSC fill:#e8f4f8,stroke:#008080,color:#333

Vilka fält måste en SBOM innehålla?

Tysklands federala kontor för informationssäkerhet (BSI) har publicerat TR-03183, som ger detaljerade SBOM-kvalitetskrav som går längre än CRA:s minimum. Använd den som ditt efterlevnadsmål.

Obligatoriska fält (BSI TR-03183)

  • Komponentnamn och version
  • Information om leverantör och tillverkare
  • Unika identifierare (PURL, CPE)
  • Beroendeförhållanden
  • Licensinformation

Kvalitetsnivåer

TR-03183 definierar tre kvalitetsnivåer:

Nivå Beskrivning
Grundläggande Minimifält ifyllda
Standard Alla rekommenderade fält
Uttömmande Fullständigt beroendeträd, hashverifiering

Även om TR-03183 är en tysk standard håller den på att bli det faktiska kvalitetsriktmärket för CRA-efterlevnad inom hela EU.

Vilka är CRA:s SBOM-efterlevnadsdeadlines?

CRA har en stegvis tidslinje för genomdrivande:

Datum Milstolpe
11 september 2026 Rapporteringsskyldigheter för sårbarheter träder i kraft. Tillverkare måste rapportera aktivt utnyttjade sårbarheter inom 24 timmar.
11 december 2027 Fullt genomdrivande. Alla produkter med digitala element måste uppfylla CRA-krav inklusive kompletta SBOM:er.

Produkter som placeras på EU-marknaden efter december 2027 och saknar en godkänd SBOM kan inte bära CE-märkning och kan inte säljas lagligt.

Vad händer om du inte efterlever?

Bristande efterlevnad av CRA får allvarliga konsekvenser:

  • Böter på upp till 15 miljoner euro eller 2,5 % av global årsomsättning (det högre värdet gäller)
  • Produktåterkallelse eller tillbakadragande från EU-marknaden
  • Marknadsförbud: produkter som inte efterlever kraven kan inte bära CE-märkning
  • Påverkan på leveranskedjan: dina kunder kan bli oförmögna att använda din produkt i sin egen CRA-efterlevnad

Marknadstillsynsmyndigheter i varje EU-medlemsstat kommer att driva igenom dessa påföljder.

Vanliga SBOM-misstag

1. Ofullständiga beroendeträd

Många verktyg fångar bara direkta beroenden. CRA kräver transitiva beroenden, det vill säga komponenter som dina beroenden i sin tur beror på.

Your Product
+-- Library A (direct) ✓
|   +-- Library B (transitive) ← Often missing!
|   \-- Library C (transitive) ← Often missing!
\-- Library D (direct) ✓

2. Saknad versionsinformation

En SBOM utan korrekt versionsinformation är nästan värdelös för sårbarhetsmatchning. Se till att varje komponent har:

  • Exakta versionsnummer (inte intervall)
  • Hashvärden för binära komponenter
  • PURL-identifierare där möjligt

3. Inaktuella SBOM:er

En SBOM som genereras vid byggtillfället men aldrig uppdateras skapar en falsk trygghetskänsla. Implementera:

  • CI/CD-integration för automatisk SBOM-generering
  • Versionskontroll för SBOM-artefakter
  • Regelbunden avvikelsedetektion mellan byggen

4. Att ignorera firmware och hårdvara

För produkter med inbyggda komponenter, kom ihåg att inkludera:

Hur du kommer igång

  1. Granska ditt nuläge: Genererar du SBOM:er i dag? Vilket format? Vilken täckning?

  2. Välj ditt format: CycloneDX för säkerhetsfokus, SPDX för licensefterlevnad (eller båda)

  3. Automatisera generering: Integrera SBOM-generering i din CI/CD-pipeline med verktyg som Syft, Trivy eller cdxgen

  4. Validera kvalitet: Kontrollera dina SBOM:er mot TR-03183-krav. Är alla obligatoriska fält ifyllda?

  5. Implementera övervakning: Koppla SBOM:er till sårbarhetsdatabaser (NVD, OSV, GitHub Advisory Database, CISA KEV)

  6. Planera för uppdateringar: Skapa processer så att varje produktrelease genererar en ny, validerad SBOM

Vanliga frågor

Vilka SBOM-format godkänner CRA?

CRA kräver format som är "vanligt förekommande och maskinläsbara". CycloneDX (OWASP) och SPDX (Linux Foundation) är de två format som uppfyller det kravet. Förordningen namnger dem inte explicit, men inga andra format når upp till standarden i praktiken.

Uppfyller NTIA:s minimumelement CRA:s krav?

NTIA:s minimumelement (leverantörsnamn, komponentnamn, version, unika identifierare, beroendeförhållanden, SBOM-författare och tidsstämpel) stämmer i stort sett överens med vad CRA och BSI TR-03183 kräver på grundnivå. De utgör en rimlig startpunkt, men TR-03183:s obligatoriska fält går längre: hashvärden och PURL-identifierare förväntas för CRA-efterlevnad. CERT-SE (MSB) följer BSI TR-03183 som det praktiska kvalitetsriktmärket för svenska tillverkare.

Kräver CRA en SBOM för komponenter med öppen källkod?

Ja. Bilaga I anger att tillverkare måste dokumentera komponenter i en maskinläsbar SBOM utan undantag för öppen källkod. Om ett bibliotek med öppen källkod finns i din produkt måste det finnas med i din SBOM med versions- och identifieringsinformation.

Måste en SBOM lämnas in vid marknadsutsläppande eller på begäran?

SBOM:en behöver inte lämnas in proaktivt. Den måste ingå i den tekniska filen (Bilaga VII) och vara tillgänglig för marknadstillsynsmyndigheter på begäran. Den måste finnas vid den tidpunkt då produkten placeras på EU-marknaden.

Kräver CRA en maskinläsbar SBOM eller är en PDF godtagbar?

Bilaga I kräver explicit maskinläsbart format. En PDF är inte godtagbar. CycloneDX eller SPDX serialiserat som JSON eller XML uppfyller kravet. Ett kalkylblad eller ett läsbart dokument gör det inte.

Hur länge måste en SBOM sparas efter att en produkt dras tillbaka?

Den tekniska filen, inklusive SBOM:en, måste sparas i 10 år efter att den sista enheten placerades på marknaden, eller under den förväntade användningstiden om den är längre (CRA Artikel 23). SBOM:en måste hållas aktuell under hela den aktiva supportperioden, som CRA sätter till minst 5 år.

Nästa steg

Hanterar du CRA-efterlevnad för flera produkter? CRA Evidence spårar dina SBOM:er, bedömer dem mot BSI TR-03183:s kvalitetsnivåer och flaggar nya sårbarheter när de dyker upp.

När du har valt ett format kan du läsa guiden för SBOM-generering för att automatisera skapandet i CI/CD. Se guiden för teknisk fil bilaga VII för att förstå var din SBOM passar in i den övergripande efterlevnadsdokumentationen.


Den här artikeln är endast informativ och utgör inte juridisk rådgivning. Kontakta kvalificerad juridisk rådgivare för specifik efterlevnadsvägledning.

CRA SBOM
Share

Gäller CRA för din produkt?

Svara på 6 enkla frågor för att ta reda på om din produkt omfattas av EU:s Cyber Resilience Act. Få ditt resultat på under 2 minuter.

Redo att uppnå CRA-efterlevnad?

Börja hantera dina SBOM:ar och efterlevnadsdokumentation med CRA Evidence.