# Olika typer av SBOM:ar

CISA:s sex SBOM-typer, från design till drift

> En SBOM kan skapas från en design, från källkod, i bygget, från en färdig artefakt eller från ett system i drift. CISA har definierat sex typer, och de ger olika svar på vad mjukvaran innehåller.

Uppdaterad: 5 oktober 2026  
URL: https://sbom.se/sbom/sbom-types

En SBOM beskriver en mjukvara vid en viss tidpunkt, och innehållet beror på när och hur den skapas. Den amerikanska myndigheten CISA har definierat **sex typer av SBOM**, som motsvarar olika skeden i mjukvarans livscykel.

De vanligaste är **Source SBOM** och **Build SBOM**.

| **SBOM-typ**      | **Beskrivning**                                                       | **Användningsområde**                                                                  |
| ----------------- | --------------------------------------------------------------------- | -------------------------------------------------------------------------------------- |
| **Design SBOM**   | Planerad arkitektur och avsedda komponenter.                          | Används i designfasen för att identifiera potentiella problem.                         |
| **Source SBOM**   | Byggs från källkoden och identifierar komponenter och beroenden.      | Möjliggör tidig identifiering av sårbarheter och kodanalys.                            |
| **Build SBOM**    | Genereras under byggprocessen och inkluderar alla faktiska beroenden. | Ger en verifierad och exakt representation av mjukvaran.                               |
| **Analyzed SBOM** | Skapas genom analys av en färdig artefakt, såsom en binär fil.        | Används när källkod eller byggmiljö saknas.                                            |
| **Deployed SBOM** | Dokumenterar installerade programvarukomponenter i en driftmiljö.     | Visar aktuell mjukvara i produktion och identifierar konfigurationsspecifika detaljer. |
| **Runtime SBOM**  | Övervakar ett körande system och identifierar aktiva komponenter.     | Möjliggör analys av dynamiskt laddade beroenden.                                       |

## Design SBOM

En Design SBOM beskriver den planerade arkitekturen och de komponenter som förväntas ingå i en produkt. Den baseras ofta på designspecifikationer eller offertförfrågningar (RFP) och används för att identifiera potentiella problem i ett tidigt skede.

**Fördelar:**

* Hjälper organisationer att planera sina projekt och identifiera eventuella kompatibilitetsproblem innan utvecklingen startar.
* Kan fungera som en riktlinje för vilka komponenter som är godkända att använda i utvecklingsprocessen.

**Begränsningar:**

* Innehåller endast teoretiska komponenter, vilket gör att faktiska beroenden som tillkommer senare kan saknas.
* Kan vara svår att generera på ett detaljerat sätt.

## Source SBOM

Skapas direkt från källkoden genom att analysera koden för att identifiera komponenter och beroenden. Genereras oftast med ett SCA-verktyg (Software Composition Analysis).

**Fördelar:**

* Möjliggör tidig identifiering av sårbarheter och beroenden i kodbasen.
* Ger en tydlig bild av vilka komponenter som används i en viss mjukvara.

**Begränsningar:**

* Kan inkludera beroenden som aldrig används i slutprodukten.
* Saknar insyn i komponenter som tillkommer senare i byggprocessen.

## Build SBOM

Genereras under byggprocessen och inkluderar alla beroenden som faktiskt används för att skapa den färdiga mjukvaran.

**Fördelar:**

* Ger en hög grad av noggrannhet eftersom den speglar den faktiska byggprocessen.
* Möjliggör signering av SBOM och produktartefakt, vilket ökar förtroendet.

**Begränsningar:**

* Kräver anpassningar i byggprocessen för att generera korrekt.
* Kan missa beroenden som laddas dynamiskt vid körning (se Runtime SBOM).

## Analyzed SBOM

Skapas genom analys av en färdigbyggd artefakt, som en binär fil, ett paket eller en container. Denna typ används ofta när man saknar tillgång till källkod eller byggmiljö.

**Fördelar:**

* Gör det möjligt att analysera äldre system eller programvara från tredje part.
* Kräver ingen insyn i byggprocessen och kan validera andra SBOM:ars data.

**Begränsningar:**

* Kan innehålla approximationer eftersom analysverktyg inte alltid identifierar alla komponenter korrekt.
* Beroende av heuristiska metoder som kan medföra felaktigheter.

## Deployed SBOM

Dokumenterar vilka programvarukomponenter som faktiskt är installerade på ett system och används i en produktionsmiljö.

**Fördelar:**

* Ger en tydlig bild av programvarukomponenterna i den faktiska driftsmiljön.
* Kan kombinera data från flera SBOM:er och identifiera konfigurationsspecifika detaljer.

**Begränsningar:**

* Kräver detaljerad information från driftmiljön, vilket kan vara svårt att samla in.
* Speglar endast den aktuella installationen och kan förändras över tid.

## Runtime SBOM

Genereras genom att övervaka ett körande system och identifiera de komponenter och beroenden som verkligen används vid drift.

**Fördelar:**

* Identifierar exakt vilka moduler och externa anrop som används i realtid.
* Möjliggör analys av dynamiskt laddade komponenter och externa anslutningar.

**Begränsningar:**

* Kräver aktiv övervakning av systemet, vilket kan innebära prestandapåverkan.
* Kan missa komponenter som endast används vid specifika körscenarier.

## Vilken typ ska man välja?

* **För mjukvara ni bygger själva:** en Build SBOM, eftersom den beskriver det som faktiskt levereras.
* **För mjukvara från tredje part eller äldre system:** en Analyzed SBOM, när leverantören inte lämnar någon och källkoden inte är tillgänglig.
* **För system i drift:** en Deployed eller Runtime SBOM som komplement, när det är viktigt att veta vad som faktiskt är installerat och körs.

Ange alltid vilken typ en SBOM är när den delas. Mottagaren behöver veta om den beskriver det som deklarerades i källkoden eller det som levererades. I CISA:s utkast till uppdaterade [Minimum Elements](https://sbom.se/sbom/minimum-elements) är det ett eget fält, Generation Context.