SBOM enligt CRA: format, djup och arkivering i CI

En SBOM (Software Bill of Materials, på svenska programvaruförteckning) är en maskinläsbar lista över alla komponenter som ingår i din programvara. Med Cyber Resilience Act (CRA) blir den obligatorisk för produkter med digitala element som säljs i EU. Kravet står på en enda rad i förordningen, men den raden räcker för att väcka en hel del frågor i teamet: vilket format, hur djupt och hur länge ska vi spara?

Den här artikeln går igenom vad CRA kräver av en SBOM, hur du väljer format och djup, och hur du bygger in generering, signering och arkivering i CI så att förteckningen blir en biprodukt av varje bygge och inte ett kvartalsprojekt.

Har du frågor om ämnet? Tveka inte att höra av dig till oss!

Det här är en teknisk genomgång och inte juridisk rådgivning. Om du är osäker på om din produkt omfattas, ta hjälp av en jurist. De juridiska uppgifterna är kontrollerade den 19 oktober 2026.

Av Johan Kuylenstierna, VD Agency 42 · Senast granskad 19 oktober 2026

Vad säger CRA om SBOM?

CRA är förordning (EU) 2024/2847. Kravet på SBOM finns i bilaga I del II punkt 1. Tillverkare ska identifiera och dokumentera sårbarheter och komponenter i sina produkter, bland annat genom att upprätta en programvaruförteckning "i ett allmänt använt och maskinläsbart format som åtminstone täcker produktens viktigaste (top-level) beroenden".

Några saker är bra att veta från början:

• Kravet gäller från den 11 december 2027 (artikel 71), när huvuddelen av CRA börjar tillämpas.
• Rapporteringsplikten gäller redan, sedan den 11 september 2026 (artikel 14). Den är svår att klara utan SBOM, så i praktiken behöver du den nu. Vi har skrivit mer om det i CRA:s rapporteringsplikt: 24 timmar, 72 timmar, 14 dagar.
• Du behöver inte publicera SBOM:en. Skäl 77 säger uttryckligen att tillverkare inte ska vara skyldiga att offentliggöra den. Väljer du att dela den med användarna ska du ange var den finns (bilaga II punkt 9).
• Myndigheten kan begära den. SBOM:en ingår i den tekniska dokumentationen (bilaga VII punkt 2 b), och en marknadskontrollmyndighet kan efter en motiverad begäran få ta del av den (bilaga VII punkt 8).
• Den ska sparas länge. Den tekniska dokumentationen ska kunna visas upp i minst tio år efter att produkten släppts ut på marknaden, eller under stödperioden om den är längre (artikel 13.13).

Tänk på SBOM:en som innehållsförteckningen på en matförpackning. Ingen läser den varje dag, men den dag någon frågar "innehåller det här nötter?" vill du kunna svara direkt, för varje förpackning som finns ute i butikerna.

Format: CycloneDX eller SPDX?

CRA pekar inte ut något format. Kommissionen får specificera format och innehåll genom genomförandeakter (artikel 13.24), men den 19 oktober 2026 har ingen sådan akt antagits. Harmoniserade standarder för CRA tas fram inom CEN/CENELEC. Tills de finns är "allmänt använt och maskinläsbart" i praktiken ett av två format:

Det mest konkreta stödet i dag är den tyska myndigheten BSI:s tekniska riktlinje TR-03183-2 (version 2.1.0, augusti 2025). Den kräver CycloneDX 1.6 eller senare eller SPDX 3.0.1 eller senare, i JSON eller XML. Riktlinjen är inte bindande i Sverige, men den är den mest detaljerade myndighetstolkningen som finns och en rimlig miniminivå att sikta på.

Vårt råd: välj ett format som standard för hela organisationen och se till att verktygen kan konvertera vid behov. Det värsta är inte fel format, det är tre olika format i tre olika team.

Djup: räcker "top-level"?

