Din kund vill ha en SBOM: en guide för komponent- och programvaruleverantörer

Den här guiden är för leverantörer i en tillverkningskedja: ECU:er, displayer, styrenheter, gateways, drivenheter, inbyggda Linuxstackar och firmwaremoduler. Om du säljer programvara och en kund har skickat en enstaka förfrågan, börja med hur du svarar på en kunds SBOM-förfrågan, som täcker det fallet.

Därför frågar OEM:erna nu

En OEM:s SBOM-förfrågan är oftast OEM:ens regelverk som når fram till dig via ett avtal. Vilket regelverk det är avgör vad OEM:en måste ha, och hur mycket av det som förs vidare till dig.

Cyber Resilience Act

Enligt Cyber Resilience Act, förordning (EU) 2024/2847, omfattar en produkt med digitala element även programvaru- eller hårdvarukomponenter som släpps ut på marknaden separat (artikel 3.1). En komponent som du säljer fristående i EU är en produkt i sig, och du är dess tillverkare, med en egen skyldighet att ta fram en SBOM: bilaga I, del II, punkt 1 kräver en SBOM i ett allmänt använt och maskinläsbart format som åtminstone omfattar produkternas beroenden på högsta nivån. Om komponenten är avsedd att integreras i andra produkter måste dina anvisningar också ge den information som integratören behöver för att uppfylla de väsentliga kraven (bilaga II, punkt 8 f).

OEM:en har också skyldigheter som når dig. Den måste iaktta tillbörlig aktsamhet när den integrerar komponenter från tredje part (artikel 13.5), och när den hittar en sårbarhet i en integrerad komponent måste den rapportera den till den person eller entitet som tillverkar eller underhåller komponenten (artikel 13.6). Kommissionens vägledning om CRA från juli 2026 säger att bevis för tillbörlig aktsamhet kan bestå av dokumentation från komponenttillverkaren, och nämner inte SBOM:er; i praktiken är en SBOM ofta den dokumentation som OEM:er ber om. Rapporteringsskyldigheterna gäller från den 11 september 2026 och förordningen gäller fullt ut från den 11 december 2027. Reservdelar som tillverkats enligt samma specifikation som komponenterna de ersätter är undantagna (artikel 2.6). För resten av förordningen, se vad CRA är och CRA-guiden.

Fordon

CRA gäller inte produkter som omfattas av förordning (EU) 2019/2144, förordningen om typgodkännande av fordon (artikel 2.2 c). Komponenter till typgodkända fordon når marknaden enligt fordonsreglerna i stället, och de reglerna nämner aldrig en SBOM.

• UN Regulation No. 155 (cybersäkerhet) kräver att tillverkaren samlar in och verifierar information genom leveranskedjan för att visa att leverantörsrelaterade risker identifieras och hanteras (5.1.1(a)), visar hur dess ledningssystem för cybersäkerhet hanterar beroenden som kan finnas till kontrakterade leverantörer, tjänsteleverantörer eller tillverkarens underorganisationer (7.2.2.5) och identifierar och hanterar leverantörsrelaterade risker för den fordonstyp som godkänns (7.3.2).
• UN Regulation No. 156 (programvaruuppdateringar) kräver att alla ursprungliga och uppdaterade programvaruversioner är unikt identifierbara (7.1.1.2) och, för varje RX Software Identification Number (RXSWIN), ett granskningsbart register som beskriver all programvara som är relevant för RXSWIN (7.1.2.3).
• ISO/SAE 21434 organiserar cybersäkerhetsarbetet mellan OEM och leverantör som fördelade aktiviteter, med fördelningen överenskommen i ett cybersecurity interface agreement.
• Auto-ISAC SBOM Informational Report (februari 2025) ger branschens egen vägledning.

Inom fordonsindustrin kommer en SBOM som ett avtalskrav, inte ett lagkrav.

Industriell automation

IEC 62443-4-1 gäller leverantörer av produkter för industriella automations- och styrsystem. Den nämner inte SBOM:er, men praxis 6, hantering av säkerhetsrelaterade problem (DM-1 till DM-6), och praxis 7, hantering av säkerhetsuppdateringar (SUM-1 till SUM-5, inklusive SUM-3, "Dependent component or operating system security update documentation"), är där en SBOM fungerar som bevis.

