Vad är en SBOM och varför behöver organisationer det?

En SBOM (Software Bill of Materials) är en maskinläsbar förteckning över alla komponenter, bibliotek och beroenden som en mjukvara består av, som en innehållsförteckning för programvara.

Tänk på den som ingredienserna i ett recept. En kaka är inte bara “kaka”, den är ägg, smör, mjöl och socker i bestämda mängder. På samma sätt är en applikation inte en enda sak, utan hundratals öppna och inköpta komponenter, ofta i versioner ni aldrig själva valt. En SBOM listar dem alla, med exakt version och licens, så att ni vet vad som faktiskt körs.

Varför det spelar roll

De flesta moderna system består till största delen av kod som någon annan skrev. En applikation kan ha tiotals direkta beroenden och hundratals indirekta, bibliotek som era bibliotek i sin tur drar in. Utan en SBOM är allt det en svart låda. Ni vet vad ni beställde, men inte vad som hamnade i bygget.

Den svarta lådan blir farlig den dag en sårbarhet upptäcks. När Log4Shell briserade i december 2021 satt tusentals organisationer med samma fråga: kör vi det sårbara Log4j-biblioteket någonstans, och i så fall var? De som hade en SBOM kunde svara på minuter. De som inte hade det letade i veckor. Skillnaden var inte hur skickliga utvecklarna var, utan om de visste vad de hade.

Sedan dess har frågan flyttat från god praxis till lagkrav. EU:s Cyber Resilience Act (CRA) ställer krav på att tillverkare av produkter med digitala element upprättar en SBOM. Från 11 september 2026 gäller dessutom rapporteringsskyldigheter: aktivt utnyttjade sårbarheter ska anmälas inom 24 timmar och fullständigt inom 72 timmar (källa: Cyber Resilience Act, Europeiska kommissionen). Poängen som gör allt konkret: ni kan inte rapportera en sårbar komponent ni inte vet att ni har.

Hur det fungerar

En SBOM är en strukturerad fil, vanligen i formatet CycloneDX eller SPDX, som ett verktyg genererar automatiskt ur byggprocessen. Den listar varje komponent med namn, version, en unik identifierare och licens. En enskild post för npm-biblioteket tough-cookie kan se ut så här:

{
  "bom-ref": "pkg:npm/[email protected]",
  "type": "library",
  "name": "tough-cookie",
  "version": "2.5.0",
  "purl": "pkg:npm/[email protected]",
  "licenses": [{ "license": { "id": "BSD-3-Clause" } }]
}

Tre fält bär informationen. purl (package URL) är den unika adressen som gör att ett verktyg entydigt kan slå upp komponenten mot en sårbarhetsdatabas. version avgör allt, [email protected] har kända sårbarheter som senare versioner åtgärdat. Och licenses avslöjar den andra risken: en komponent kan vara säker men ha en licens ni inte får använda i sammanhanget. Licensinformationen är minst lika viktig som säkerheten.

Men en SBOM ensam svarar bara på frågan vad finns?. Den säger inte om en känd sårbarhet faktiskt drabbar er. Det är därför VEX (Vulnerability Exploitability eXchange) blivit följeslagaren till SBOM. Där SBOM listar komponenten, säger VEX om sårbarheten i den är relevant, med statusen not_affected, affected, fixed eller under_investigation. En sårbar funktion som aldrig anropas i er produkt kan markeras not_affected, så att larmet inte stjäl tid från en verklig risk.

Hela kedjan automatiseras. Ett genereringssteg producerar en SBOM vid bygget, vanligen i CycloneDX- eller SPDX-format. En sårbarhetsbevakare matchar varje purl mot kända CVE:er löpande. När en ny sårbarhet publiceras vet ni samma dag om den rör er, utan att leta manuellt.

Två format dominerar, och de är byggda för olika syften. Skillnaden mellan CycloneDX och SPDX är att det förra är säkerhetsfokuserat och det senare licens- och compliancefokuserat. Båda går att generera ur samma verktyg, så valet låser inte in er.

	CycloneDX	SPDX
Aktuell version	1.7 (21 oktober 2025)	3.0.1 (december 2024)
Bakom	OWASP, även ECMA-424	Linux Foundation, ISO/IEC 5962
Styrka	Säkerhet, kompakt modell	Licens- och upphovsrättsspårning
Inbyggt VEX	Ja	Stöds från 3.0
Vanligast i	Cybersäkerhet, CRA-arbete	Stora open source-projekt

(Källor: cyclonedx.org/specification/overview, hämtad 2026-06; SPDX-specifikationen 3.0.1, spdx.github.io/spdx-spec/v3.0.1, hämtad 2026-06.) CRA kräver “ett vanligt förekommande, maskinläsbart format” men pekar ännu inte ut en specifik standard. CEN, CENELEC och ETSI accepterade i april 2025 kommissionens standardiseringsbegäran M/606 om 41 harmoniserade standarder för CRA; de horisontella standarderna har leveransdatum 30 augusti 2026 och de vertikala 30 oktober 2026 (källa: CEN-CENELEC, cencenelec.eu, hämtad 2026-06). Tills de finns är CycloneDX förstahandsvalet när drivkraften är säkerhet och CRA-rapportering.

