SBOM
Vad är en SBOM?
En SBOM, software bill of materials, är en maskinläsbar lista över komponenterna i en programvara: varje bibliotek, paket och beroende, med version, producent och licens. Den är för programvara vad innehållsförteckningen är för livsmedel. När en ny sårbarhet publiceras visar en SBOM på några minuter om du levererar den berörda komponenten.
Uppdaterad
Vad står SBOM för?
SBOM står för software bill of materials, på svenska ungefär programvaruförteckning. Begreppet kommer från tillverkningsindustrin, där en bill of materials listar delarna som ingår i en produkt. CISA beskriver en SBOM som en nästlad förteckning, en lista över ingredienserna som utgör programvarukomponenter.
Det mesta av koden i en modern applikation har skrivits av någon annan, och det mesta av den kommer in indirekt: du lägger till ett paket, och det drar med sig dussintals transitiva beroenden. En SBOM skriver ner allt detta, så att du kan svara på "är vi drabbade?" utan att läsa ett enda repo.
Vad innehåller en SBOM?
En användbar SBOM har två delar: data om själva SBOM:en och data om varje komponent. 2026 Minimum Elements, som CISA, NSA och FBI publicerade tillsammans med internationella partner den 29 juli 2026, ersätter NTIA:s lista från 2021 och är den grundnivå som de flesta köpare nu hänvisar till.
| Del | Fält |
|---|---|
| Om SBOM:en | Författare och författarsignatur, tidsstämpel, dataformatets namn och version, verktygets namn och version, SBOM-version och genereringskontexten |
| Om varje komponent | Namn, version, producent, identifierare som en package URL, hashvärde och algoritm, licens och beroenderelationer |
Genereringskontexten betyder mer än man kan tro. Den anger när SBOM:en togs fram: före bygget, under bygget, från den färdiga artefakten eller efter den. Två SBOM:er av samma release kan skilja sig åt av just det skälet. Se SBOM-exempel för hur fälten ser ut i en riktig fil.
SBOM-format
Två format täcker nästan alla SBOM:er som används. CycloneDX, från OWASP, började inom säkerhet och beskriver även sårbarheter och tjänster. SPDX, från Linux Foundation, började inom licensefterlevnad. Båda kan bära minimielementen, och de flesta verktyg skriver båda. Se CycloneDX vs SPDX för hur du väljer.
Varför SBOM:er är viktiga
- Snabbare incidenthantering. När en sårbarhet som Log4Shell slår till är frågan vilka av dina produkter som innehåller den. Med SBOM:er är det en sökning. Utan dem är det ett projekt.
- Sårbarhetsbevakning efter release. Programvara som var ren när den levererades kan vara sårbar i morgon. Om du kontrollerar sparade SBOM:er mot nya säkerhetsmeddelanden upptäcker du det utan att bygga om något.
- Licensrisk. Varje komponents deklarerade licens visar copyleft-villkor eller kommersiella villkor innan de når produkten.
- Frågor från kunder och tillsynsmyndigheter. Köpare frågar allt oftare efter en SBOM vid upphandling, och flera ramverk förväntar sig en komponentförteckning.
Vem behöver en SBOM?
Alla som levererar programvara, och alla som måste stå till svars för vad den innehåller. Kravet kommer oftast genom något av följande:
- Medicintekniska produkter. FDA section 524B kräver en SBOM för cyberenheter i ansökningar inför marknadsgodkännande.
- Produkter som säljs i EU. Cyber Resilience Act begär en SBOM av tillverkare. Se SBOM-krav och verktyg enligt CRA.
- Federal upphandling i USA. OMB-memot M-26-05 från januari 2026 låter varje myndighet själv avgöra om en ska krävas, så räkna med att det avgörs från fall till fall.
- Betalprogramvara. PCI DSS 4.0 krav 6.3.2 begär en förteckning över specialutvecklad programvara och dess tredjepartskomponenter. Kravet föreskriver ingen SBOM, men en SBOM uppfyller behovet.
Så genererar du en SBOM
Det finns tre sätt att ta fram en, och metoden avgör vad som hamnar i filen.
| Metod | Vad den läser | Typisk lucka |
|---|---|---|
| Skanna källan | Manifest och lockfiler i repot | Allt som bygget hämtar men som ingen lockfile listar |
| Skanna resultatet | En färdig containeravbild eller binär | Kompilerad kod är tvetydig, och byggverktyg lämnar inga spår |
| Registrera bygget | Vad bygget faktiskt hämtade medan det kördes | Trafik som går förbi registreringen, vilket bör flaggas |
Generatorer med öppen källkod som Syft, Trivy och cdxgen använder de två första metoderna. De är oense med varandra om samma commit, eftersom var och en har sina egna regler för vad som ska läsas. För alternativen sida vid sida, se de bästa SBOM-verktygen.
SBOM vs SCA vs VEX
- En SBOM är en förteckning. Den säger vad som finns där, inte om det är säkert.
- Software composition analysis är analysen. Den hittar komponenter och kontrollerar dem för risker, och många SCA-verktyg tar fram en SBOM på vägen.
- VEX är ett uttalande om påverkan. Det säger om en känd sårbarhet faktiskt påverkar din produkt, vilket minskar bruset som en SBOM ensam skapar.
Att generera en SBOM är den enkla delen
En fil som ingen läser förändrar ingenting. Värdet kommer av att ha en SBOM per release, bevaka dem och kunna hitta dem när det gäller. Det arbetet är SBOM-hantering, och bästa praxis för SBOM visar hur du bedriver det.
Så skapar CRACI SBOM:er
CRACI är en GitHub Actions-runner som registrerar varje paket som varje jobb hämtar, i alla led av beroendeträdet och inklusive paket som återställs från CI-cachar. Resultatet är en SBOM av bygget som producerade releasen, med en fullständighetsstatus som anger vad jobbet inte kunde se. Den exporteras som CycloneDX eller SPDX, och CRACI fortsätter att omvärdera den när nya sårbarheter publiceras. Se SBOM-generering under bygget.
SBOM: vanliga frågor
Vad är en SBOM enkelt förklarat?
En SBOM är en innehållsförteckning för programvara. Den namnger varje komponent i en produkt, med version, producent och licens, i ett format som maskiner kan läsa.
Vad står SBOM för?
SBOM står för software bill of materials.
Varför behöver du en SBOM?
För att snabbt kunna se om en nypublicerad sårbarhet påverkar det du levererar, se licensrisker före release och svara kunder och tillsynsmyndigheter som frågar vad din produkt innehåller.
Vilka är de två viktigaste SBOM-formaten?
CycloneDX och SPDX. CycloneDX kommer från OWASP och började inom säkerhet. SPDX kommer från Linux Foundation och började inom licensefterlevnad. Båda kan bära minimielementen.
Krävs en SBOM enligt lag?
Det beror på produkten och marknaden. FDA section 524B kräver en för cyberenheter, och EU:s Cyber Resilience Act begär en av tillverkare. Vid federal upphandling i USA är det nu varje myndighets eget beslut. För många andra företag är det ett krav från kunder snarare än ett lagkrav.
Hur ofta bör en SBOM uppdateras?
Generera en ny SBOM för varje release, eftersom varje bygge kan dra in andra versioner. En releases SBOM ändras inte i efterhand, men du bör fortsätta att kontrollera den mot nya sårbarheter.
Vem skapar SBOM:en?
Oftast teamet som bygger programvaran, helst i CI så att varje release automatiskt får en. Programvara du köper bör komma med en SBOM från leverantören.
Se SBOM:en för ditt riktiga bygge
Kör ett GitHub Actions-arbetsflöde på CRACI och jämför dess registrerade SBOM med vad dina nuvarande verktyg rapporterar.
Boka en demo