Juridiskt är golvet produktens viktigaste (top-level) beroenden. Tekniskt räcker det sällan. Sårbarheter som Log4Shell satt ofta flera nivåer ner i beroendeträdet, och det är just där du behöver kunna söka när 24-timmarsklockan startar.

1. Ta med transitiva beroenden

BSI:s riktlinje kräver att beroenden följs rekursivt, åtminstone till den första komponenten som ligger utanför det du själv levererar. Det är en bra tumregel. Generera hela trädet, även om lagen bara kräver toppen.

2. Glöm inte basimagen

För en container är operativsystemets paket en del av produkten. En SBOM som bara listar applikationens npm- eller Maven-beroenden missar ofta det som faktiskt blir sårbart: OpenSSL, glibc och liknande i basimagen.

3. Identifiera komponenterna så att de går att matcha

Ange namn, version, leverantör, en PURL (package URL) eller CPE och en kontrollsumma. Utan entydiga identifierare kan skannern inte matcha komponenten mot sårbarhetsdatabaser, och då är förteckningen mest dekoration.

4. Håll sårbarheter utanför SBOM:en

En SBOM beskriver vad som finns i en version, och den ändras inte. Sårbarhetsläget ändras varje dag. Lägg bedömningar av sårbarheter i separata dokument, till exempel VEX eller CSAF, och låt SBOM:en vara statisk per version.

Så bygger du in SBOM i CI

Målet är enkelt att säga: varje artefakt som lämnar pipelinen har en SBOM som är signerad, kopplad till exakt den artefakten och sparad på ett ställe där den går att söka i om fem år.

1. Generera vid varje bygge

Låt pipelinen skapa SBOM:en för den färdiga artefakten, inte bara för källkoden. Då kommer basimage och byggberoenden med. Ett exempel med Trivy för en container-image:

trivy image --format cyclonedx --output sbom.cdx.json registry.example.se/app:1.4.2

Föredrar ni Anchores verktyg ger Syft samma typ av förteckning:

syft registry.example.se/app:1.4.2 -o cyclonedx-json=sbom.cdx.json

2. Signera och koppla till artefakten

En SBOM som ligger lös i en mapp bevisar inte mycket. Bifoga den som en signerad attestering till imagens digest, till exempel med Sigstore/Cosign. Med en egen nyckel (gärna i en KMS eller ett hemlighetsvalv):

cosign attest --yes --key cosign.key --type cyclonedx --predicate sbom.cdx.json registry.example.se/app@sha256:<digest>

Och för att verifiera, till exempel i en admission-policy eller vid leverans:

cosign verify-attestation --key cosign.pub --type cyclonedx registry.example.se/app@sha256:<digest>

Utan --key använder Cosign i stället keyless-signering, som kräver en OIDC-identitet från till exempel CI-plattformen. Tänk också på att Cosign som standard skriver en post i den publika transparensloggen Rekor. Det är ofta en fördel, men kontrollera att det passar er policy.

Nu kan vem som helst med rätt behörighet verifiera att just den här SBOM:en hör till just den här imagen, och att ingen har ändrat den i efterhand.

3. Arkivera för alla versioner som finns ute

• Spara SBOM:er för varje release, inte bara den senaste. Det är de gamla versionerna hos kunderna som brukar ställa till det.
• Lagra dem nära artefakten (i registret, till exempel Harbor) och i ett sökbart arkiv. Registret rensas ofta enligt policy, men dokumentationen ska finnas kvar i minst tio år.
• Skydda arkivet mot ändringar och radering. Det är bevismaterial.

4. Skanna det som redan är levererat

Skanna lagrade SBOM:er mot sårbarhetsdata varje dag, inte bara vid bygge. Både Trivy och Grype kan skanna en SBOM direkt, utan att hämta imagen igen: trivy sbom sbom.cdx.json eller grype sbom:sbom.cdx.json. Då upptäcker du nya sårbarheter i gamla releaser utan att bygga om något.

5. Gör det sökbart