Maskiner

Förordning (EU) 2023/1230 om maskiner gäller från den 20 januari 2027 och nämner inte SBOM:er. Dess väsentliga krav på skydd mot förvanskning (bilaga III, 1.1.9) innebär att programvara som är avgörande för överensstämmelsen ska identifieras och skyddas, att maskinen ska kunna identifiera den programvara som är installerad på den och som behövs för att den ska fungera säkert, och att bevis på ingrepp i den programvaran ska samlas in. Maskiner med digitala element omfattas också av CRA, till skillnad från typgodkända fordon, och därför ber maskintillverkare redan nu sina leverantörer om SBOM:er. Se CRACI för maskintillverkare och industriell IoT.

NIS2 och certifierade kunder

Om du levererar till väsentliga eller viktiga entiteter, till exempel inom halvledare, kräver artikel 21.2 d i NIS2 att din kund hanterar säkerheten i leveranskedjan. Den nämner inte SBOM:er. Kunder gör om den till frågeformulär, och kontrollerna 5.21 och 8.8 i bilaga A till ISO/IEC 27001 är där en SBOM fungerar som bevis. Se SBOM:er som bevis för ISO 27001, SOC 2 och NIS2.

Regelverken sida vid sida

Regelverk	Gäller	Nämner en SBOM?	Vad som når leverantören
Cyber Resilience Act	Produkter med digitala element på EU-marknaden, inklusive komponenter som säljs separat	Ja, bilaga I, del II (1)	Direkt om du släpper ut komponenten på marknaden; via OEM:ens tillbörliga aktsamhet (art. 13.5) och sårbarhetsrapporter (art. 13.6)
UN R155 och R156	Fordonstillverkare som söker typgodkännande	Nej	Hantering av leverantörsrisk (R155 7.2.2.5, 7.3.2) och identifiering av programvara (R156), via avtal
ISO/SAE 21434	Cybersäkerhetsteknik för vägfordon, OEM:er och leverantörer	Inte i den offentliga beskrivningen	Fördelade aktiviteter och ett cybersecurity interface agreement
IEC 62443-4-1	Leverantörer av produkter för industriella automations- och styrsystem	Nej	Direkt om du är produktleverantören; SBOM:er fungerar som bevis för DM och SUM
Förordningen om maskiner	Maskiner och relaterade produkter på EU-marknaden	Nej	Identifiering och skydd av programvara (bilaga III 1.1.9); CRA gäller vid sidan av
NIS2	Väsentliga och viktiga entiteter	Nej	Frågeformulär om säkerhet i leveranskedjan och avtalsvillkor (art. 21.2 d, 21.3)

Oavsett väg behöver kunden samma sak: en korrekt SBOM för varje programvaruversion du levererar.

Vad OEM:er brukar be om

Kraven skiljer sig mellan OEM:er, men de landar i samma lista. Kontrollera din SBOM mot den före första leveransen.

Krav	Typisk förväntan
Format	CycloneDX eller SPDX, JSON eller XML, med en lägsta specifikationsversion. BSI TR-03183-2 anger CycloneDX 1.6 eller senare, eller SPDX 3.0.1 eller senare.
Fält	I linje med CISA 2026 Minimum Elements eller BSI TR-03183-2: upphovsperson, tidsstämpel, och för varje komponent namn, version, producent och identifierare
Identifierare	En package URL där ekosystemet har en, en CPE där det saknas, så att komponenterna kan matchas mot sårbarhetsdatabaser
Licenser	SPDX-licensidentifierare. OEM:ens licensspecialist läser dem för att bedöma copyleft och andra licensrisker.
Hashvärden	En hash av varje levererad binärfil, så att OEM:en kan bekräfta att SBOM:en beskriver filen den har fått. BSI kräver SHA-512.
Djup	Transitiva beroenden, inte bara högsta nivån
Granularitet	En SBOM per levererad programvaruversion eller artikelnummer
Leverans och svarstider	En leveranskanal, och svarstider för frågor om sårbarheter

