Kunden din vil ha en SBOM: en guide for komponent- og programvareleverandører

Denne guiden er for leverandører i en produksjonsleverandørkjede: ECU-er, skjermer, kontrollere, gatewayer, drivverk, innebygde Linux-stakker og fastvaremoduler. Selger du programvare og en kunde har sendt en enkeltstående forespørsel, start med slik svarer du på en SBOM-forespørsel fra en kunde, som dekker det tilfellet.

Derfor spør OEM-ene nå

En SBOM-forespørsel fra en OEM er som regel OEM-ens regelverk som når deg gjennom en kontrakt. Hvilket regelverk det er, avgjør hva OEM-en må ha, og hvor mye av det som sendes videre til deg.

Cyber Resilience Act

Etter Cyber Resilience Act, forordning (EU) 2024/2847, omfatter et produkt med digitale elementer også programvare- eller maskinvarekomponenter som bringes i omsetning separat (artikkel 3(1)). En komponent du selger for seg selv i EU, er et produkt i egen rett, og du er produsenten, med din egen SBOM-plikt: vedlegg I, del II, punkt 1 ber om en SBOM i et vanlig brukt og maskinlesbart format som minst dekker produktenes avhengigheter på toppnivå. Er komponenten ment for integrering i andre produkter, må instruksjonene dine også gi integratoren informasjonen som trengs for å oppfylle de grunnleggende kravene (vedlegg II, punkt 8(f)).

OEM-en har også forpliktelser som når deg. Den må utvise aktsomhet når den integrerer komponenter fra tredjeparter (artikkel 13(5)), og når den finner en sårbarhet i en komponent den har integrert, må den rapportere den til personen eller enheten som produserer eller vedlikeholder komponenten (artikkel 13(6)). Kommisjonens CRA-veiledning fra juli 2026 sier at bevis for aktsomhet kan bestå av dokumentasjon fra komponentprodusenten, og nevner ikke SBOM-er; i praksis er en SBOM ofte dokumentasjonen OEM-er ber om. Rapporteringspliktene gjelder fra 11. september 2026, og forordningen gjelder fullt ut fra 11. desember 2027. Reservedeler laget etter samme spesifikasjon som komponentene de erstatter, er unntatt (artikkel 2(6)). For resten av forordningen, se hva CRA er og CRA-guiden.

Kjøretøy

CRA gjelder ikke for produkter som omfattes av forordning (EU) 2019/2144, forordningen om typegodkjenning av kjøretøy (artikkel 2(2)(c)). Komponenter til typegodkjente kjøretøy kommer i stedet på markedet etter kjøretøyregler, og de reglene nevner aldri en SBOM.

• UN Regulation No. 155 (cybersikkerhet) krever at produsenten samler inn og verifiserer informasjon gjennom leverandørkjeden for å vise at leverandørrelaterte risikoer er identifisert og håndteres (5.1.1(a)), viser hvordan styringssystemet for cybersikkerhet vil håndtere avhengigheter til kontraherte leverandører, tjenesteleverandører eller produsentens underorganisasjoner (7.2.2.5), og identifiserer og håndterer leverandørrelaterte risikoer for kjøretøytypen som godkjennes (7.3.2).
• UN Regulation No. 156 (programvareoppdateringer) krever at alle opprinnelige og oppdaterte programvareversjoner er entydig identifiserbare (7.1.1.2), og for hvert RX Software Identification Number (RXSWIN) et reviderbart register som beskriver all programvare som er relevant for RXSWIN-en (7.1.2.3).
• ISO/SAE 21434 organiserer cybersikkerhetsarbeidet mellom OEM og leverandør som distribuerte aktiviteter, med fordelingen avtalt i en cybersecurity interface agreement.
• Auto-ISAC SBOM Informational Report (februar 2025) gir bransjens egen veiledning.

I bilindustrien kommer en SBOM som et kontraktskrav, ikke et lovkrav.

Industriell automatisering

