# Vanliga frågor om SBOM

Korta svar, med länkar till artiklar som går djupare

> Vad är en SBOM, är den ett lagkrav, vilket format ska man välja och hur ofta ska den uppdateras? Korta svar på vanliga frågor om SBOM.

Uppdaterad: 5 oktober 2026  
URL: https://sbom.se/sbom/faq

## Vad är en SBOM?

En SBOM (Software Bill of Materials) är en maskinläsbar förteckning över de komponenter som en mjukvara består av: bibliotek, ramverk och andra beroenden, med namn, version och leverantör. Läs mer i [Vad är SBOM?](https://sbom.se/sbom/what-is-sbom)

## Är SBOM ett lagkrav?

Ja, för tillverkare av produkter med digitala element som säljs i EU. Cyber Resilience Act (CRA) kräver en SBOM från den 11 december 2027. NIS2 och DORA nämner inte SBOM, men ställer krav på sårbarhetshantering och säkerhet i leveranskedjan. Läs mer i [SBOM-kraven i CRA](https://sbom.se/cra/sbom-requirements) och [Regelverk som kräver SBOM](https://sbom.se/regulations/overview).

## Måste en SBOM vara offentlig?

Nej. CRA kräver inte att tillverkare offentliggör sin SBOM. Den ingår i den tekniska dokumentationen och kan begäras ut av en marknadskontrollmyndighet. Kunder kan kräva en SBOM i avtal.

## Vad innehåller en SBOM?

Minst komponentens namn, version, leverantör, en unik identifierare och relationerna mellan komponenterna, samt vem som skapade SBOM:en och när. Ofta finns också licenser och kontrollsummor. Läs mer i [Vad finns i en SBOM?](https://sbom.se/sbom/sbom-contents) och [Vad är Minimum Elements?](https://sbom.se/sbom/minimum-elements)

## Innehåller en SBOM sårbarheter?

Normalt inte. En SBOM beskriver vad mjukvaran består av. Vilka sårbarheter som berör komponenterna ändras över tid och tas fram genom att SBOM:en jämförs mot sårbarhetsdatabaser. Bedömningen av om en sårbarhet faktiskt påverkar produkten delas i ett separat dokument, [VEX](https://sbom.se/vulnerabilities/what-is-vex).

## Vilket format ska jag välja, CycloneDX eller SPDX?

Båda är öppna standarder och båda accepteras i de flesta sammanhang. CycloneDX kommer från OWASP och togs fram för säkerhetsanalys. SPDX kommer från Linux Foundation, började som ett format för licensinformation och är en ISO-standard. Välj det format som era verktyg och kunder stöder. Läs mer i [SBOM-format och standarder](https://sbom.se/sbom/formats-and-standards).

## Hur skapar man en SBOM?

Med ett verktyg som läser källkod, byggresultat eller containeravbildningar, till exempel Syft, Trivy, cdxgen eller Observer CLI. SBOM:en bör skapas automatiskt i bygget. Läs mer i [Hur skapar man en SBOM?](https://sbom.se/guides/create-an-sbom)

## Hur ofta ska en SBOM uppdateras?

En SBOM beskriver en viss version av mjukvaran. Skapa en ny för varje release och spara de gamla så länge versionerna används. Sårbarhetsbevakningen ska däremot göras löpande, eftersom nya sårbarheter upptäcks i komponenter som redan är levererade.

## Vad är skillnaden mellan SBOM och SCA?

SCA (Software Composition Analysis) är en typ av verktyg som analyserar vilka komponenter med öppen källkod en mjukvara använder. En SBOM är ett dokument i ett standardiserat format som kan delas mellan organisationer. Många SCA-verktyg kan skapa SBOM:ar. Läs mer i [SBOM och SCA, vad är skillnaden?](https://sbom.se/sbom/sbom-and-sca)

## Hur får jag SBOM:ar från mina leverantörer?

Skriv in det i avtalet: format, hur ofta SBOM:en ska levereras och hur. Läs mer i [SBOM i offentlig upphandling](https://sbom.se/guides/public-procurement) och [SBOM i digitala leveranskedjor](https://sbom.se/guides/supply-chains).

## Vad gör man med alla SBOM:ar?

En enstaka SBOM går att granska för hand. När antalet växer behövs ett system som lagrar SBOM:erna per release, bevakar dem mot nya sårbarheter och visar vilka produkter som berörs av en viss komponent. [SBOM Observer](https://bytesafe.dev/observer) från Bytesafe, som driver den här sajten, är ett sådant verktyg. Dependency-Track är ett alternativ med öppen källkod.