Många OEM:er kontrollerar detta automatiskt när filen kommer in. Se checklistan för SBOM-kvalitet för vad din kund kommer att kontrollera, och vilka verktyg de använder, och SBOM-exempel för hur fälten ser ut i en fil.

Din SBOM när det finns lite eller ingen öppen källkod

En bare metal-ECU eller styrenhet med proprietär firmware från modellbaserad kodgenerering har en ärlig SBOM som kan vara kort: den proprietära applikationen, din starthanterare, en kretsleverantörs bibliotek eller kalibrering, och eventuell öppen källkod som ett kryptografibibliotek. Det är ett giltigt svar. Reglerna:

• Lista proprietära komponenter med dina egna identifierare: namn, version och dig själv som producent.
• Ange de kända okända, till exempel ett leverantörsbibliotek vars innehåll du inte kan se.
• Fyll aldrig ut SBOM:en för att den ska se grundlig ut, och utelämna aldrig ett bibliotek med öppen källkod för att det är litet.

För Linuxbaserade displayer och gateways gäller det motsatta: hundratals eller tusentals komponenter, inklusive kärnan, starthanteraren och baspaketen (se uppkopplade enheter). En SBOM som bara listar din applikation och några bibliotek är det första ett mottagande team flaggar. Om du bygger med Yocto, se varför skannrar missar det som finns i Yocto-byggen.

Avtal: vad ni ska enas om före första leveransen

Villkor	Varför det spelar roll
Vilka produkter och programvaruversioner som omfattas	Så att ingen senare tvistar om huruvida en variant eller en servicerelease behövde en SBOM
Format och specifikationsversion	Deras mottagningspipeline kan avvisa allt annat
Fält och ramverket de följer	"BSI TR-03183-2 v2.1.0" eller "CISA 2026 Minimum Elements" går att testa; "en fullständig SBOM" gör det inte
Vad som utlöser en leverans	Varje release, varje programvaruversion som levereras till OEM:en och varje rättelse
Leveranskanal	OEM:ens leverantörsportal, säkert filutbyte eller e-post under NDA
Sekretess	Ett NDA eller det befintliga leveransavtalet, där SBOM:en anges som konfidentiell information
Användningsbegränsningar	Endast för sårbarhetshantering och efterlevnad, ingen vidaredelning utan samtycke
Sårbarhetsmeddelanden, åt båda hållen	OEM:en rapporterar sårbarheter som den hittar i din komponent (CRA art. 13.6); du meddelar den om dina
Förväntningar på VEX	Vilket format, och hur snabbt du bedömer en ny CVE
Lagringstid	Hur länge du sparar SBOM:en för varje version, anpassat till produktens supportperiod
Korrekthet och kända okända	En ärlig klausul om vad SBOM:en kan och inte kan täcka skyddar båda parter

CISA:s SBOM Sharing Primer beskriver fordonsfallet på samma sätt: SBOM-förfrågningar ingår i de vanliga avtalen om informationsutbyte, till exempel sekretessavtal, cybersecurity interface agreement och development interface agreement.

Att dela utan att röja IP

En SBOM är inte din källkod. Den listar komponenternas namn, versioner, producenter, licenser, hashvärden och relationer. Den innehåller inte din kod, dina algoritmer, dina kalibreringsdata eller din konstruktion.

• CRA ålägger inte tillverkare att offentliggöra SBOM:en (skäl 77). Den lämnas till en marknadskontrollmyndighet på motiverad begäran (bilaga VII, punkt 8).
• CISA:s vägledning om delning beskriver de vanliga kanalerna för proprietär programvara: e-post under ett NDA, kundens leverantörsportal eller ett säkert dokumentutbyte, eller en egen portal med åtkomstkontroll, där avtal reglerar sekretess och åtkomst.
• Praktiska alternativ: en fullständig SBOM per OEM under avtal; identifierare för proprietära delar som inte avslöjar interna projektnamn; och ett separat VEX-dokument, så att du kan uppdatera en sårbarhets status utan att skicka SBOM:en igen.

Hur ofta, och vad som händer efter leveransen

