SBOM – från komponentlista till styrning av cyberrisk i leveranskedjan

Vet ni vad er mjukvara faktiskt innehåller – och kan ni snabbt avgöra om ni påverkas när en ny kritisk sårbarhet upptäcks?

Software Bill of Materials (SBOM) ger en strukturerad och maskinläsbar bild av vilka komponenter, bibliotek, versioner och beroenden som ingår i en mjukvaruprodukt. Men värdet ligger inte i själva listan. Värdet uppstår när informationen används för att förstå risk, prioritera åtgärder och skapa kontroll över mjukvarans leveranskedja.

När nästa kritiska sårbarhet upptäcks – är ni påverkade?

Log4Shell visade tydligt hur svårt det kan vara att snabbt avgöra vilka system som faktiskt innehåller en sårbar komponent. När en ny kritisk CVE publiceras behöver säkerhets- och IT-organisationen kunna svara på några grundläggande frågor: Använder vi komponenten? I vilka system? Vilka kunder och verksamhetsprocesser påverkas? Vem ansvarar för åtgärden?

Utan en aktuell komponentförteckning kan svaret kräva omfattande manuellt arbete:

• Vilka system använder biblioteket?
• Vilka versioner är installerade?
• Är komponenten direkt eller transitivt beroende?
• Vilka produkter, tjänster eller kunder berörs?

Med en aktuell SBOM kan analysen göras betydligt snabbare och i hög grad automatiseras. SBOM:en kan kopplas till sårbarhetsdatabaser och användas för att identifiera vilka system som innehåller en berörd komponent och vilka versioner som behöver hanteras.

Vad är en SBOM?

En SBOM är en strukturerad förteckning över de mjukvarukomponenter som ingår i en produkt eller applikation. Den kan bland annat innehålla komponentnamn, versioner, leverantör, licensinformation och relationer mellan komponenter.

Två av de vanligaste formaten är SPDX och CycloneDX. För att SBOM-informationen ska vara användbar över tid behöver den hållas aktuell. CISA rekommenderar att en ny SBOM skapas för varje ny release av en komponent och att förändringar i komponenterna återspeglas i SBOM:en.

SBOM är inte målet – det är rådata

Att generera en SBOM löser inte i sig ett säkerhetsproblem. Den verkliga nyttan uppstår när informationen kopplas till organisationens risk- och sårbarhetshantering.

En användbar SBOM kan exempelvis bidra till att:

• identifiera kända sårbarheter i komponenter och beroenden
• förstå vilka system och produkter som påverkas av en ny CVE
• prioritera patchning utifrån faktisk exponering och verksamhetskritikalitet
• följa upp leverantörer och tredjepartskomponenter
• stödja incidenthantering och analys av mjukvarans leveranskedja
• skapa bättre underlag för compliance, revision och riskrapportering

Mjukvarans leveranskedja är en del av attackytan

Modern programvara består i stor utsträckning av open source och andra tredjepartskomponenter. Det gör utvecklingen snabbare och mer effektiv, men innebär också att organisationer är beroende av kod och komponenter som de inte själva kontrollerar.

I takt med att dessa beroenden har ökat har mjukvarans leveranskedja blivit en allt viktigare del av attackytan. Incidenter som SolarWinds, Log4Shell och XZ Utils har visat hur sårbarheter eller komprometterade komponenter kan få konsekvenser långt utanför den ursprungliga leverantören.

SBOM ger inte ett fullständigt skydd mot supply-chain-attacker, men ger organisationen bättre förutsättningar att förstå vilka komponenter man är beroende av och att snabbare bedöma konsekvenserna när något händer.

Från compliance till konkret riskhantering

SBOM har också fått en tydligare roll i europeisk cybersäkerhetsreglering. Det är viktigt att skilja mellan regelverk som uttryckligen ställer krav på SBOM och regelverk där SBOM snarare är ett verktyg som kan stödja efterlevnaden.

Cyber Resilience Act (CRA)
EU:s Cyber Resilience Act innehåller ett uttryckligt krav på att tillverkare av berörda produkter med digitala element ska identifiera och dokumentera sårbarheter och komponenter, bland annat genom att upprätta en Software Bill of Materials i ett vanligt förekommande maskinläsbart format. SBOM:en ska åtminstone omfatta produktens direkta beroenden.

CRA börjar i huvudsak tillämpas den 11 december 2027. Vissa rapporteringskrav börjar gälla tidigare. För organisationer som utvecklar eller tillhandahåller produkter med digitala element innebär det att komponenttransparens och strukturerad sårbarhetshantering behöver byggas in i produktlivscykeln.

NIS2 och den svenska cybersäkerhetslagen
NIS2 ställer krav på lämpliga och proportionerliga riskhanteringsåtgärder inom bland annat supply-chain security, incidenthantering, kontinuitet samt säkerhet vid utveckling och underhåll av nätverks- och informationssystem, inklusive sårbarhetshantering.

Den svenska cybersäkerhetslagen (2025:1506), som delvis genomför NIS2, trädde i kraft den 15 januari 2026. NIS2 och cybersäkerhetslagen kräver inte en SBOM som sådan, men en aktuell SBOM kan vara ett viktigt verktyg för att stödja arbetet med flera av dessa krav.

Så kan SBOM bli en del av utvecklingsprocessen

SBOM ger störst värde när den inte hanteras som ett separat dokument, utan genereras och uppdateras automatiskt som en del av utvecklings- och releaseprocessen.

I mogna miljöer kan SBOM genereras vid varje build. Som baslinje bör den åtminstone uppdateras när en ny release skapas eller när produktens komponenter förändras.

Sex frågor en CISO bör kunna få svar på

En praktisk måttstock är inte om organisationen ‘har en SBOM’, utan om den snabbt kan använda informationen när en ny risk uppstår.

1. Använder vi den här komponenten?
2. Vilka system och produkter innehåller den?
3. Vilka kunder eller verksamhetsprocesser påverkas?
4. Vem levererade komponenten?
5. När kan den patchas eller på annat sätt hanteras?
6. Vem äger risken och beslutet?

Om svaren kräver manuella inventeringar i flera team finns sannolikt ett gap i organisationens komponenttransparens och supply-chain risk management.

Hur börjar man?

För de flesta organisationer är det bättre att börja avgränsat än att försöka kartlägga allt på en gång.

• Börja med ett affärskritiskt system, en produkt eller en tydligt avgränsad applikationsportfölj.
• Generera en SBOM automatiskt och säkerställ att den kan hållas aktuell över tid.
• Koppla komponentinformationen till sårbarhets- och riskhanteringen.
• Definiera ansvar: vem äger komponentdata, vem bedömer risk och vem fattar beslut om åtgärd?
• Ställ relevanta krav på leverantörer och säkerställ att SBOM-data går att använda i era egna processer.

Från komponentlista till beslutsunderlag

SBOM är i grunden en teknisk komponentförteckning. Men rätt använd kan den ge något betydligt mer värdefullt: förmågan att snabbare förstå exponering, prioritera åtgärder och fatta bättre beslut när mjukvarans leveranskedja förändras eller utsätts för nya hot.

Den centrala frågan är därför inte om ni kan generera en SBOM. Frågan är om ni kan använda den för att svara på: “Är vi påverkade – och vad behöver vi göra nu?”

Vill ni diskutera hur SBOM passar in i er miljö?

IP-Solutions kan hjälpa till med arkitektur, automatisering, säkerhet och arbetssätt kring mjukvarans leveranskedja – från nulägesanalys och rådgivning till implementation.

Kontakta oss för ett första samtal om komponenttransparens, supply-chain risk och SBOM.