IEC 62443-4-1 gjelder leverandører av produkter for industrielle automasjons- og styringssystemer. Den nevner ikke SBOM-er, men practice 6, håndtering av sikkerhetsrelaterte problemer (DM-1 til DM-6), og practice 7, håndtering av sikkerhetsoppdateringer (SUM-1 til SUM-5, inkludert SUM-3, «Dependent component or operating system security update documentation»), er der en SBOM fungerer som bevis.

Maskiner

Maskinforordningen (EU) 2023/1230 gjelder fra 20. januar 2027 og nevner ikke SBOM-er. De grunnleggende kravene om beskyttelse mot korrupsjon (vedlegg III, 1.1.9) ber om at programvare som er avgjørende for samsvar, identifiseres og beskyttes, at maskinen kan identifisere programvaren som er installert på den og som trengs for sikker drift, og at bevis for inngrep i den programvaren samles inn. Maskiner med digitale elementer faller også inn under CRA, i motsetning til typegodkjente kjøretøy, og derfor ber maskinprodusenter leverandørene sine om SBOM-er nå. Se CRACI for maskinprodusenter og industriell IoT.

NIS2 og sertifiserte kunder

Leverer du til vesentlige eller viktige enheter, for eksempel innen halvledere, krever NIS2 artikkel 21(2)(d) at kunden din tar tak i sikkerheten i leverandørkjeden. Den nevner ikke SBOM-er. Kundene gjør den om til spørreskjemaer, og kontrollene 5.21 og 8.8 i vedlegg A til ISO/IEC 27001 er der en SBOM fungerer som bevis. Se SBOM-er som bevis for ISO 27001, SOC 2 og NIS2.

Regelverkene side om side

Regelverk	Gjelder for	Nevner det en SBOM?	Hva som når leverandøren
Cyber Resilience Act	Produkter med digitale elementer på EU-markedet, inkludert komponenter som selges separat	Ja, vedlegg I, del II (1)	Direkte hvis du bringer komponenten i omsetning; gjennom OEM-ens aktsomhet (art. 13(5)) og sårbarhetsrapporter (art. 13(6))
UN R155 og R156	Kjøretøyprodusenter som søker typegodkjenning	Nei	Styring av leverandørrisiko (R155 7.2.2.5, 7.3.2) og programvareidentifikasjon (R156), gjennom kontrakter
ISO/SAE 21434	Cybersikkerhetsteknikk for veikjøretøy, OEM-er og leverandører	Ikke i den offentlige beskrivelsen	Distribuerte aktiviteter og en cybersecurity interface agreement
IEC 62443-4-1	Leverandører av produkter for industrielle automasjons- og styringssystemer	Nei	Direkte hvis du er produktleverandøren; SBOM-er fungerer som bevis for DM og SUM
Maskinforordningen	Maskiner og tilhørende produkter på EU-markedet	Nei	Identifikasjon og beskyttelse av programvare (vedlegg III 1.1.9); CRA gjelder ved siden av
NIS2	Vesentlige og viktige enheter	Nei	Spørreskjemaer om leverandørkjedesikkerhet og kontraktsvilkår (art. 21(2)(d), 21(3))

Uansett vei trenger kunden det samme: en nøyaktig SBOM for hver programvareversjon du leverer.

Hva OEM-er vanligvis ber om

Kravene varierer mellom OEM-er, men de samler seg om den samme listen. Sjekk SBOM-en din mot den før første leveranse.

Krav	Typisk forventning
Format	CycloneDX eller SPDX, JSON eller XML, med en minste spesifikasjonsversjon. BSI TR-03183-2 setter CycloneDX 1.6 eller nyere, eller SPDX 3.0.1 eller nyere.
Felt	I tråd med CISA 2026 Minimum Elements eller BSI TR-03183-2: forfatter, tidsstempel, og for hver komponent navn, versjon, produsent og identifikatorer
Identifikatorer	En package URL der økosystemet har en, en CPE der det ikke har det, så komponentene kan matches mot sårbarhetsdatabaser
Lisenser	SPDX-lisensidentifikatorer. OEM-ens lisensspesialist leser dem for å vurdere copyleft og annen lisensrisiko.
Hasher	En hash av hver levert binærfil, så OEM-en kan bekrefte at SBOM-en beskriver filen den mottok. BSI ber om SHA-512.
Dybde	Transitive avhengigheter, ikke bare toppnivået
Granularitet	Én SBOM per levert programvareversjon eller delenummer
Levering og respons	En leveringskanal, og svartider for spørsmål om sårbarheter

