Kort svar: ja. Cyber Resilience Act, forordning (EU) 2024/2847, kræver, at enhver fabrikant af et omfattet produkt med digitale elementer udarbejder en softwarestykliste. Det er et af de otte krav til håndtering af sårbarheder i bilag I, del II, som gælder for ethvert omfattet produkt uden "hvor det er relevant" og uden størrelsestærskel, fra den 11. december 2027.

Det længere svar er tre sætninger i forordningen, og hver af dem afgør et spørgsmål, folk bliver ved med at stille.

Kravet: bilag I, del II, punkt 1

Fabrikanter skal "identificere og dokumentere sårbarheder og komponenter i produkter med digitale elementer, herunder ved at udarbejde en softwarestykliste i et almindeligt anvendt og maskinlæsbart format, der som minimum dækker produkternes afhængigheder på øverste niveau".

Fire ting fastlægges af den sætning.

Den er obligatorisk. SBOM'en er det navngivne middel til at identificere og dokumentere komponenter. Der er ingen vej til punkt 1 uden en.

Formatet er "almindeligt anvendt og maskinlæsbart". Forordningen nævner hverken CycloneDX eller SPDX, og det behøver den ikke: Begge er almindeligt anvendte og maskinlæsbare, og begge opfylder teksten. Et regneark er maskinlæsbart i svag forstand og ikke almindeligt anvendt til formålet; stol ikke på det.

Dybden er "som minimum afhængighederne på øverste niveau". Det er gulvet, ikke anbefalingen. Øverste niveau betyder de pakker, jeres produkt erklærer direkte. Transitive afhængigheder er der, hvor de fleste kendte sårbarheder faktisk sidder, så en SBOM kun med øverste niveau opfylder ordlyden og efterlader halvdelen af punkt 1, identifikationen af sårbarheder, svag. De fleste værktøjer laver alligevel hele grafen.

Den dækker "produkterne", i flertal, pr. produkt. Én SBOM pr. produkt med digitale elementer, pr. version, der påvirker overholdelsen (bilag VII, punkt 1, litra b, beder om versionerne). Én SBOM for hele organisationen opfylder det ikke.

Hvor den hører til: bilag VII, punkt 2, litra b, og punkt 8

SBOM'en er en del af den tekniske dokumentation. Bilag VII, punkt 2, litra b, nævner "softwarestyklisten" blandt de specifikationer for håndtering af sårbarheder, dokumentationen skal indeholde. Det er et dokument, I opbevarer, dateret, sammen med dokumentationen, i ti år eller supportperioden, alt efter hvad der er længst.

Punkt 8 i samme bilag besvarer det spørgsmål, alle stiller derefter: Skal vi offentliggøre den? Nej. SBOM'en udleveres "efter begrundet anmodning fra en markedsovervågningsmyndighed, forudsat at det er nødvendigt for, at myndigheden kan kontrollere overholdelsen af de væsentlige cybersikkerhedskrav i bilag I". Den videregives til en myndighed, på anmodning, med en begrundelse. Intet i forordningen kræver, at den offentliggøres for kunder eller offentligheden, men intet forbyder det heller: Bilag II, punkt 9, siger, at hvis fabrikanten beslutter at stille SBOM'en til rådighed for brugerne, skal brugeroplysningerne angive, hvor den kan findes. En kundes sikkerhedsspørgeskema kan alligevel bede om den.

Hvad det ikke afgør

Formatdetaljer. Kommissionen kan fastsætte SBOM'ens format og elementer ved gennemførelsesretsakt (artikel 13, stk. 24). Indtil da er "almindeligt anvendt og maskinlæsbart" målestokken, og de to åbne formater opfylder den.

Dybde ud over øverste niveau. Forordningen sætter et gulv. Om en myndighed, et bemyndiget organ eller en kunde accepterer kun øverste niveau, er et praktisk spørgsmål med et forudsigeligt svar: Jo dybere SBOM, jo færre spørgsmål.

Hardwarekomponenter. Punkt 1 siger "sårbarheder og komponenter", og SBOM'en er en softwarestykliste. For et hardwareprodukt skal dokumentationen stadig identificere komponenter (bilag VII, punkt 1, litra c, vil have den indvendige opbygning), men kravet om maskinlæsbarhed er formuleret for software.

Hvad I skal gøre

Generer SBOM'en fra buildet, ikke i hånden, i CycloneDX eller SPDX, for hvert produkt og hver version, der er relevant for overholdelsen, og opbevar den sammen med den tekniske dokumentation. Hold genereringen i release-pipelinen, så dokumentationens SBOM er det leverede produkts SBOM og ikke sidste kvartals. Skriv en SBOM-procedure på én side, der siger hvilket værktøj, hvilket format, hvilken dybde, hvor den ligger, og hvem der besvarer en begrundet anmodning; den procedure er et af de fire driftsdokumenter, del II forudsætter, og det er det, en auditor beder om at se før selve SBOM'en.

Og hold sårbarhedssiden for øje: Punkt 1 lyder "identificere og dokumentere sårbarheder og komponenter". SBOM'en er komponenthalvdelen. Sårbarhedshalvdelen er den scanning, der læser den, og i det øjeblik scanningen viser en udnyttet sårbarhed, er artikel 14's 24-timers-ur det næste at tænke på.

Hvad forordningen derefter kræver af jer for hver komponent på den liste, fornøden omhu efter artikel 13(5), indberetning opstrøms efter artikel 13(6) og testen for "kendte udnyttelige sårbarheder" ved udgivelsen, står i ledsageartiklen, efter Kommissionens vejledning.

Kilder

  • Forordning (EU) 2024/2847, bilag I, del II, punkt 1 (citeret); bilag II, punkt 9; bilag VII, punkt 1, litra b, 1, litra c, 2, litra b, og 8; artikel 13, stk. 24, om gennemførelsesretsakten for SBOM-formatet; artikel 71, stk. 2, for datoerne. Læst i EU-Tidende-teksten på EUR-Lex den 11. september 2026.

Dette er ikke juridisk rådgivning. De tre sætninger ovenfor er korte nok til at læse i selve forordningen, og det er der, en beslutning om jeres produkt bør hvile.