En softwarekomponentliste, på engelsk SBOM, er en fortegnelse over de komponenter, et softwareprodukt er bygget af. I en leverandøraudit er listen et brugbart bevis, fordi den kan prøves. Spørg til en bestemt komponent, og se, om leverandøren kan svare hurtigt og præcist for netop jeres version. Listen viser til gengæld ikke i sig selv, at sårbarhederne bliver rettet.
Artiklen handler om listen som bevis hos køberen. Hvad fabrikanten skal kunne vise om listen, er et andet emne.
Det, forordningen kræver, og hvem der får listen
Når forordningen gælder fuldt ud fra 11. december 2027, er listen en pligt for fabrikanten af et produkt med digitale elementer. Den skal være i et almindeligt anvendt, maskinlæsbart format og som minimum omfatte de vigtigste produktafhængigheder (bilag I, del II, nr. 1). Listen hører til den tekniske dokumentation, og markedsovervågningsmyndigheden kan få den efter en begrundet anmodning (bilag VII).
Kunderne har ikke krav på listen. Fabrikanten bestemmer selv, om brugerne får den, og skal i så fald oplyse, hvor den findes (bilag II, nr. 9). Ifølge betragtning 77 bør fabrikanten heller ikke være forpligtet til at offentliggøre den. Hvordan fordelingen mellem myndighed, kunder og offentlighed ser ud set fra fabrikanten, står i artiklen om, hvem der skal have komponentlisten.
Vil I have listen, må I altså aftale det. Det kan ske nu, også for produkter fra før 2027.
Hvor mange får listen i dag
ENISA spurgte sidst i 2025 organisationer om deres brug af komponentlister. Der kom 334 svar, og de fleste var fra store organisationer, så tallene beskriver dem, der svarede, og ikke markedet. Omkring fire ud af ti svarede, at de aldrig får en liste fra leverandører af standardsoftware, og lige så mange, at det sker sjældent. Hver tiende havde gjort listen obligatorisk i leverandørkontrakterne.
Det er en grund til at stille kravet tidligt. En leverandør, der ikke har listen klar, skal have tid til at lave den.
Det, listen kan bevise
Listen er kun et bevis, hvis den passer til det, der kører hos jer. Det er praksis og ikke krav fra forordningen at prøve den sådan, men prøven er enkel.
- Versionen. Bed om listen for den version, I bruger, og kontrollér, at versionsnummeret svarer til det, der er installeret.
- Datoen. Se, hvornår listen er lavet. En liste fra en tidligere version siger lidt om den nuværende.
- Prøvespørgsmålet. Vælg en komponent, der har været omtalt for en alvorlig sårbarhed, og spørg, om den indgår i jeres version, og i givet fald hvilken udgave. Tænkt eksempel: I spørger til et udbredt bibliotek til logning. Et godt svar kommer med version, berørte moduler og status på rettelsen. Et svagt svar er, at leverandøren vil undersøge det.
- Ejeren. Spørg, hvem der holder listen ajour, og hvordan en ny version af produktet giver en ny liste.
Hvor hurtigt og præcist svaret kommer, siger noget om leverandørens sårbarhedshåndtering. Hvordan den kontrolleres i sin helhed, står under sårbarhedshåndtering og opdateringer hos leverandøren.
Det, listen ikke kan bevise
En liste, der kun når de vigtigste afhængigheder, viser ikke komponenterne længere nede. ENISA peger på, at dybden afgør, om de indirekte afhængigheder kan vurderes. En sårbarhed i et bibliotek, som et andet bibliotek bruger, kan derfor mangle på en liste, der ellers opfylder minimum. Forskellen er forklaret i artiklen om, hvorfor en liste i øverste niveau ofte er for lidt.
Listen viser heller ikke, at nogen holder øje med den. Bed derfor om at se, hvordan leverandøren sammenholder listen med kendte sårbarheder, og hvad der skete ved den seneste alvorlige sag.
Endelig dækker listen kun produktet. Er leverandøren en driftsleverandør eller en cloudtjeneste uden produkt hos jer, er der måske slet ingen liste. Spørg da til, hvordan leverandøren holder styr på de komponenter, tjenesten bygger på.
Når leverandøren ikke vil udlevere listen
Nogle leverandører vil ikke give listen fra sig, fordi den viser, hvad produktet er bygget af. Et kompromis er, at listen vises på et møde, eller at leverandøren svarer på konkrete spørgsmål om komponenter inden for en aftalt frist. Andre former for indsigt uden kopi er beskrevet under leverandøren vil ikke udlevere dokumentation.
Hvad det kræver, og hvad det koster at lade være
Det kræver et krav i aftalen om enten listen eller svar på komponentspørgsmål, og en fast prøve i auditten. Det kræver også en hos jer, der kan læse et maskinlæsbart format eller få det læst.
Uden listen eller retten til at spørge må I vente på leverandørens egen melding, når en udbredt komponent får en alvorlig sårbarhed. Så ved I ikke, om tavshed betyder, at I ikke er berørt.
Det skal I lade være med
- At tage en liste uden versionsnummer som bevis · den skal passe til det, der kører hos jer.
- At regne en liste i øverste niveau for fuldstændig · de indirekte afhængigheder kan mangle.
- At henvise til forordningen, når I beder om listen · kunderne har ikke krav på den, så aftal det.
Det skal auditten kunne vise
- ☐ Aftalens krav om komponentliste eller svar på komponentspørgsmål.
- ☐ En liste, hvis version svarer til den installerede.
- ☐ Et prøvespørgsmål om en komponent med svar og svartid.
- ☐ Hvem der holder listen ajour hos leverandøren.
- ☐ Hvordan listen sammenholdes med kendte sårbarheder.
Kilder
- Forordning (EU) 2024/2847 (Cyber Resilience Act), artikel 3, nr. 39, artikel 71, betragtning 77, bilag I, del II, nr. 1, bilag II, nr. 9, og bilag VII, nr. 2 og 8, læst 13. november 2026.
- ENISA, SBOM Adoption State of Play 2026. Survey Results and Analysis, juni 2026, afsnit 2.1, 2.4.2, 2.4.3 og 2.4.7, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Vælg den vigtigste softwareleverance, og bed om komponentlisten for den version, I kører.
Læs også: Produkter med digitale elementer · Leverandøren vil ikke udlevere dokumentation
→ Kontakt · Tlf. 70 13 63 23 · Leverandøraudit hos Nielco IT
