Fra 11. december 2027 skal fabrikanten af et softwareprodukt lave en maskinlæsbar softwarekomponentliste i et udbredt format, som mindst omfatter de vigtigste afhængigheder. Kilden er bilag I, del II, nr. 1, der hører til sårbarhedshåndteringen, som gælder i hele supportperioden.
Den danske udgave af forordningen kalder en SBOM for en softwarekomponentliste. Denne artikel gennemgår, hvad kravet indeholder, og hvordan hver del kan efterprøves. Format og dybde berøres kun kort. De har deres egne artikler.
Hvad lovteksten siger
Artikel 3, nr. 39, definerer softwarekomponentlisten som en formel fortegnelse med nærmere oplysninger om og forsyningskæderelationer for de komponenter, der indgår i softwareelementerne i et produkt med digitale elementer.
Bilag I, del II, nr. 1, kræver, at fabrikanten identificerer og dokumenterer sårbarheder og komponenter i produktet, herunder ved at udarbejde en softwarekomponentliste i et almindeligt anvendt og maskinlæsbart format, der som minimum dækker de vigtigste produktafhængigheder. Den engelske udgave siger “top-level dependencies”, og i praksis læses det danske udtryk som det øverste niveau af afhængigheder. Den læsning er en tolkning.
Listen nævnes også i bilag VII. Efter nr. 2, litra b, skal beskrivelsen af sårbarhedshåndteringsprocesserne i den tekniske dokumentation omfatte softwarekomponentlisten. Efter nr. 8 skal listen udleveres, når en markedsovervågningsmyndighed beder om den med en begrundelse, og det er nødvendigt for kontrollen.
Del II gælder uanset risikovurderingen og i hele supportperioden, skriver Kommissionen i sin FAQ. Det adskiller listen fra kravene i del I, der kan begrundes væk, hvis de ikke er relevante.
ENISA’s seks pligter
ENISA har i rapporten “SBOM Adoption State of Play 2026” sammenfattet fabrikantens pligter i seks punkter. Gengivet på dansk:
- En liste for hvert produkt, der bringes i omsætning.
- Et almindeligt anvendt og maskinlæsbart format.
- Som minimum de øverste niveauers afhængigheder.
- Listen holdes ajour i hele produktets livscyklus.
- Listen indgår i den tekniske dokumentation og udleveres til markedsovervågningen efter anmodning. Der er ingen pligt til at offentliggøre den.
- Listen indgår i sårbarhedshåndteringen og understøtter identifikation og registrering af sårbarheder og komponenter.
Et forbehold hører med. Det er ENISA’s sammenfatning, og rapporten siger selv, at den ikke tilslutter sig nogen bestemt fortolkning af en retlig pligt. Punkt 4 står ikke ordret i bilag I. ENISA læser det sådan ud fra pligten til at holde den tekniske dokumentation løbende ajour i supportperioden (artikel 31, stk. 2) og pligten til systematisk dokumentation af sårbarheder (artikel 13, stk. 7). Det er en rimelig læsning, men det er en læsning.
Sådan prøves hvert punkt
En gennemgang kan bruge de seks punkter som tjekliste. Fremgangsmåden nedenfor er praksis og ikke noget, forordningen foreskriver.
Liste pr. produkt. Findes der en liste for hvert produkt, I bringer i omsætning? Og for hvilken version? En liste, der ikke kan knyttes til en bestemt version, er svær at bruge som bevis.
Format. Er listen maskinlæsbar, og er formatet almindeligt anvendt? Forordningen nævner ingen formater. CycloneDX og SPDX er de to, der oftest nævnes, og begge er udgivet som standarder hos henholdsvis Ecma International og ISO/IEC. Kommissionen kan fastsætte format og elementer ved en gennemførelsesretsakt efter artikel 13, stk. 24. Vi har ikke set, at det er sket (november 2026).
Dybde. Dækker listen som minimum de vigtigste produktafhængigheder? Gennemgangen sammenholder listen med projektets egne afhængighedsfiler og ser, om de direkte afhængigheder er med.
Ajourføring. Svarer listen til den kode, der faktisk er frigivet? En almindelig prøve er at bygge den frigivne version igen eller undersøge den leverede pakke og sammenligne komponenterne med listen.
Dokumentation og udlevering. Ligger listen i den tekniske dokumentation, og kan den findes frem, hvis myndigheden spørger? Artikel 13, stk. 13, kræver, at den gemmes i ti år fra omsætningen eller hele supportperioden, når den varer længst.
Sårbarhedshåndtering. Bruges listen til noget? Gennemgangen leder efter sporet fra listen til en overvågning af sårbarheder og videre til vurderinger af fund. En liste, der ligger i en mappe og aldrig læses, opfylder ordlyden dårligt, fordi kravet står som en del af det at identificere og dokumentere sårbarheder.
Ingen standard at læne sig op ad endnu
EU-Tidende bragte, så vidt vi kunne se i november 2026, endnu ingen henvisning til en harmoniseret CRA-standard. Der er derfor ingen formodning om overensstemmelse for listens indhold. Den tyske retningslinje BSI TR-03183-2 giver en detaljeret målestok, men den er ikke bindende og giver ingen formodning.
Hvad det kræver, og hvad det koster at lade være
Det kræver, at listen bliver lavet automatisk som en del af byggeprocessen for hver version, at den gemmes sammen med versionen, og at den faktisk bruges i sårbarhedshåndteringen.
Uden en liste kan I ikke svare hurtigt, når en ny sårbarhed i en udbredt komponent bliver offentlig. Og I kan ikke vise myndigheden, at kravet i del II, nr. 1, er opfyldt for den version, der ligger hos kunderne.
Det skal I lade være med
- At lave listen én gang og lade den ligge · den skal passe til den frigivne kode.
- At gengive ENISA’s seks punkter som lovens ordlyd · det er en sammenfatning.
- At offentliggøre listen i den tro, at loven kræver det · det gør den ikke.
Det skal auditten kunne vise
- ☐ En softwarekomponentliste til hver version, I har bragt på markedet.
- ☐ Et maskinlæsbart, almindeligt anvendt format.
- ☐ Dækning af mindst de vigtigste produktafhængigheder.
- ☐ Overensstemmelse mellem listen og den leverede kode.
- ☐ Listen beskrevet som del af sårbarhedshåndteringen, jf. bilag VII, nr. 2, litra b.
- ☐ Spor fra listen til overvågning og vurdering af sårbarheder.
Kilder
- Forordning (EU) 2024/2847, dansk udgave, artikel 3, nr. 39, artikel 13, stk. 7, 13 og 24, artikel 31, stk. 2, bilag I, del II, nr. 1, og bilag VII, nr. 2, litra b, og nr. 8, læst 13. november 2026.
- ENISA, SBOM Adoption State of Play 2026, afsnit 1.2, læst 13. november 2026.
- Kommissionens tjenestegrene, FAQs on the Cyber Resilience Act, version 1.4, afsnit 4.1.3, læst 13. november 2026.
- Europa-Kommissionen, Cyber Resilience Act, standardisering, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Find komponentlisten for den version, der senest gik ud til kunderne, og sammenlign den med den pakke, de fik.
Læs også: Skal kunderne have komponentlisten? · Den tyske retningslinje TR-03183-2 som målestok
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
