Din kunde vil have en SBOM: en guide til komponent- og softwareleverandører

Denne guide er til leverandører i en produktionsforsyningskæde: ECU'er, displays, controllere, gateways, drev, indlejrede Linux-stakke og firmwaremoduler. Sælger du software, og har en kunde sendt en enkeltstående anmodning, så start med sådan svarer du på en kundes SBOM-anmodning, som dækker det tilfælde.

Hvorfor OEM'er spørger nu

En OEM's SBOM-anmodning er som regel OEM'ens regulering, der banker på din dør via en kontrakt. Hvilken regulering det er, afgør, hvad OEM'en skal have, og hvor meget af det der sendes videre til dig.

Cyber Resilience Act

Efter Cyber Resilience Act, forordning (EU) 2024/2847, omfatter et produkt med digitale elementer også software- eller hardwarekomponenter, der bringes i omsætning separat (artikel 3, nr. 1). En komponent, du selv sælger i EU, er et produkt i sig selv, og du er dens producent med din egen SBOM-forpligtelse: Bilag I, del II, punkt 1, kræver en SBOM i et almindeligt anvendt og maskinlæsbart format, der som minimum dækker produkternes afhængigheder på øverste niveau. Er komponenten beregnet til at blive integreret i andre produkter, skal din vejledning også give integratoren de oplysninger, der er nødvendige for at overholde de væsentlige krav (bilag II, punkt 8, litra f)).

OEM'en har også forpligtelser, der når dig. Den skal udvise rettidig omhu, når den integrerer komponenter fra tredjeparter (artikel 13, stk. 5), og når den finder en sårbarhed i en komponent, den har integreret, skal den rapportere den til den person eller enhed, der fremstiller eller vedligeholder komponenten (artikel 13, stk. 6). Kommissionens CRA-vejledning fra juli 2026 siger, at dokumentation for rettidig omhu kan bestå af dokumentation fra komponentens producent, og nævner ikke SBOM'er; i praksis er en SBOM ofte den dokumentation, OEM'er beder om. Rapporteringsforpligtelserne gælder fra den 11. september 2026, og forordningen gælder fuldt ud fra den 11. december 2027. Reservedele fremstillet efter samme specifikation som de komponenter, de erstatter, er undtaget (artikel 2, stk. 6). Resten af forordningen finder du i hvad CRA er og CRA-guiden.

Køretøjer

CRA gælder ikke for produkter, der er omfattet af forordning (EU) 2019/2144, forordningen om typegodkendelse af køretøjer (artikel 2, stk. 2, litra c)). Komponenter til typegodkendte køretøjer kommer i stedet på markedet under køretøjsreglerne, og de nævner aldrig en SBOM.

• UN Regulation No. 155 (cybersikkerhed) kræver, at producenten indsamler og verificerer oplysninger gennem forsyningskæden for at vise, at leverandørrelaterede risici er identificeret og styres (5.1.1(a)), viser, hvordan dens ledelsessystem for cybersikkerhed vil styre afhængigheder af kontraherede leverandører, tjenesteudbydere eller producentens underorganisationer (7.2.2.5), og identificerer og styrer leverandørrelaterede risici for den køretøjstype, der godkendes (7.3.2).
• UN Regulation No. 156 (softwareopdateringer) kræver, at alle oprindelige og opdaterede softwareversioner kan identificeres entydigt (7.1.1.2), og at der for hvert RX Software Identification Number (RXSWIN) findes et register, der kan revideres og beskriver al den software, der er relevant for RXSWIN'et (7.1.2.3).
• ISO/SAE 21434 organiserer cybersikkerhedsarbejdet mellem OEM og leverandør som fordelte aktiviteter, hvor fordelingen aftales i en cybersecurity interface agreement.
• Auto-ISAC SBOM Informational Report (februar 2025) er branchens egen vejledning.

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

Industriel automation

