Vad är SBOM? Krav enligt CRA och NIS2

När Log4Shell slog ner i december 2021 gick CERT-SE ut med bulletinen BM21-004 och varnade att "attackförsök pågår redan mot svenska aktörer". MSB följde upp med en extra varning riktad direkt till ledningsgrupper. Då ställdes en enkel fråga i varje svensk säkerhetsorganisation: vilka av våra system kör Log4j? Organisationer med en SBOM kunde svara inom timmar. De utan en SBOM ägnade veckor åt manuella granskningar och mejl till leverantörer.

Med EU:s Cyber Resilience Act (CRA) blir SBOM ett lagkrav för tillverkare av digitala produkter från 11 december 2027. NIS2 nämner inte SBOM direkt. Men kraven på leverantörskedjans säkerhet förutsätter i praktiken att ni kan inventera komponenter.

Den här guiden förklarar vad en SBOM är, vilka format som finns och vad CRA och NIS2 kräver. Du får också konkreta tips på vad ni bör göra nu.

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 vet ni direkt vilka av era system som påverkas.

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. Det är ingen PDF eller Excel-fil. Det är strukturerad data (JSON eller XML) som går att importera till säkerhetsverktyg och söka i automatiskt.

De tre formaten: CycloneDX, SPDX och SWID

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

Vinnaren? Ingen enskild. De flesta moderna verktyg, som Syft, Trivy och GitHub, kan skapa både CycloneDX och SPDX. Den praktiska rekommendationen är att kräva CycloneDX eller SPDX i avtalet och låta leverantören välja. SWID kan ni i de flesta fall ignorera.

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 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. SBOM behöver i praktiken finnas på plats vid det datumet, eftersom sårbarhetshantering förutsätter komponentinventering.
• 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. De kraven förutsätter i praktiken att ni kan inventera komponenter.

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:

Flödet blir så här: CRA tvingar er leverantör att skapa en SBOM. NIS2 ger er på köparsidan rätten och skyldigheten att begära och använda den. Fram till december 2027 är SBOM-utlämning från leverantörer en avtalsfråga, inte en lagstadgad rättighet.

Tre attacker där SBOM hade gjort skillnad

Teorin är abstrakt. Här är tre verkliga incidenter som visar varför SBOM är värdefullt – och var dess gränser går.

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.

Organisationer utan SBOM fick ringa varje leverantör och vänta på svar. Många upptäckte sin exponering först efter att attackerna redan var i full gång. Organisationer med SBOM kunde söka i sin inventering. De fick en lista över alla påverkade system inom minuter.

Tietoevry (januari 2024)

Akira-ransomware slog ut Tietoevrys svenska datacenter och påverkade Filmstaden, Rusta, Systembolaget, Statens Servicecenter och 120 svenska myndigheter via lönesystemet Primula. Tiotusentals anställda kunde inte få lön i tid. Tapporna gick upp i miljoner.

Det här är inte ett komponentexempel som Log4Shell, utan en klassisk leverantörsincident. Men poängen är densamma: när Tietoevry föll ringde varje IT-chef i Sverige sina leverantörer och frågade "använder ni Tietoevry någonstans?". De som hade en kartlagd leverantörskedja, inklusive fjärdepartsberoenden, kunde svara snabbt. Andra fick veta veckor senare att en kritisk underleverantör hade varit ner.

SBOM löser inte hela det här problemet. Men det är samma princip: kartlägg vad ni har, både komponenter och leverantörer, så att ni kan agera direkt när nästa incident dyker upp.

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 ligger i en mejlbilaga är värdelös. 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. Drukna inte i data. 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 om SBOM

Är SBOM lagstadgat i EU?

Ja, indirekt. CRA (förordning 2024/2847) kräver att tillverkare av produkter med digitala element upprättar en SBOM i maskinläsbart format senast 11 december 2027.

NIS2 nämner inte SBOM uttryckligen, men kravet på leverantörskedjans säkerhet i artikel 21 gör SBOM till en praktisk implementationskomponent på köparsidan.

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

CRA kräver ett "vanligt förekommande och maskinläsbart format" men namnger inget specifikt. CycloneDX (OWASP) dominerar i säkerhetsteam och DevSecOps-pipelines, medan SPDX (ISO/IEC 5962:2021) dominerar i upphandling och open source-compliance.

De flesta verktyg genererar båda. Vår rekommendation: kräv CycloneDX eller SPDX i avtalet – låt leverantören välja.

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 ingestera och övervaka SBOM:er över tid.

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

CRA reglerar tillverkare av digitala produkter och kräver att SBOM finns i den tekniska dokumentationen. NIS2 reglerar väsentliga och viktiga entiteter (köparsidan) och kräver att ni hanterar risker i leverantörskedjan.

Tillsammans skapar de en flödeskedja: CRA tvingar leverantörer att generera SBOM, NIS2 ger er rätten och skyldigheten att begära och använda den.

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