• En ny SBOM för varje programvaruversion du levererar, under samma identifierare som OEM:en flashar eller registrerar. För fordon knyter det an till programvaruidentifieringen i R156.
• En rättad SBOM när du hittar ett fel i en som du har skickat.
• Ett VEX-uttalande eller ett säkerhetsmeddelande när du har bedömt en sårbarhet.

Följdfrågan, "påverkas ni av CVE-X?", kommer med nästa stora sårbarhet. Var redo att besvara den per levererad version, vilket bara går om du har sparat SBOM:en för var och en.

VEX: vad din kund kommer att förvänta sig härnäst

Ett VEX-dokument anger om en produkt påverkas av en sårbarhet. CISA:s Minimum Requirements for VEX (april 2023) definierar fyra statusar: not_affected, affected, fixed och under_investigation. Ett not_affected-uttalande bör ange en av fem motiveringar, eller annars en konsekvensbeskrivning (impact statement):

• component_not_present
• vulnerable_code_not_present
• vulnerable_code_not_in_execute_path
• vulnerable_code_cannot_be_controlled_by_adversary
• inline_mitigations_already_exist

Ett affected-uttalande behöver en åtgärdsbeskrivning (action statement): vad kunden ska göra. VEX finns i tre format: VEX-profilen i CSAF 2.0, CycloneDX VEX och OpenVEX. Yoctos SPDX 3.0-utdata innehåller VEX-data som standard (variabeln SPDX_INCLUDE_VEX).

Exempel. En Linuxbaserad display levereras med OpenSSL 3.0.8. CVE-2023-0464 beskriver överdriven resursanvändning vid verifiering av X.509-certifikatkedjor som innehåller policybegränsningar. Policyhanteringen är avstängd som standard, och displayens programvara aktiverar den aldrig. Leverantören skickar ett OpenVEX-uttalande, här som illustration:

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://example.com/vex/display-fw-5.3.0-2023-0464",
  "author": "Example Displays Product Security",
  "timestamp": "2026-11-11T09:00:00Z",
  "version": 1,
  "statements": [
    {
      "vulnerability": { "name": "CVE-2023-0464" },
      "products": [{ "@id": "pkg:generic/example/[email protected]" }],
      "status": "not_affected",
      "justification": "vulnerable_code_not_in_execute_path",
      "impact_statement": "X.509 policy processing is disabled by default and the firmware never enables it."
    }
  ]
}

Att ta fram SBOM:er på ett upprepbart sätt

Hur du bygger	Realistiskt sätt att ta fram SBOM:en
Programvara som byggs i CI	Ta fram SBOM:en i bygget som producerar den levererade programvaran, och spara den med releasen
Yocto-baserad inbyggd Linux	Yoctos egen SPDX-utdata (create-spdx), kontrollerad för vad den utelämnar, eller en registrering av Yocto-bygget
Bare metal-firmware från modellbaserade verktyg	Ett generatorbibliotek eller verktyg, aldrig en textredigerare, som underhålls med varje release och valideras innan filen skickas
Binärfiler från tredje part som du integrerar	Be din egen leverantör om dess SBOM; binäranalys som ersättning tills den kommer

Oavsett väg: validera filen innan du skickar den. Checklistan för SBOM-kvalitet listar de validerare som din kund sannolikt kör, CycloneDX vs SPDX hjälper dig med formatet, och att standardisera SBOM-genereringen handlar om att göra den likadan i alla team.

Var CRACI passar in

För leverantörer som bygger på GitHub Actions ersätter CRACI de GitHub-hostade runnerna och registrerar en SBOM från varje bygge, så att varje levererad version redan har en.

• SBOM:en listar det som bygget faktiskt drog in, inklusive transitiva beroenden, med en package URL per paket och den angivna licensen för varje komponent.
• Varje jobbs SBOM har en fullständighetsstatus, så att du vet vad du skickar innan du skickar det.
• SBOM:er exporteras som CycloneDX eller SPDX, och CRACI stöder VEX.
• Bevakade SBOM:er omvärderas när nya sårbarheter publiceras, och bygghistoriken visar vilka byggen som innehöll ett sårbart beroende, inom din lagringstid.
• Yocto-byggen körs på CRACI:s runners och är dokumenterade.
• SBOM:er från tredje part kan läggas till, så att komponenter du köper in bevakas tillsammans med dina egna byggen.

