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.
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:
- Firmware-versioner och komponenter
- Hardware Bill of Materials (HBOM) där tillämpligt
- Bootloader- och kernelkomponenter
Hur du kommer igång
-
Granska ditt nuläge: Genererar du SBOM:er i dag? Vilket format? Vilken täckning?
-
Välj ditt format: CycloneDX för säkerhetsfokus, SPDX för licensefterlevnad (eller båda)
-
Automatisera generering: Integrera SBOM-generering i din CI/CD-pipeline med verktyg som Syft, Trivy eller cdxgen
-
Validera kvalitet: Kontrollera dina SBOM:er mot TR-03183-krav. Är alla obligatoriska fält ifyllda?
-
Implementera övervakning: Koppla SBOM:er till sårbarhetsdatabaser (NVD, OSV, GitHub Advisory Database, CISA KEV)
-
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.
Relaterade artiklar
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.