IEC 62443-4-1 gælder for leverandører af produkter til industrielle automations- og kontrolsystemer. Den nævner ikke SBOM'er, men praksis 6, håndtering af sikkerhedsrelaterede problemer (DM-1 til DM-6), og praksis 7, styring af sikkerhedsopdateringer (SUM-1 til SUM-5, herunder SUM-3, "Dependent component or operating system security update documentation"), er der, hvor en SBOM tjener som dokumentation.

Maskiner

Forordning (EU) 2023/1230 om maskiner gælder fra den 20. januar 2027 og nævner ikke SBOM'er. Dens væsentlige krav om beskyttelse mod forvanskning (bilag III, 1.1.9) kræver, at software, der er afgørende for overensstemmelsen, identificeres og beskyttes, at maskinen kan identificere den software, der er installeret på den og nødvendig for, at den kan fungere sikkert, og at der indsamles dokumentation for indgreb i den software. Maskiner med digitale elementer er også omfattet af CRA, i modsætning til typegodkendte køretøjer, og derfor beder maskinproducenter nu deres leverandører om SBOM'er. Se CRACI for maskinproducenter og industriel IoT.

NIS2 og certificerede kunder

Leverer du til væsentlige eller vigtige enheder, for eksempel inden for halvledere, kræver NIS2 artikel 21, stk. 2, litra d), at din kunde tager hånd om sikkerheden i forsyningskæden. Den nævner ikke SBOM'er. Kunderne omsætter den til spørgeskemaer, og ISO/IEC 27001 Annex A-kontrollerne 5.21 og 8.8 er der, hvor en SBOM tjener som dokumentation. Se SBOM'er som dokumentation for ISO 27001, SOC 2 og NIS2.

Ordningerne side om side

Ordning	Gælder for	Nævner en SBOM?	Hvad når leverandøren
Cyber Resilience Act	Produkter med digitale elementer på EU-markedet, herunder komponenter, der sælges separat	Ja, bilag I, del II, punkt 1	Direkte, hvis du bringer komponenten i omsætning; via OEM'ens rettidige omhu (art. 13, stk. 5) og sårbarhedsrapporter (art. 13, stk. 6)
UN R155 og R156	Køretøjsproducenter, der søger typegodkendelse	Nej	Styring af leverandørrisiko (R155 7.2.2.5, 7.3.2) og identifikation af software (R156) via kontrakter
ISO/SAE 21434	Cybersikkerhedsudvikling af vejkøretøjer, OEM'er og leverandører	Ikke i den offentlige beskrivelse	Fordelte aktiviteter og en cybersecurity interface agreement
IEC 62443-4-1	Leverandører af produkter til industrielle automations- og kontrolsystemer	Nej	Direkte, hvis du er produktleverandøren; SBOM'er tjener som dokumentation for DM og SUM
Forordningen om maskiner	Maskiner og relaterede produkter på EU-markedet	Nej	Identifikation og beskyttelse af software (bilag III, 1.1.9); CRA gælder ved siden af
NIS2	Væsentlige og vigtige enheder	Nej	Spørgeskemaer om sikkerhed i forsyningskæden og kontraktvilkår (art. 21, stk. 2, litra d), og stk. 3)

Uanset vejen har kunden brug for det samme: en præcis SBOM for hver softwareversion, du leverer.

Hvad OEM'er typisk beder om

Kravene varierer fra OEM til OEM, men de samler sig om den samme liste. Tjek din SBOM mod den før første levering.

Krav	Typisk forventning
Format	CycloneDX eller SPDX, JSON eller XML, med en laveste specifikationsversion. BSI TR-03183-2 kræver CycloneDX 1.6 eller nyere eller SPDX 3.0.1 eller nyere.
Felter	I tråd med CISA 2026 Minimum Elements eller BSI TR-03183-2: forfatter, tidsstempel og for hver komponent navn, version, producent og identifikatorer
Identifikatorer	En package URL, hvor økosystemet har en, ellers en CPE, så komponenterne kan matches mod sårbarhedsdatabaser
Licenser	SPDX-licensidentifikatorer. OEM'ens licensspecialist læser dem for at vurdere copyleft og anden licensrisiko.
Hashes	En hash af hver leveret binærfil, så OEM'en kan bekræfte, at SBOM'en beskriver den fil, den har modtaget. BSI beder om SHA-512.
Dybde	Transitive afhængigheder, ikke kun øverste niveau
Granularitet	Én SBOM pr. leveret softwareversion eller varenummer
Levering og svar	En leveringskanal og svartider for spørgsmål om sårbarheder