När CRACI inte är svaret

• Du har ingen CI, eller så bygger du på GitLab, Jenkins eller en byggserver. CRACI har i dag bara stöd för GitHub Actions; andra CI-system finns på färdplanen.
• Din firmware genereras från modellbaserade verktyg utan att några paket hämtas. En byggregistrering tillför lite där.
• Du behöver lagra SBOM:er för många OEM:er i en delningsportal, eller signera SBOM:er. CRACI erbjuder inget av det.
• Dina byggen måste köras på din egen infrastruktur. Kundhostade runners finns på färdplanen.
• Din kund vill ha bevis på din organisations säkerhetsarbete, som ett ISO 27001-certifikat eller svar på ett NIS2-frågeformulär. En SBOM är bevis för en del av det, inte en certifiering. CRACI:s eget ISO 27001-certifikat gäller CRACI:s tjänst, inte din.

SBOM:er för leverantörer: vanliga frågor

Min kund, en OEM, har bett om en SBOM. Är jag skyldig att leverera en?

Ofta är det avtalet som kräver det snarare än lagen. Om du själv släpper ut en komponent med digitala element på EU-marknaden kräver Cyber Resilience Act en egen SBOM. Annars ligger skyldigheten hos OEM:en, som för den vidare till dig genom tillbörlig aktsamhet och leveransavtalet.

Gäller CRA komponenter som jag säljer till en tillverkare?

Om du släpper ut komponenten separat på EU-marknaden, ja: artikel 3.1 omfattar programvaru- eller hårdvarukomponenter som släpps ut på marknaden separat. Om den bara når marknaden inuti OEM:ens produkt är OEM:en tillverkaren och måste iaktta tillbörlig aktsamhet för din komponent (artikel 13.5). Komponenter till typgodkända fordon ligger utanför CRA (artikel 2.2 c).

Kräver UN R155 eller ISO/SAE 21434 en SBOM?

Nej. R155 nämner aldrig en SBOM; den kräver att fordonstillverkaren hanterar leverantörsrelaterade risker. ISO/SAE 21434 organiserar cybersäkerhetsarbetet med leverantörer genom interface agreements. Inom fordonsindustrin kommer SBOM:er som ett avtalskrav.

Vilket format och vilka fält förväntar sig en OEM?

Oftast CycloneDX eller SPDX i JSON eller XML, i linje med CISA 2026 Minimum Elements eller BSI TR-03183-2: upphovsperson och tidsstämpel, och för varje komponent namn, version, producent, package URL eller CPE, licens och hash, med transitiva beroenden.

Hur ofta måste jag skicka en uppdaterad SBOM?

För varje programvaruversion du levererar, varje gång du rättar ett fel, och tillsammans med ett VEX-uttalande eller ett säkerhetsmeddelande när du har bedömt en sårbarhet. Kom överens om vad som utlöser en leverans i avtalet.

Röjer vi vår immateriella egendom om vi delar en SBOM?

Nej. En SBOM listar komponenternas namn, versioner, producenter, licenser, hashvärden och relationer, inte källkod, algoritmer eller kalibreringsdata. Dela den under ett NDA eller leveransavtalet, med användningen begränsad till sårbarhetshantering och efterlevnad. CRA kräver inte att den är offentlig.

Vad är VEX, och kommer min kund att be om det?

VEX anger om en produkt påverkas av en sårbarhet: not_affected, affected, fixed eller under_investigation, med en motivering för not_affected. Räkna med att få frågan efter nästa uppmärksammade sårbarhet i en komponent som du levererar.

Vår ECU-firmware innehåller ingen öppen källkod. Hur ser vår SBOM ut?

Kort och ärlig: den proprietära applikationen, starthanteraren, eventuella bibliotek eller kalibrering från kretsleverantören och eventuell öppen källkod som ett kryptografibibliotek, var och en med dina egna identifierare, plus de kända okända. Fyll inte ut den.