Måttet på en SBOM är hur djupt den når. En SBOM som bara listar era direkta beroenden missar det mesta. De flesta riskerna bor nämligen i de transitiva beroendena, biblioteken som era bibliotek i sin tur drar in. CISA publicerade i augusti 2025 ett uppdaterat utkast till minimielement för en SBOM (källa: CISA, “2025 Minimum Elements for a Software Bill of Materials”, publicerad 22 augusti 2025, cisa.gov, hämtad 2026-06). De förtydligade bland annat krav på licens, komponent-hash och hur djupt beroendekedjan ska redovisas. En grund SBOM är bättre än ingen. Men det är djupet som avgör om den hjälper den dag en sårbarhet dyker upp långt nere i kedjan.

När det passar

En SBOM hör hemma överallt där mjukvara byggs, köps in eller förvaltas över tid. Den ger mest värde i tre lägen.

• Vid utveckling och förvaltning. Genererad vid varje bygge blir SBOM:en en levande inventering. När en zero-day dyker upp har ni svaret direkt, inte efter en veckas inventering.
• I upphandling. En beställare som kräver SBOM i avtalet köper inte längre en svart låda. Ni kan granska vad leverantören faktiskt levererar och be dem förklara varför de kör en opatchad komponent från flera år tillbaka.
• Vid leverantörsgranskning. Med Cybersäkerhetslagen (SFS 2025:1506) i kraft sedan 15 januari 2026 ställs krav på hela leverantörskedjan. SBOM är det konkreta verktyget för att granska vad era leverantörer bygger på.

I Sverige binder detta ihop upphandling och säkerhet. En kommun eller myndighet som kräver SBOM får ett granskbart underlag i stället för leverantörens ord. Upphandlingsmyndigheten publicerade 2026 vägledning om hur cybersäkerhetslagen (NIS2) påverkar offentlig upphandling (källa: Upphandlingsmyndigheten, “Cybersäkerhetslagens (NIS2) påverkan på offentlig upphandling”, upphandlingsmyndigheten.se, hämtad 2026-06).

När det inte passar

En SBOM är inte ett mål i sig, och i fel form blir den en pappersprodukt. Det finns lägen där den ger lite tillbaka.

En statisk SBOM som genereras en gång och läggs i en mapp är nästan värdelös. Mjukvara förändras vid varje release. En SBOM som inte uppdateras speglar snart ett system som inte längre finns, och då ger den falsk trygghet snarare än kontroll. Värdet uppstår först när genereringen är automatisk och kopplad till sårbarhetsbevakning.

SBOM löser inte heller säkerheten på egen hand. Den talar om vad ni har, inte om det är säkert konfigurerat, korrekt patchat eller exponerat mot internet. En perfekt SBOM över ett dåligt driftat system gör det inte säkert. Den är ett underlag för beslut, inte beslutet självt.

Och utan VEX riskerar en SBOM att drunkna i brus. En stor applikation kan ha hundratals komponenter med formellt kända CVE:er, varav de flesta aldrig påverkar er. Listar ni allt utan att bedöma relevansen får ni en larmkö ingen orkar gå igenom. SBOM utan bedömningssteg blir då mer arbete, inte mindre risk.

Konkret exempel

En offentlig upphandling av ett verksamhetssystem är där SBOM:en blir mest påtaglig. Beställaren skriver in ett krav: leverantören ska leverera en maskinläsbar SBOM i CycloneDX-format vid varje större release, plus ett VEX-dokument som redovisar hur kända sårbarheter hanteras.

Det förändrar relationen. Tidigare fick beställaren en färdig produkt och ett löfte om att den var säker. Nu får beställaren en lista att granska. Dyker det upp ett bibliotek med en känd sårbarhet kan beställaren ställa den enkla frågan: varför kör ni denna version, och när byts den? Leverantören kan inte längre gömma sig i en svart låda. Mjukvara måste vårdas som något levande, uppdateras, inte lämnas, och SBOM gör det synligt om den inte vårdas.

Digitalist arbetar med SBOM och sårbarhetsbevakning som en del av säker utveckling och förvaltning, och hjälper offentliga beställare att formulera SBOM-krav i upphandlingar. Som generell kvalitetssignal mäter vi oss i resultat, inte i timmar: NPS 61.

Vanliga missförstånd

“SBOM handlar bara om säkerhet.” Den fångar lika mycket licensrisk. En komponent kan vara fri från sårbarheter men ha en licens som hindrar er från att använda den i ett kommersiellt eller offentligt sammanhang. SBOM:en gör båda riskerna synliga samtidigt, och för en upphandlare är licensfrågan ofta lika avgörande som säkerheten.

“En SBOM räcker för att vara CRA-redo.” Det stämmer inte fullt ut. En SBOM säger vad som finns, men CRA förutsätter också att ni kan bedöma och rapportera sårbarheter i tid. I praktiken behöver ni SBOM plus VEX plus löpande sårbarhetsbevakning. SBOM:en är förutsättningen, inte hela svaret.

“Vi genererar SBOM en gång, så är det klart.” En SBOM är en ögonblicksbild av ett bygge. Nästa release ändrar innehållet, och en ny sårbarhet kan publiceras vilken dag som helst. Värdet ligger i att SBOM:en uppdateras automatiskt och bevakas kontinuerligt, inte i att den finns.

Frågan en beställare till sist ska ställa är inte om leverantören har en SBOM, utan om den lever: genereras vid varje bygge, bevakas mot nya sårbarheter, och kan visas upp den dag någon frågar.