Mange OEM'er tjekker disse punkter automatisk ved modtagelsen. Se tjeklisten for SBOM-kvalitet for, hvad din kunde vil tjekke, og hvilke værktøjer de bruger, og SBOM-eksempler for, hvordan felterne ser ud i en fil.

Din SBOM, når der er lidt eller ingen open source

En bare-metal-ECU eller -controller med proprietær firmware fra modelbaseret kodegenerering har en ærlig SBOM, der kan være kort: den proprietære applikation, din bootloader, en chipleverandørs biblioteker eller kalibrering og eventuel open source som et kryptografibibliotek. Det er et gyldigt svar. Reglerne:

• Opfør proprietære komponenter med dine egne identifikatorer: navn, version og dig selv som producent.
• Angiv de kendte ukendte, for eksempel et leverandørbibliotek, hvis indhold du ikke kan se.
• Pust aldrig SBOM'en op for at virke grundig, og udelad aldrig et open source-bibliotek, fordi det er lille.

For Linux-baserede displays og gateways gælder det modsatte: hundredvis eller tusindvis af komponenter, herunder kernen, bootloaderen og basissystemets pakker (se forbundne enheder). En SBOM, der kun viser din applikation og nogle få biblioteker, er det første, et modtagende team markerer. Bygger du med Yocto, så se hvorfor scannere overser det, der er i Yocto-builds.

Kontrakter: hvad du skal aftale før første levering

Vilkår	Hvorfor det betyder noget
Omfattede produkter og softwareversioner	Så ingen senere diskuterer, om en variant eller en servicerelease skulle have haft en SBOM
Format og specifikationsversion	Deres modtagepipeline afviser måske alt andet
Felter og det rammeværk, de følger	"BSI TR-03183-2 v2.1.0" eller "CISA 2026 Minimum Elements" kan testes; "en komplet SBOM" kan ikke
Hvad der udløser en levering	Hver release, hver softwareversion leveret til OEM'en og hver rettelse
Leveringskanal	OEM'ens leverandørportal, sikker filudveksling eller e-mail under NDA
Fortrolighed	En NDA eller den eksisterende leveranceaftale, der nævner SBOM'en som fortrolig information
Begrænsninger i brugen	Kun sårbarhedsstyring og compliance, ingen videregivelse uden samtykke
Underretning om sårbarheder, begge veje	OEM'en rapporterer sårbarheder, den finder i din komponent (CRA art. 13, stk. 6); du underretter den om dine
Forventninger til VEX	Hvilket format, og hvor hurtigt du vurderer en ny CVE
Opbevaring	Hvor længe du gemmer SBOM'en for hver version, afstemt efter produktets supportperiode
Nøjagtighed og kendte ukendte	En ærlig klausul om, hvad SBOM'en kan og ikke kan dække, beskytter begge parter

CISA's SBOM Sharing Primer beskriver bilindustrien på samme måde: SBOM-anmodninger indgår i de almindelige aftaler om informationsudveksling, for eksempel en fortrolighedsaftale, en cybersecurity interface agreement eller en development interface agreement.

Del uden at lække IP

En SBOM er ikke din kildekode. Den opfører komponenternes navne, versioner, producenter, licenser, hashes og relationer. Den indeholder ikke din kode, dine algoritmer, dine kalibreringsdata eller dit design.

