En softwarekomponentliste, på engelsk SBOM, fortæller, hvilke biblioteker og andre komponenter et program er bygget af. Bliver der offentliggjort en alvorlig fejl i et bibliotek, mange programmer bruger, kan driften søge i listerne og finde de berørte systemer selv, i stedet for at vente på, at hver leverandør melder sig.
Cyber Resilience Act gør listen til en pligt for fabrikanten fra 11. december 2027, men giver ikke køberen ret til at få den. Driften skal derfor både kunne bruge listerne, når de findes, og klare sig, når de mangler.
Det, forordningen giver, og det, den ikke giver
Forordning 2024/2847 definerer listen som en formel fortegnelse over komponenterne i et produkts software og deres forsyningskæderelationer (artikel 3, nr. 39). Fabrikanten skal lave den i et almindeligt anvendt og maskinlæsbart format, og mindst omfatte de vigtigste produktafhængigheder, jf. bilag I, del II, nr. 1. På engelsk står der “top-level dependencies”, så kravet forstås normalt som listens øverste lag. Det er en tolkning.
Listen hører til fabrikantens tekniske dokumentation. Myndigheden kan bede om den med en begrundelse. Brugerne får den kun, hvis fabrikanten selv vil, og så skal det fremgå af brugeroplysningerne, hvor den findes (bilag II, nr. 9). Pligt til at lægge den frem for alle er der ikke, jf. betragtning 77.
Pligten omfatter de produkter, fabrikanten bringer i omsætning fra og med 11. december 2027. En version fra før den dato er kun omfattet, hvis den bagefter ændres væsentligt (artikel 69, stk. 2). En stor del af det, der kører hos jer i dag, vil derfor aldrig få en liste efter forordningen. Hvad fabrikanten konkret skal kunne dokumentere, står i artiklen om softwarekomponentlisten efter CRA.
Formaterne, driften vil møde
De to udbredte formater til selve listen er CycloneDX og SPDX. CycloneDX er udgivet som standarden ECMA-424, og SPDX er udgivet som ISO/IEC 5962:2021. Forordningen kræver ingen bestemt af dem. Kommissionen kan fastsætte formatet ved en gennemførelsesretsakt, men pr. november 2026 kender vi ingen sådan retsakt.
Status for en sårbarhed hører ikke hjemme i listen efter den tyske retningslinje TR-03183-2. Den skal i stedet stå i en sikkerhedsmeddelelse, fx i CSAF med VEX-profilen. VEX-profilen i CSAF 2.0 opregner fem grunde til at melde et produkt upåvirket, bl.a. at den sårbare kode ikke findes, eller at den ikke ligger i den vej, programmet udføres. Retningslinjen og formaterne er ikke bindende.
For driften betyder det to slags filer pr. produkt: listen, der viser indholdet, og meddelelser, der siger, om en bestemt sårbarhed rammer. Begge skal kunne læses maskinelt, ellers bliver de ikke brugt.
Sådan bruges listen i den daglige drift
Fremgangsmåden herunder er praksis. Forordningen siger intet om den.
Gem hver liste sammen med det system og den version, den hører til, helst i samme register som systemlisten. En liste uden versionsnummer kan ikke bruges, for næste version kan have andre komponenter. Hold listerne op mod nye sårbarhedsmeddelelser ved hjælp af identifikatorer som CPE og purl, og læg resultatet ind i den samme kø som scannerens fund.
Matchningen er det svære led. I ENISA’s undersøgelse fra 2025 svarede næsten to tredjedele, at det var meget eller ret vanskeligt at koble listerne til kendte sårbarheder, bl.a. på grund af falske positiver. Svarene kom især fra store organisationer, så de beskriver dem, der svarede. Regn med, at et match skal vurderes af en tekniker, før det bliver et fund.
Når fabrikanten selv har udsendt en meddelelse om, at produktet ikke er berørt, er den et brugbart bevis for at lukke et match. Skriv meddelelsen ind som begrundelse i undtagelseslisten, så næste gennemgang kan se, hvorfor sagen er lukket. Kommissionens tolkning af, hvornår en sårbarhed i en afhængighed med rette står urettet, er gennemgået under den dokumenterede vurdering af “ikke berørt”.
Grænsen for, hvad listen viser
En liste i øverste niveau viser de komponenter, produktet selv har valgt. Det bibliotek, som et af dem trækker med sig, kan mangle. Ifølge ENISA er det listens dybde, der bestemmer, om afhængigheder længere nede overhovedet kan vurderes. Et tomt søgeresultat i en liste i øverste niveau er altså ikke et bevis for, at systemet er fri for komponenten. Forskellen er forklaret i artiklen om, hvorfor øverste niveau er lovens minimum.
Hvor listen mangler eller er for tynd, kan driften selv læse de installerede pakker og filer på maskinerne med en scanning med login. Den måling er uafhængig af leverandøren og bør findes alligevel. Fremgangsmåden står i sårbarhedsscanning med login.
Det, gennemgangen prøver
En gennemgang kan prøve listerne med en øvelse. Et tænkt eksempel: Gennemgangen vælger en komponent, der for nylig har haft en alvorlig sårbarhed, og beder driften vise, hvilke systemer der indeholder den, og i hvilken version. Svaret viser, om listerne findes, om de passer til de installerede versioner, og om nogen kan søge i dem.
Dernæst sammenligner gennemgangen et par lister med en måling fra de samme maskiner. Afviger komponenternes versioner, er listen forældet. Til sidst ses der på de match, der er lukket som “ikke berørt”, og om der ligger en begrundelse ved hver.
Hvad det kræver, og hvad det koster at lade være
Det kræver et sted at gemme listerne pr. system og version, et værktøj eller et script, der kan læse formaterne, og en tekniker, der vurderer de match, der kommer ud. Det tager tid at få leverandørerne til at levere listerne, så start med de vigtigste systemer.
Uden lister er driften afhængig af leverandørernes egne meldinger, når et udbredt bibliotek får en alvorlig sårbarhed. Tavshed fra en leverandør kan betyde, at systemet ikke er berørt, eller at ingen har kigget.
Det skal I lade være med
- At gemme en liste uden versionsnummer · den passer kun til den version, den er lavet til.
- At læse et tomt søgeresultat som et nej · indirekte afhængigheder kan mangle i listen.
- At lukke match uden begrundelse · fabrikantens meddelelse eller jeres egen vurdering skal stå ved sagen.
- At regne med listen for systemer fra før december 2027 · de er kun omfattet ved væsentlig ændring.
Det skal gennemgangen kunne vise
- ☐ Et register over modtagne komponentlister med system, version og dato.
- ☐ En søgning efter en udvalgt komponent med svar og svartid.
- ☐ Sammenligning af en liste med en måling fra de samme maskiner.
- ☐ Begrundelser for match, der er lukket som ikke berørt.
- ☐ Systemer uden liste, med den måling, der bruges i stedet.
Kilder
- Forordning (EU) 2024/2847 (Cyber Resilience Act), artikel 3, nr. 39, artikel 13, stk. 24, artikel 69, stk. 2, artikel 71, betragtning 77, bilag I, del II, nr. 1, bilag II, nr. 9, og bilag VII, nr. 8, læst 13. november 2026.
- ENISA, SBOM Adoption State of Play 2026, juni 2026, afsnit 2.4.1 og 2.4.3, læst 13. november 2026.
- BSI, TR-03183-2, version 2.1.0, august 2025, afsnit 3.1 og 8.1.14, læst 13. november 2026.
- OASIS, Common Security Advisory Framework Version 2.0, afsnit 3.2.3.5 og 4.5, læst 13. november 2026.
- Ecma International, ECMA-424 og SPDX, Specifications, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Bed leverandøren af jeres vigtigste forretningssystem om komponentlisten for den version, I kører, og prøv at søge i den.
Læs også: Opdateringsniveau · Prioritering af sårbarheder
→ Kontakt · Tlf. 70 13 63 23 · Teknisk sikkerhedsgennemgang hos Nielco IT