Mange OEM-er sjekker dette automatisk ved mottak. Se sjekklisten for SBOM-kvalitet for hva kunden din vil sjekke og verktøyene de bruker, og SBOM-eksempler for hvordan feltene ser ut i en fil.

SBOM-en din når det er lite eller ingen åpen kildekode

En bare-metal-ECU eller kontroller med proprietær fastvare fra modellbasert kodegenerering har en ærlig SBOM som kan være kort: den proprietære applikasjonen, bootloaderen din, biblioteker eller kalibrering fra en halvlederleverandør, og eventuell åpen kildekode som et kryptografibibliotek. Det er et gyldig svar. Reglene:

• List proprietære komponenter med egne identifikatorer: navn, versjon og deg selv som produsent.
• Oppgi de kjente ukjente, som et leverandørbibliotek du ikke kan se innholdet i.
• Fyll aldri på SBOM-en for at den skal se grundig ut, og utelat aldri et bibliotek med åpen kildekode fordi det er lite.

For Linux-baserte skjermer og gatewayer gjelder det motsatte: hundrevis eller tusenvis av komponenter, inkludert kjernen, bootloaderen og basissystempakkene (se tilkoblede enheter). En SBOM som bare lister applikasjonen din og noen få biblioteker, er det første et mottakende team flagger. Bygger du med Yocto, se hvorfor skannere går glipp av det som er i Yocto-bygg.

Kontrakter: hva du avtaler før første leveranse

Vilkår	Hvorfor det betyr noe
Produkter og programvareversjoner som omfattes	Så ingen krangler senere om en variant eller en serviceutgivelse trengte en SBOM
Format og spesifikasjonsversjon	Mottakspipelinen deres kan avvise alt annet
Feltene og rammeverket de følger	«BSI TR-03183-2 v2.1.0» eller «CISA 2026 Minimum Elements» kan testes; «en fullstendig SBOM» kan ikke
Utløser for levering	Hver utgivelse, hver programvareversjon som sendes til OEM-en, og hver rettelse
Leveringskanal	OEM-ens leverandørportal, sikker filutveksling eller e-post under NDA
Konfidensialitet	En NDA eller den eksisterende leveringsavtalen, som nevner SBOM-en som konfidensiell informasjon
Bruksbegrensninger	Bare sårbarhetshåndtering og samsvar, ingen videredeling uten samtykke
Varsling om sårbarheter, begge veier	OEM-en rapporterer sårbarheter den finner i komponenten din (CRA art. 13(6)); du varsler den om dine
Forventninger til VEX	Hvilket format, og hvor raskt du vurderer en ny CVE
Oppbevaring	Hvor lenge du oppbevarer SBOM-en for hver versjon, tilpasset produktets støtteperiode
Nøyaktighet og kjente ukjente	Et ærlig vilkår om hva SBOM-en kan og ikke kan dekke, beskytter begge parter

CISAs SBOM Sharing Primer beskriver bilindustrien på samme måte: SBOM-forespørsler tas inn i standard avtaler om informasjonsutveksling, for eksempel en taushetserklæring, en cybersecurity interface agreement eller en development interface agreement.

Deling uten å lekke immaterielle verdier

En SBOM er ikke kildekoden din. Den lister komponentnavn, versjoner, produsenter, lisenser, hasher og relasjoner. Den inneholder ikke koden, algoritmene, kalibreringsdataene eller designet ditt.