• CRA forpligter ikke producenter til at offentliggøre SBOM'en (betragtning 77). Den udleveres til en markedsovervågningsmyndighed på dennes begrundede anmodning (bilag VII, punkt 8).
• CISA's vejledning om deling beskriver de sædvanlige kanaler for proprietær software: e-mail under en NDA, kundens leverandørportal eller en sikker dokumentudveksling eller en egen portal med adgangskontrol, hvor kontrakter regulerer fortrolighed og adgang.
• Praktiske muligheder: én fuld SBOM pr. OEM under kontrakt; identifikatorer for proprietære dele, der ikke afslører interne projektnavne; og et separat VEX-dokument, så du kan opdatere en sårbarheds status uden at sende SBOM'en igen.

Hvor ofte, og hvad der sker efter leveringen

• En ny SBOM for hver softwareversion, du leverer, under den samme identifikator, som OEM'en flasher eller registrerer. For køretøjer hænger det sammen med R156's identifikation af software.
• En rettet SBOM, når du finder en fejl i en, du har sendt.
• En VEX-erklæring eller en advisory, når du har vurderet en sårbarhed.

Opfølgningsspørgsmålet, "er I berørt af CVE-X?", kommer med den næste store sårbarhed. Vær klar til at besvare det pr. leveret version, hvilket kun er muligt, hvis du har gemt SBOM'en for hver af dem.

VEX: hvad din kunde vil forvente som det næste

Et VEX-dokument siger, om et produkt er berørt af en sårbarhed. CISA's Minimum Requirements for VEX (april 2023) definerer fire statusser: not_affected, affected, fixed og under_investigation. En not_affected-erklæring bør angive én af fem begrundelser, eller ellers en konsekvenserklæring (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 kræver en handlingserklæring (action statement): hvad kunden skal gøre. VEX findes i tre formater: VEX-profilen i CSAF 2.0, CycloneDX VEX og OpenVEX. Yoctos SPDX 3.0-output indeholder som standard VEX-data (variablen SPDX_INCLUDE_VEX).

Eksempel. Et Linux-baseret display leveres med OpenSSL 3.0.8. CVE-2023-0464 beskriver for stort ressourceforbrug ved verificering af X.509-certifikatkæder, der indeholder policy constraints. Policy-behandling er som standard slået fra, og displayets software slår den aldrig til. Leverandøren sender en illustrativ 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."
    }
  ]
}

Sådan producerer du SBOM'er gentageligt

Sådan bygger du	Realistisk måde at producere SBOM'en på
Software bygget i CI	Generér SBOM'en i det build, der producerer den leverede software, og gem den sammen med releasen
Yocto-baseret indlejret Linux	Yoctos eget SPDX-output (create-spdx), tjekket for hvad det udelader, eller en registrering af Yocto-buildet
Bare-metal-firmware fra modelbaserede værktøjer	Et generatorbibliotek eller -værktøj, aldrig en teksteditor, vedligeholdt med hver release og valideret før afsendelse
Tredjeparts-binærfiler, du integrerer	Bed din egen leverandør om dens SBOM; binær analyse som midlertidig løsning, indtil den kommer

Uanset vejen: Validér filen, før du sender den. Tjeklisten for SBOM-kvalitet viser de validatorer, din kunde sandsynligvis kører, CycloneDX vs SPDX hjælper med formatet, og standardisering af SBOM-generering handler om at gøre det ens på tværs af teams.

Hvor CRACI passer ind

For leverandører, der bygger på GitHub Actions, erstatter CRACI de GitHub-hostede runners og registrerer en SBOM fra hvert build, så hver leveret version allerede har en.

• SBOM'en viser, hvad buildet faktisk hentede ind, inklusive transitive afhængigheder, med en package URL pr. pakke og den deklarerede licens for hver komponent.
• Hvert jobs SBOM har en fuldstændighedsstatus, så du ved, hvad du sender, før du sender det.
• SBOM'er eksporteres som CycloneDX eller SPDX, og CRACI understøtter VEX.
• Overvågede SBOM'er genvurderes, efterhånden som nye sårbarheder offentliggøres, og build-historikken viser, hvilke builds der indeholdt en sårbar afhængighed, inden for din opbevaringsperiode.
• Yocto-builds kører på CRACI-runners og er dokumenteret.
• Tredjeparts-SBOM'er kan tilføjes, så komponenter, du køber ind, overvåges side om side med dine egne builds.

