Vad är SBOM? Krav enligt CRA och NIS2

Vad är en SBOM?

SBOM står för Software Bill of Materials – på svenska programvarustycklista. Det är en maskinläsbar lista över alla mjukvarukomponenter i en applikation. Den visar namn, version, leverantör, unik identifierare och hur komponenterna hänger ihop.

Den närmaste liknelsen är stycklistan i tillverkningsindustrin. När en biltillverkare ska återkalla en defekt bromskomponent vet de exakt vilka modeller som har den. Det är tack vare stycklistan. En SBOM fungerar likadant för mjukvara. När en sårbarhet upptäcks i ett bibliotek kan ni söka efter berörda versioner. Bekräfta sedan om sårbarheten faktiskt kan utnyttjas i er miljö.

En SBOM innehåller oftast:

• Komponentnamn och version – till exempel log4j-core 2.14.1
• Leverantör och författare – vem som har tillverkat komponenten
• Unik identifierare – ofta en PURL (Package URL) eller CPE
• Beroenden – komponent A bygger på B, som bygger på C
• Tidsstämpel – när SBOM:en skapades
• Licens – viktigt för open source-efterlevnad

Det viktiga är att SBOM:en är maskinläsbar. En PDF-lista räcker inte för automatiserad analys. Använd ett strukturerat format som era verktyg kan läsa, exempelvis CycloneDX eller SPDX.

De tre formaten: CycloneDX, SPDX och SWID

Det finns tre etablerade SBOM-format. Du behöver känna till två av dem.

Välj ett format som mottagaren och analysverktygen stöder. Kom överens om format, version och vilka fält som ska ingå innan leveransen. Kontrollera exportstödet i det verktyg ni använder; alla verktyg erbjuder inte båda formaten.

Vad CRA kräver: lagstadgad SBOM från 2027

CRA (Cyber Resilience Act) är EU:s förordning för cybersäkerhet i digitala produkter. Den trädde i kraft 10 december 2024. Kraven börjar gälla stegvis fram till 11 december 2027.

I CRA:s bilaga I, del II, punkt 1 står det att tillverkare ska identifiera och dokumentera sårbarheter och komponenter i produkter med digitala element. Det ska bland annat ske genom en programvarustycklista i ett vanligt förekommande och maskinläsbart format. Den ska minst täcka produktens direkta beroenden.

I praktiken betyder det:

Notera att CRA bara kräver direkta beroenden. Det är en miniminivå. Många praktiker, bland annat tyska BSI i deras TR-03183-2-vägledning, rekommenderar att gå djupare och inkludera även indirekta beroenden. Det är där sårbarheter som Log4j ofta gömmer sig.

Tidslinje för CRA och SBOM

• 10 december 2024 – CRA träder i kraft
• 11 september 2026 – Rapporteringskrav för aktivt utnyttjade sårbarheter börjar gälla. Det är inte startdatumet för det uttryckliga SBOM-kravet. En komponentinventering kan ändå stödja rapporteringen.
• 11 december 2027 – Full tillämpning. CE-märkning kräver CRA-efterlevnad inklusive SBOM.

Sanktioner

Bristande efterlevnad av bilaga I (där SBOM-kravet finns) kan kosta upp till 15 miljoner euro eller 2,5 procent av global årsomsättning. Det högsta beloppet gäller. Produkter utan korrekt SBOM kan dessutom vägras CE-märkning. Det blockerar dem från EU-marknaden.

Vad NIS2 kräver: leverantörskedjans säkerhet

NIS2 nämner inte SBOM uttryckligen. Däremot ställer artikel 21 krav på leverantörskedjans säkerhet. En komponentinventering kan vara ett sätt att stödja arbetet, beroende på vilka produkter och risker det gäller.

Artikel 21.2 d kräver säkerhet i leveranskedjan. Det inkluderar säkerhetsrelaterade aspekter av relationen mellan varje entitet och dess direkta leverantörer eller tjänsteleverantörer.

Artikel 21.3 lägger till att entiteter ska beakta sårbarheter som är specifika för varje direkt leverantör. Ni ska också väga in den övergripande kvaliteten på produkter och cybersäkerhetspraxis hos era leverantörer. Det omfattar deras säkra utvecklingsförfaranden.

I svensk lag är detta implementerat genom cybersäkerhetslagen (2025:1506), som trädde i kraft 15 januari 2026. Lagen lägger inte till något SBOM-specifikt utöver NIS2.