• CRA pålegger ikke produsenter å gjøre SBOM-en offentlig (fortalepunkt 77). Den går til en markedstilsynsmyndighet etter en begrunnet anmodning (vedlegg VII, punkt 8).
• CISAs veiledning om deling beskriver de vanlige kanalene for proprietær programvare: e-post under NDA, kundens leverandørportal eller en sikker dokumentutveksling, eller din egen portal med tilgangskontroll, med kontrakter som regulerer konfidensialitet og tilgang.
• Praktiske alternativer: én fullstendig SBOM per OEM under kontrakt; identifikatorer for proprietære deler som ikke avslører interne prosjektnavn; og et eget VEX-dokument, så du kan oppdatere statusen til en sårbarhet uten å sende SBOM-en på nytt.

Hvor ofte, og hva som skjer etter levering

• En ny SBOM for hver programvareversjon du leverer, under samme identifikator som OEM-en flasher eller registrerer. For kjøretøy knytter det seg til programvareidentifikasjonen i R156.
• En rettet SBOM når du finner en feil i en du har sendt.
• En VEX-erklæring eller en advisory når du har vurdert en sårbarhet.

Oppfølgingsspørsmålet, «er dere berørt av CVE-X?», kommer med neste store sårbarhet. Vær klar til å svare per levert versjon, noe som bare er mulig hvis du har oppbevart SBOM-en for hver av dem.

VEX: hva kunden din vil forvente som neste steg

Et VEX-dokument sier om et produkt er berørt av en sårbarhet. CISAs Minimum Requirements for VEX (april 2023) definerer fire statuser: not_affected, affected, fixed og under_investigation. En not_affected-erklæring bør gi én av fem begrunnelser, eller ellers en 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

En affected-erklæring trenger en action statement: hva kunden bør gjøre. VEX finnes i tre formater: VEX-profilen i CSAF 2.0, CycloneDX VEX og OpenVEX. Yoctos SPDX 3.0-utdata inkluderer VEX-data som standard (variabelen SPDX_INCLUDE_VEX).

Eksempel. En Linux-basert skjerm leveres med OpenSSL 3.0.8. CVE-2023-0464 beskriver overdrevent ressursbruk ved verifisering av X.509-sertifikatkjeder som inneholder policy constraints. Policybehandling er slått av som standard, og programvaren i skjermen slår den aldri på. Leverandøren sender en illustrerende OpenVEX-erklæring:

{
  "@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."
    }
  ]
}

Produser SBOM-er på en repeterbar måte

Hvordan du bygger	Realistisk måte å produsere SBOM-en på
Programvare bygget i CI	Generer SBOM-en i bygget som produserer den leverte programvaren, og oppbevar den sammen med utgivelsen
Yocto-basert innebygd Linux	Yoctos egne SPDX-utdata (create-spdx), sjekket for hva de utelater, eller en registrering av Yocto-bygget
Bare-metal-fastvare fra modellbaserte verktøy	Et generatorbibliotek eller verktøy, aldri et tekstredigeringsprogram, vedlikeholdt med hver utgivelse og validert før sending
Tredjeparts binærfiler du integrerer	Be din egen leverandør om SBOM-en; binæranalyse som erstatning til den kommer

Uansett vei: valider filen før du sender den. Sjekklisten for SBOM-kvalitet lister validatorene kunden din sannsynligvis kjører, CycloneDX vs SPDX hjelper med formatet, og standardisering av SBOM-generering dekker hvordan du gjør den lik på tvers av team.

Hvor CRACI passer inn

For leverandører som bygger på GitHub Actions, erstatter CRACI de GitHub-hostede runnerne og registrerer en SBOM fra hvert bygg, så hver levert versjon allerede har en.

• SBOM-en lister det bygget faktisk trakk inn, inkludert transitive avhengigheter, med en package URL per pakke og den deklarerte lisensen til hver komponent.
• Hver jobbs SBOM har en fullstendighetsstatus, så du vet hva du sender før du sender det.
• SBOM-er eksporteres som CycloneDX eller SPDX, og CRACI støtter VEX.
• Overvåkede SBOM-er vurderes på nytt når nye sårbarheter publiseres, og byggehistorikken viser hvilke bygg som inneholdt en sårbar avhengighet, innenfor oppbevaringstiden din.
• Yocto-bygg kjører på CRACI-runnere og er dokumentert.
• SBOM-er fra tredjeparter kan legges til, så komponenter du kjøper inn, overvåkes sammen med dine egne bygg.