Når CRACI ikke er svaret

• Du har ingen CI, eller du bygger på GitLab, Jenkins eller en build-server. CRACI understøtter kun GitHub Actions i dag; andre CI-systemer er på roadmappen.
• Din firmware genereres af modelbaserede værktøjer uden pakkehentning. Der tilføjer en build-registrering ikke meget.
• Du skal hoste SBOM'er for mange OEM'er i en delingsportal eller signere SBOM'er. CRACI tilbyder ingen af delene.
• Dine builds skal køre på din egen infrastruktur. Kundehostede runners er på roadmappen.
• Din kunde vil have bevis for din organisations sikkerhedsstyring, for eksempel et ISO 27001-certifikat eller svar på et NIS2-spørgeskema. En SBOM er dokumentation for en del af det, ikke en certificering. CRACI's eget ISO 27001-certifikat dækker CRACI's tjeneste, ikke din.

SBOM'er for leverandører: ofte stillede spørgsmål

Min kunde, en OEM, har bedt om en SBOM. Er jeg forpligtet til at levere en?

Ofte er det kontrakten, der kræver det, snarere end loven. Bringer du selv en komponent med digitale elementer i omsætning på EU-markedet, kræver Cyber Resilience Act din egen SBOM. Ellers ligger forpligtelsen hos OEM'en, som sender den videre til dig via rettidig omhu og leveranceaftalen.

Gælder CRA for komponenter, jeg sælger til en producent?

Hvis du bringer komponenten i omsætning på EU-markedet separat, ja: Artikel 3, nr. 1, omfatter software- eller hardwarekomponenter, der bringes i omsætning separat. Når den kun kommer på markedet inde i OEM'ens produkt, er OEM'en producenten og skal udvise rettidig omhu med din komponent (artikel 13, stk. 5). Komponenter til typegodkendte køretøjer falder uden for CRA (artikel 2, stk. 2, litra c)).

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

Nej. R155 nævner aldrig en SBOM; den kræver, at køretøjsproducenten styrer leverandørrelaterede risici. ISO/SAE 21434 organiserer cybersikkerhedsarbejdet med leverandører via interface agreements. I bilindustrien kommer SBOM'er som et kontraktkrav.

Hvilket format og hvilke felter vil en OEM forvente?

Som regel CycloneDX eller SPDX i JSON eller XML, i tråd med CISA 2026 Minimum Elements eller BSI TR-03183-2: forfatter og tidsstempel og for hver komponent navn, version, producent, package URL eller CPE, licens og hash, med transitive afhængigheder.

Hvor ofte skal jeg sende en opdateret SBOM?

For hver softwareversion, du leverer, hver gang du retter en fejl, og sammen med en VEX-erklæring eller advisory, når du har vurderet en sårbarhed. Aftal, hvad der udløser en levering, i kontrakten.

Afslører vi vores intellektuelle ejendom ved at dele en SBOM?

Nej. En SBOM opfører komponenternes navne, versioner, producenter, licenser, hashes og relationer, ikke kildekode, algoritmer eller kalibreringsdata. Del den under en NDA eller leveranceaftalen, med brugen begrænset til sårbarhedsstyring og compliance. CRA kræver ikke, at den offentliggøres.

Hvad er VEX, og vil min kunde bede om det?

VEX angiver, om et produkt er berørt af en sårbarhed: not_affected, affected, fixed eller under_investigation, med en begrundelse for not_affected. Regn med at blive bedt om det efter den næste bredt omtalte sårbarhed i en komponent, du leverer.

Vores ECU-firmware har ingen open source. Hvordan ser vores SBOM ud?

Kort og ærlig: den proprietære applikation, bootloaderen, eventuelle biblioteker eller kalibrering fra chipleverandøren og eventuel open source som et kryptografibibliotek, hver med dine egne identifikatorer, plus de kendte ukendte. Pust den ikke op.