Frågan "vilka releaser innehåller paket X i version Y?" ska kunna besvaras med en sökning, inte med en arkeologisk utgrävning. Det är den frågan som avgör om du klarar den tidiga varningen inom 24 timmar enligt artikel 14.

6. Låt AI hjälpa, men låt människor bedöma

AI-verktyg kan med fördel sammanfatta stora SBOM:er, föreslå vilka träffar som är relevanta och skriva första utkastet till en VEX-bedömning. Bedömningen av om en sårbarhet faktiskt går att utnyttja i er produkt ska ändå göras och signeras av en människa. Det är så era ingenjörer får mer tid till det som kräver omdöme.

Vanliga misstag

• SBOM bara för "stora" releaser. Hotfixen i fredags är också en release.
• Ingen koppling till artefakten. Om du inte kan visa vilken SBOM som hör till vilken image är den svår att använda som bevis.
• Manuell generering. Allt som kräver att någon kommer ihåg det kommer att glömmas bort till slut. Som Liftarens guide påpekar är det bra att veta var handduken är. Det är ännu bättre om pipelinen packar den åt dig.
• Fel ägare. SBOM är inte bara säkerhetsteamets fråga. Produktteamet äger byggena, juridik äger licenserna och någon måste äga arkivet.

Sammanfattning

• CRA kräver en maskinläsbar SBOM i ett allmänt använt format som minst täcker produktens top-level-beroenden (bilaga I del II punkt 1), från den 11 december 2027.
• Den behöver inte publiceras, men ska ingå i den tekniska dokumentationen och sparas i minst tio år.
• Inget format är fastställt ännu. CycloneDX eller SPDX är de självklara valen, och BSI TR-03183-2 är ett bra riktmärke.
• Generera hela beroendeträdet inklusive basimagen, signera SBOM:en mot artefakten, arkivera varje release och skanna dagligen.

Du ska prioritera det här nu om:

• ni säljer programvara eller uppkopplad hårdvara i EU,
• ni inte kan säga vilka releaser som innehåller en viss komponent inom en timme,
• era SBOM:er (om de finns) skapas manuellt eller bara för vissa releaser.

Vill du ha hjälp att bygga en pipeline som klarar CRA?

Vi är Sveriges go-to-specialister på Kubernetes och bygger säkra CI/CD-kedjor med SBOM, signering, skanning och policyer. Vi har erfarenhet från försvarssektorn och har gjort uppdrag för danska myndigheter, bland annat Forsvaret och tidigare Skattestyrelsen.

Vill du veta var ni står i dag? Vi gör en GAP-analys mot CRA, NIS2 och cybersäkerhetslagen och ger er en prioriterad lista över vad som saknas. Kontakta oss för offert eller ett första tekniskt samtal.

Läs mer på:

• DevOps och DevSecOps
• Compliance: NIS2 och CRA
• CRA:s rapporteringsplikt
• Cybersäkerhetslagen för dig som driftar plattformen
• Kontakta oss

Källor

Alla kontrollerade 2026-10-19.

1. Europaparlamentets och rådets förordning (EU) 2024/2847 av den 23 oktober 2024 (Cyber Resilience Act), EUT L, 20.11.2024. Skäl 77, artiklarna 13.13, 13.24, 14 och 71, bilaga I del II punkt 1, bilaga II punkt 9 och bilaga VII punkterna 2 b och 8. eur-lex.europa.eu/eli/reg/2024/2847/oj
2. Europeiska kommissionen, "Cyber Resilience Act – Implementation" (genomförandeakter, vägledning 2026-07-27, standardisering). digital-strategy.ec.europa.eu
3. BSI, Technical Guideline TR-03183-2: Software Bill of Materials (SBOM), version 2.1.0, 2025-08-20. bsi.bund.de
4. CERT-SE, "Rapporteringsplikt enligt CRA". cert.se/cyberresilienceact
5. NCSC, "Så här fungerar cyberresiliensförordningen". ncsc.se