Når CRACI ikke er svaret

• Du har ingen CI, eller du bygger på GitLab, Jenkins eller en byggeserver. CRACI støtter bare GitHub Actions i dag; andre CI-systemer er på veikartet.
• Fastvaren din genereres fra modellbaserte verktøy uten pakkehenting. En byggeregistrering tilfører lite der.
• Du må hoste SBOM-er for mange OEM-er i en delingsportal, eller signere SBOM-er. CRACI tilbyr ingen av delene.
• Byggene dine må kjøre på din egen infrastruktur. Kundehostede runnere er på veikartet.
• Kunden din vil ha bevis for organisasjonens sikkerhetsstyring, som et ISO 27001-sertifikat eller svar på et NIS2-spørreskjema. En SBOM er bevis for en del av det, ikke en sertifisering. CRACIs eget ISO 27001-sertifikat dekker CRACIs tjeneste, ikke din.

SBOM-er for leverandører: ofte stilte spørsmål

Kunden min, en OEM, har bedt om en SBOM. Er jeg pålagt å levere en?

Ofte er det kontrakten som krever det, ikke loven. Bringer du selv en komponent med digitale elementer i omsetning på EU-markedet, krever Cyber Resilience Act din egen SBOM. Ellers er plikten OEM-ens, som sender den videre til deg gjennom aktsomhet og leveringsavtalen.

Gjelder CRA for komponenter jeg selger til en produsent?

Bringer du komponenten i omsetning separat på EU-markedet, ja: artikkel 3(1) omfatter programvare- eller maskinvarekomponenter som bringes i omsetning separat. Når den bare kommer på markedet inne i OEM-ens produkt, er OEM-en produsenten og må utvise aktsomhet med komponenten din (artikkel 13(5)). Komponenter til typegodkjente kjøretøy er utenfor CRA (artikkel 2(2)(c)).

Krever UN R155 eller ISO/SAE 21434 en SBOM?

Nei. R155 nevner aldri en SBOM; den krever at kjøretøyprodusenten håndterer leverandørrelaterte risikoer. ISO/SAE 21434 organiserer cybersikkerhetsarbeidet med leverandører gjennom interface agreements. I bilindustrien kommer SBOM-er som et kontraktskrav.

Hvilket format og hvilke felt vil en OEM forvente?

Vanligvis CycloneDX eller SPDX i JSON eller XML, i tråd med CISA 2026 Minimum Elements eller BSI TR-03183-2: forfatter og tidsstempel, og per komponent navn, versjon, produsent, package URL eller CPE, lisens og hash, med transitive avhengigheter.

Hvor ofte må jeg sende en oppdatert SBOM?

For hver programvareversjon du leverer, hver gang du retter en feil, og med en VEX-erklæring eller advisory når du har vurdert en sårbarhet. Avtal utløseren i kontrakten.

Vil deling av en SBOM avsløre våre immaterielle verdier?

Nei. En SBOM lister komponentnavn, versjoner, produsenter, lisenser, hasher og relasjoner, ikke kildekode, algoritmer eller kalibreringsdata. Del den under en NDA eller leveringsavtalen, med bruk begrenset til sårbarhetshåndtering og samsvar. CRA krever ikke at den gjøres offentlig.

Hva er VEX, og vil kunden min be om det?

VEX sier om et produkt er berørt av en sårbarhet: not_affected, affected, fixed eller under_investigation, med en begrunnelse for not_affected. Regn med å bli bedt om en etter neste mye omtalte sårbarhet i en komponent du leverer.

ECU-fastvaren vår har ingen åpen kildekode. Hvordan ser SBOM-en vår ut?

Kort og ærlig: den proprietære applikasjonen, bootloaderen, eventuelle biblioteker eller kalibrering fra halvlederleverandøren, og eventuell åpen kildekode som et kryptografibibliotek, hver med dine egne identifikatorer, pluss de kjente ukjente. Ikke fyll den opp.