BSI’s tekniske retningslinje TR-03183-2 kræver en særskilt softwarekomponentliste for hver softwareversion. Forordningen siger det ikke med de ord. Den kræver en teknisk dokumentation, som nævner de versioner, der har betydning for overholdelsen, holdes ved lige og gemmes i ti år eller mere.
For et softwarehus, der frigiver hver uge, er spørgsmålet praktisk. Hvad skal gemmes, og hvor meget? Denne artikel lægger de to kilder ved siden af hinanden. At forordningen kræver en liste pr. release, er en tolkning, og det markerer vi undervejs.
Den tyske regel
TR-03183-2 siger, at der skal laves en særskilt liste for hver softwareversion. En opdateret liste for en given version laves kun, hvis der kommer yderligere oplysninger om komponenterne, eller hvis fejl i listen rettes. Ændres en komponent, skal den have en ny version.
Reglen er enkel. En ny version giver en ny liste. Samme version giver samme liste, medmindre listen var forkert eller ufuldstændig.
BSI skriver selv, at retningslinjen ikke er bindende og ikke giver formodning om overensstemmelse. Den er en målestok og ikke et krav.
Hvad forordningen kræver
Fire bestemmelser er relevante.
Bilag VII, nr. 1, litra b: dokumentationen skal pege på de softwareversioner, overholdelsen af de væsentlige krav afhænger af.
Bilag VII, nr. 2, litra b: komponentlisten indgår i beskrivelsen af, hvordan sårbarheder håndteres.
Artikel 31, stk. 2: dokumentationen laves, inden produktet kommer på markedet, og holdes derefter løbende opdateret, mindst så længe supportperioden varer.
Artikel 13, stk. 13: dokumentationen gemmes i ti år fra omsætningen, eller i hele supportperioden, hvis den er længere end ti år.
Kommissionens FAQ henviser desuden til Blue Guide, afsnit 4.3, og skriver med henvisning dertil, at dokumentationen ved redesign og nye vurderinger skal dække samtlige versioner af produktet, beskrive ændringerne og forklare, hvordan versionerne kan identificeres. Vi har ikke selv læst Blue Guide og gengiver kun FAQ’ens henvisning.
Hvordan de to hænger sammen
Forordningen kræver en ajourført liste, der hører til dokumentationen, og som kan knyttes til de versioner, der påvirker overholdelsen. Den tyske retningslinje kræver en liste pr. version. Vores tolkning er, at en liste pr. frigivet version er den enkleste måde at opfylde forordningens krav på, fordi den gør det muligt at svare på, hvad en bestemt version hos en kunde indeholder. Men forordningen kræver ikke den form udtrykkeligt.
Når der frigives hver uge
Hyppige frigivelser giver mange lister. ENISA’s undersøgelse fra 2026 viser, at det kan lade sig gøre. 74 procent af de adspurgte har helt eller delvist automatiseret lister for hver release eller build. Det er 334 svar fra efteråret 2025, overvejende fra store organisationer, og ikke et tal for markedet.
Følgende opbygning er udbredt. Den er praksis:
- Listen laves automatisk i byggekæden, når en version frigives.
- Listen gemmes sammen med versionens øvrige artefakter, med versionsnummer og dato.
- Listen ændres ikke bagefter. Rettes en fejl i listen, gemmes en ny udgave ved siden af med en note om, hvad der er rettet.
- Lister for interne byggerier, der aldrig frigives, gemmes efter jeres egen regel. Forordningen handler om versioner, der bringes i omsætning.
Mængden af lister er sjældent problemet. En liste fylder lidt. Problemet er ofte, at den ikke kan findes igen, eller at den blev overskrevet af det næste byggeri.
Opbevaringen
Ti år er længe i software. Byggesystemer, lagringsløsninger og formater skifter i perioden. Gennemgangen ser derfor på, om listerne kan læses om ti år. Er formatet åbent og dokumenteret, er det lettere end ved et proprietært format. Ligger listerne i et system, der kan blive lukket, bør der være en plan for at flytte dem. Begge punkter er praksis.
For en version, der frigives i dag, betyder det, at listen skal kunne findes frem et godt stykke ind i 2030’erne.
Hvad en gennemgang ser efter
En almindelig prøve er at vælge en tilfældig ældre version, som en kunde kører, og bede om dens liste. Findes den? Passer den til den version, kunden har? Er den uændret siden frigivelsen, eller er ændringer forklaret? Prøven siger mere end en beskrivelse af processen, fordi den viser, om processen også virkede for en version, ingen har kigget på i lang tid.
Hvad det kræver, og hvad det koster at lade være
Det kræver en automatisk dannelse af listen ved hver frigivelse, en fast opbevaring, hvor listen ikke overskrives, og en plan for, hvordan listerne kan læses i hele opbevaringsperioden.
Uden det kan I ikke svare på, hvad en bestemt version indeholder, når en kunde, myndighed eller jeres egen sårbarhedshåndtering spørger. Og I kan ikke vise, at dokumentationen er ajourført for den version.
Det skal I lade være med
- At skrive, at forordningen kræver en liste pr. release · det er den tyske retningslinjes regel.
- At overskrive listen ved næste byggeri · listen for den frigivne version skal kunne findes.
- At gemme lister i et format, ingen kan læse om ti år · opbevaringen skal være brugbar.
Det skal auditten kunne vise
- ☐ En liste for hver frigivet version, med versionsnummer og dato.
- ☐ Spor af rettelser i lister, adskilt fra den oprindelige.
- ☐ En plan for at gemme listerne i ti år eller hele supportperioden.
- ☐ Resultat af en prøve på en ældre version hos en kunde.
Kilder
- BSI, TR-03183-2, version 2.1.0, afsnit 3.1, læst 13. november 2026.
- Forordning (EU) 2024/2847, dansk udgave, artikel 13, stk. 13, artikel 31, stk. 2, og bilag VII, nr. 1, litra b, og nr. 2, litra b, læst 13. november 2026.
- Kommissionens tjenestegrene, FAQs on the Cyber Resilience Act, version 1.4, afsnit 4.1.8, læst 13. november 2026.
- ENISA, SBOM Adoption State of Play 2026, afsnit 2.4.2, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Vælg en version fra sidste år, som en kunde stadig kører, og se, om I kan finde dens komponentliste.
- Softwarekomponentliste, afhængigheder og tredjepartskomponenter
- Teknisk dokumentation, når softwaren udkommer hver uge
Læs også: Den tyske retningslinje TR-03183-2 som målestok · Overvågning af komponenter for hver understøttet version
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