För digital infrastruktur, MSP:er och molntjänster har EU dessutom antagit kommissionens genomförandeförordning (EU) 2024/2690. Den binder hårdare på avtalsnivå. Bland annat kräver den att kontrakt ska specificera cybersäkerhetskrav för leverantörer.

Hur kraven hänger ihop

Det är lätt att blanda ihop CRA och NIS2. Här är skillnaden:

CRA kräver att omfattade tillverkare upprättar en SBOM. Det ger inte varje kund en allmän rätt att få ut den, och NIS2 föreskriver inte att varje köpare ska begära SBOM. Avtala om leverans, uppdatering och sekretess även efter december 2027.

Exempel och begränsningar med SBOM

Komponentinventering hjälper er att undersöka sårbarheter. Den ersätter inte detektion av skadlig kod eller kartläggning av driftberoenden.

Log4Shell (december 2021)

Den klassiska SBOM-affischen. Log4j fanns djupt inbäddad i tusentals applikationer som indirekt beroende. Ofta låg det flera nivåer ner i beroendekedjan. När CVE-2021-44228 publicerades startade en frenetisk jakt världen över.

En aktuell SBOM kan hjälpa er att hitta berörda Log4j-versioner. Om biblioteket saknas i inventeringen eller produktversionen är oklar behövs ytterligare undersökning. En matchning behöver också följas av leverantörens bedömning av exponering och tillgängliga rättningar.

Leverantörsberoenden kräver ett separat register

En SBOM beskriver programvarukomponenter, inte hela leverantörskedjan. Den visar inte automatiskt vilka datacenter, driftpartners eller underleverantörer som en tjänst är beroende av. Kombinera därför komponentinventeringen med kartlagda leverantörsrisker och uppgifter om kritiska underleverantörer.

XZ Utils-bakdörren (mars 2024)

En bakdörr i liblzma, ett bibliotek i xz-utils-paketet, upptäcktes precis innan den nådde stabila Linux-distributioner. En SBOM hade visat att biblioteket fanns där. Men bakdörren själv hade inte upptäckts av komponentinventering. Det var en avsiktligt skadlig version (5.6.0 och 5.6.1) som en bidragsgivare planterade in efter lång tids social ingenjörskonst.

Lärdomen är att SBOM är inventering, inte detektion. När CVE-2024-3094 publicerades kunde organisationer med SBOM snabbt identifiera påverkade system. Men SBOM hade inte upptäckt själva attacken.

Hur SBOM skapas i praktiken

För era utvecklingsteam är själva genereringen oftast en småsak. Det svåra ligger på andra sidan.

Verktyg som skapar SBOM

Open source:

• Syft (Anchore) – skannar containerimages, filsystem och paket
• Trivy (Aqua) – SBOM och sårbarhetsskanning i samma verktyg
• GitHub Dependency Graph – inbyggt i GitHub-repos

Kommersiella:

• Snyk
• Black Duck
• Mend (tidigare WhiteSource)
• Sonatype Lifecycle

Moderna CI/CD-pipelines i GitHub Actions, GitLab och Azure DevOps kan skapa en SBOM som byggartefakt vid varje release. Det är ungefär som en byggrapport. Det är också den naturliga platsen att lägga SBOM-genereringen.

Det svåra är inte att skapa – det är att använda

En SBOM som bara sparas i en mejlbilaga är svår att använda när ni behöver söka över flera produkter. Det ni behöver är en process för att:

1. Ta emot SBOM från egna byggen och från leverantörer
2. Lagra och indexera dem så att de blir sökbara
3. Matcha komponenter mot sårbarhetsdata (NVD, OSV, GHSA)
4. Larma när en relevant CVE släpps
5. Skapa nya SBOM vid varje release. En statisk SBOM blir snabbt fel.

OWASP Dependency-Track är gratis och referensverktyget för detta. Det importerar CycloneDX-filer, indexerar komponenter och matchar dem löpande mot sårbarhetskällor. Kommersiella alternativ är Snyk, Sonatype Lifecycle och Anchore Enterprise.

Vad ni bör göra nu

Oavsett om ni utvecklar mjukvara, köper in den eller gör båda så ser den praktiska handlingsplanen ut så här.

Om ni köper in mjukvara

För upphandlare och säkerhetsansvariga är SBOM ett verktyg för att stärka leverantörshanteringen.

Skriv in SBOM-krav i avtalen. En svag formulering är "Leverantören tillhandahåller SBOM på begäran". En stark formulering är:

Prioritera era system. Börja med en omfattning ni kan följa upp. Börja med era 5–10 mest kritiska system. Det kan vara kundvändande tjänster, system som lagrar personuppgifter eller betalningsflöden. Bredda sedan när processen sitter. Det här knyter an till hur ni klassar leverantörer efter kritikalitet.

Ha en process för CVE-händelser. När nästa Log4Shell publiceras: vem söker i SBOM-databasen? Vilken SLA gäller? Hur kommunicerar ni med leverantörer? Det här hör hemma i er incidenthanteringsprocess.

Om ni utvecklar och säljer mjukvara

För CRA-omfattade tillverkare är SBOM en del av den tekniska dokumentationen från december 2027. Men ni bör börja nu.

Lägg SBOM-genereringen i bygget. Lägg till Syft eller Trivy i CI/CD och låt varje release skapa en SBOM som byggartefakt. Det är oftast en konfigurationsfråga, inte ett projekt.

Välj ett format och håll er konsekventa. Välj CycloneDX om ni har säkerhetsfokus. Välj SPDX om ni har upphandlings- och licensfokus. Många team skapar båda.

Bygg en leveranskanal. Era kunder kommer att kräva SBOM. Bestäm hur ni levererar – API, kundportal eller säker filöverföring – innan första kunden frågar.

Koppla till sårbarhetshantering. SBOM är grunden för sårbarhetsskanning. När en CVE släpps ska ni snabbt kunna svara era kunder om de är påverkade.

Tre vanliga missuppfattningar

"SBOM = säkerhet." Nej. En SBOM är en inventering. Den måste matchas mot sårbarhetsdata och leda till patchning. Utan en process är en SBOM bara en lista.

"SBOM ger bort vår IP." Sällan ett verkligt problem. En SBOM innehåller komponentnamn och versioner, inte källkod. Det leverantörer oftast vill skydda är affärslogiken, och den finns inte i en SBOM.

"SBOM är bara för mjukvaruleverantörer." Fel. Varje företag använder mjukvara. Den största nyttan av SBOM ligger ofta hos köparen, som vill veta vad som finns i de produkter man köper in.

Kom igång

En SBOM är inte en regulatorisk pappersövning. Det är ett operativt verktyg som drastiskt kortar tiden från att en sårbarhet publiceras till att ni vet om ni är drabbade. Att vänta till december 2027 är att vänta för länge.

Börja med tre steg:

1. Kartlägg era kritiska leverantörer.
2. Skriv in SBOM-krav i nya avtal.
3. Välj ett verktyg för att lagra och söka i de SBOM:er ni får in.

För egna produkter: lägg SBOM-genereringen i CI/CD-pipelinen nu.

ChainSec hjälper er att hantera leverantörsrisker systematiskt. Det gäller hela vägen från leverantörsbedömning till uppföljning av säkerhetskrav enligt CRA och NIS2. Boka en demo för att se hur det fungerar.

Vanliga frågor

Är SBOM lagstadgat i EU?

Ja. CRA har ett uttryckligt krav på en maskinläsbar SBOM för tillverkare av produkter med digitala element som omfattas, med tillämpning från 11 december 2027. NIS2 nämner inte SBOM uttryckligen; den kan stödja hanteringen av leverantörsrisker.

Vilket format ska vi använda – CycloneDX eller SPDX?

CRA namnger inget specifikt format i SBOM-kravet. CycloneDX och SPDX är etablerade alternativ. Välj ett format och en version som era verktyg kan importera, och avtala om obligatoriska fält och uppdateringar.

Räcker det att kräva SBOM från våra leverantörer?

Nej. En SBOM utan process är bara en lista. Ni behöver ett sätt att lagra, söka och matcha SBOM mot sårbarhetsdata (NVD, OSV) när nästa Log4Shell dyker upp. Verktyg som OWASP Dependency-Track eller kommersiella plattformar som Snyk och Sonatype hjälper er importera och övervaka SBOM:er över tid.

Vad är skillnaden mellan CRA och NIS2 när det gäller SBOM?

CRA kräver att omfattade tillverkare upprättar SBOM. NIS2 kräver att omfattade verksamheter hanterar säkerhetsrisker i leverantörskedjan, men ger inte en generell rätt eller skyldighet att få SBOM från varje leverantör. Reglera kundens tillgång till SBOM i avtalet.

Läs mer om CRA och NIS2-säkerhetsåtgärder för bredare kontext.