Del av vår guide till cyberresiliensförordningen. Granskad 17 oktober 2026.
Vad en SBOM innehåller
En programvaruförteckning (SBOM, software bill of materials) är en formell, maskinläsbar förteckning över programvarukomponenterna i en produkt och hur de hänger ihop: namn, versioner, leverantörer och beroenden. För ett hårdvaruteam blir en SBOM användbar först när ni kopplar den till exakt det firmwarebygge och den hårdvarurevision den beskriver. Som styrt dokument visar den vad som levererades och vad en ny sårbarhet berör.
Vad cyberresiliensförordningen säger om SBOM
EU:s cyberresiliensförordning, förordning (EU) 2024/2847, gör programvaruförteckningen till en del av tillverkarens skyldigheter för sårbarhetshantering. Det viktigaste:
- Definition. En programvaruförteckning är "en formell förteckning med närmare uppgifter om och leveranskedjeförhållanden för komponenter" i produktens programvaruelement (artikel 3.39).
- Krav. Tillverkare ska identifiera och dokumentera komponenter, bland annat genom en programvaruförteckning i ett allmänt använt och maskinläsbart format som åtminstone täcker de översta beroendena (bilaga I, del II, punkt 1).
- Teknisk dokumentation. SBOM:en ingår i underlaget om sårbarhetshantering i den tekniska dokumentationen (bilaga VII, punkt 2 b), och ska lämnas till en marknadskontrollmyndighet efter en motiverad begäran (bilaga VII, punkt 8).
- Offentliggörande är frivilligt. Tillverkare är inte skyldiga att göra SBOM:en offentlig (skäl 77). Om ni delar den med användarna ska användarinformationen ange var den finns (bilaga II, punkt 9).
- Formatet kan fastställas senare. Kommissionen får specificera SBOM:ens format och innehåll genom genomförandeakter (artikel 13.24).
I praktiken ska ni kunna ta fram SBOM:en för en viss produkt flera år efter leverans; reglerna för arkivering finns under "SBOM som styrda dokument" längre ned.
Minimielement
Förordningen listar inte själv några datafält; kommissionen kan specificera dem senare (artikel 13.24). En ofta citerad utgångspunkt är den amerikanska NTIA-rapporten The Minimum Elements for a Software Bill of Materials (2021), som anger sju datafält per komponent:
| Datafält | Vad det anger |
|---|---|
| Leverantörsnamn | Vem som skapar, definierar och identifierar komponenten |
| Komponentnamn | Namnet som den ursprungliga leverantören gett den |
| Version | Leverantörens beteckning för just den versionen |
| Andra unika identifierare | Söknycklar som CPE, SWID-taggar eller Package URL (PURL) |
| Beroenderelation | Att komponent X ingår i programvara Y |
| Författare av SBOM-data | Vem som skapat posten i förteckningen |
| Tidsstämpel | När SBOM-datan sammanställdes |
I Tyskland går BSI längre i sin tekniska riktlinje TR-03183-2, som är skriven med CRA i åtanke. Version 2.1.0 kräver JSON eller XML i CycloneDX 1.6 eller senare, eller SPDX 3.0.1 eller senare, och anger att en separat SBOM ska tas fram för varje programvaruversion. TR-03183-2 är en nationell riktlinje, inte en del av förordningen, och en användbar referens i väntan på specifikationer på EU-nivå.
SPDX och CycloneDX
Det mesta av vägledningen kring SBOM, även BSI TR-03183-2, pekar på två öppna, maskinläsbara och formellt standardiserade format.
| SPDX | CycloneDX | |
|---|---|---|
| Förvaltas av | Linux Foundation | OWASP |
| Formell standard | ISO/IEC 5962:2021 | Ecma International, ECMA-424 |
| Inriktning | Säkerhet, licensefterlevnad och annan data om leveranskedjan | Leveranskedja och minskad cyberrisk |
| Utöver programvara | Referenser för AI och data | Även hårdvaruförteckningar (HBOM) och SaaS-förteckningar |
| Officiell webbplats | spdx.dev | cyclonedx.org |
Välj det format som era byggverktyg och kunder redan använder. Konsekvens väger tyngre: generera SBOM:en från bygget vid varje release.
Varför en SBOM hör till en viss revision
Samma kortrevision levereras med flera firmwareversioner under sin livstid, och en firmwareversion kan köras på mer än en kortrevision. Om er SBOM inte är kopplad till båda får ni svårt att använda den vid en incident.
Publiceras en sårbarhet i ett bibliotek behöver ni veta vilka firmwareversioner som innehåller den, vilka hårdvarurevisioner som kör de versionerna och vilka levererade enheter som berörs. För att svara behöver ni:
- en SBOM per släppt firmware- eller programvaruversion, som BSI TR-03183-2 kräver
- en koppling från den SBOM:en till firmwareartikeln och till varje hårdvarurevision den är frisläppt för
- produktidentifiering på enheten, som CRA redan kräver i form av typ-, parti- eller serienummer (artikel 13.15)
- de programvaruversioner som påverkar överensstämmelsen, angivna i den tekniska dokumentationen (bilaga VII, punkt 1 b)
Utan de kopplingarna svarar en SBOM på "vad finns i det här bygget" och lämnar "vilka kunder har det här bygget" obesvarad.
Glappet mellan konstruktionsstrukturen och SBOM
Ni har sannolikt redan en artikelstruktur (BOM) för konstruktionen. Den är sällan kopplad till SBOM:en.
| Artikelstruktur (EBOM) | SBOM | |
|---|---|---|
| Beskriver | Artiklar, sammanställningar, material | Programvarukomponenter och beroenden |
| Ägs av | Mekanik- och elektronikkonstruktion | Firmware- och mjukvaruteam |
| Finns i | PDM, PLM eller kalkylblad | Byggflöde, kodförråd eller SBOM-verktyg |
| Ändras | Genom ändringsorder | Vid varje bygge |
| Identifierare | Artikelnummer och revisioner | Paketnamn, versioner, PURL |
Överbrygga dem genom att behandla varje frisläppt firmwareavbild som en artikel i artikelstrukturen, med eget artikelnummer och egen revision, och koppla SBOM:en till den artikeln. Hårdvarustrukturen visar då sin firmware, och firmwareartikeln bär sin SBOM. Frisläpp firmwareartikeln genom samma ändringsprocess som hårdvaran.
Firmware i produktstrukturen. 1: SW Image är en egen artikel med eget nummer och revision, och SBOM:en kopplas till den.
SBOM som styrda dokument
En SBOM som används som underlag för regelefterlevnad behöver samma styrning som en ritning eller en testrapport:
- Versionshantering. Spara varje SBOM. Varje firmwarerelease får en ny SBOM bredvid de tidigare.
- Godkännande. Granska och godkänn SBOM:en som en del av firmwarefrisläppningen, med namngiven godkännare och datum.
- Koppling till revisioner. Koppla varje SBOM till sin firmwareartikel och till de hårdvarurevisioner den levereras på.
- Spårbarhet i ändringar. Dokumentera varför en komponent ändrades, genom den ändringsbegäran som införde ändringen.
- Arkivering. Spara SBOM:er med den tekniska dokumentationen i minst 10 år efter utsläppandet på marknaden, eller under stödperioden om den är längre (artikel 13.13).
- Styrd delning. Ge kunder och myndigheter SBOM:en för deras revision, och inget annat. Skäl 77 lämnar offentliggörandet åt er, så ni bestämmer vem som får åtkomst.
Vad neo gör, och inte gör
neo hanterar SBOM:er som styrda dokument. Ni kan lagra SBOM-filer, SPDX eller CycloneDX, versionshantera dem, skicka dem genom godkännande och koppla dem till de firmware- och hårdvarurevisioner de beskriver. Ändringsbegäran visar varför de ändrades, granskningsloggar visar vem som gjorde vad, och via leverantörs- och kundportaler delar ni en viss SBOM med dem som behöver den.
neo genererar inte SBOM:er och söker inte efter sårbarheter. Generera SBOM:er i ert byggflöde och bevaka sårbarheter med särskilda verktyg för SBOM eller mjukvarukompositionsanalys. De verktygen tar fram och analyserar SBOM:en; neo håller den godkänd, versionshanterad och kopplad till rätt produktrevision. Övriga CRA-dokument finns i CRA-checklistan för konstruktion, och ni kan också prata med oss om er uppsättning.