Forordningen kræver ikke en rettelse for hver sårbarhed i en afhængighed, men den kræver, at I dokumenterer de sårbarheder, I bliver bekendt med, og at afhjælpningen står i forhold til risikoen. En vurdering af, at produktet ikke er berørt, er derfor et bevis, der skal kunne holde, når nogen ser på det senere.
Fra 11. december 2027 hører den interne vurdering til den dokumentation, en markedsovervågningsmyndighed kan bede om. Artiklen handler om, hvad den bør indeholde, og hvordan en gennemgang stikprøver gamle vurderinger. Svaret til en kunde er et andet emne.
Grundlaget
Efter artikel 13, stk. 7, fører fabrikanten en systematisk og forholdsmæssig dokumentation af relevante cybersikkerhedsforhold. Den omfatter de sårbarheder, fabrikanten får kendskab til, og de oplysninger fra andre, der har betydning.
Kommissionens FAQ forklarer, hvordan det hænger sammen med afhjælpning. Ifølge FAQ’en er det ikke hver eneste sårbarhed, der skal have sin egen rettelse. Det er risikoen, der styrer, og fabrikanten tager stilling til den i risikovurderingen og handler uden ophold, når risikoen kræver det.
FAQ’ens eksempel er hardware, men pointen passer på software. En router indeholder et bibliotek med en sårbarhed, men bibliotekets funktioner kaldes aldrig. Fabrikanten kan forventes at dokumentere sårbarheden, kan vælge ikke at rette den med en særskilt opdatering og kan forventes at fjerne det ubrugte bibliotek i den næste almindelige udgivelse.
Eksemplet viser tre ting. Sårbarheden skal dokumenteres, også når den ikke rettes. Afgørelsen om ikke at lave en særskilt opdatering skal være begrundet. Og det ubrugte bibliotek bør væk, når lejligheden er der.
Tre spørgsmål, en vurdering skal svare på
FAQ’en nævner kriterier for, om en sårbarhed kan udnyttes: om og hvor tit koden med fejlen bliver kørt, hvor høje rettigheder en angriber skal starte med, og om andre kontroller allerede dækker hullet. Det svarer til definitionen i artikel 3, nr. 41, af en sårbarhed, der kan udnyttes effektivt under praktiske operationelle forhold.
Omsat til en intern vurdering giver det tre spørgsmål:
- Kaldes koden? Bruger produktet den funktion i komponenten, sårbarheden sidder i? Eller er komponenten med, men den sårbare del aldrig i brug?
- Kan den nås? Kan en angriber påvirke de data eller den vej, der fører til den sårbare kode? Kræver det adgang, en angriber ikke realistisk har?
- Under hvilke driftsforhold? Gælder konklusionen alle understøttede konfigurationer, eller kun standardopsætningen? Hvad hvis kunden slår en valgfri funktion til?
En vurdering, der svarer på alle tre med begrundelse, er et langt bedre bevis end en markering af, at sårbarheden er “ikke relevant”.
En tjekliste fra CSAF
Der findes et format, der kan bruges som tjekliste. CSAF 2.0 er en OASIS-standard for maskinlæsbare sikkerhedsmeddelelser, og den har en VEX-profil til at meddele, om et produkt er berørt. Formatet opstiller fem begrundelser for, at et produkt ikke er berørt. Gengivet på dansk: komponenten findes ikke i produktet, den sårbare kode findes ikke, den sårbare kode kan ikke styres af en angriber, den sårbare kode er ikke i udførselsvejen, og indbyggede afbødninger findes allerede.
Vi nævner listen, fordi den er en nyttig måde at tvinge vurderingen til at vælge en begrundelse. Forordningen kræver hverken CSAF eller VEX. Formatet er et valg, ikke et krav.
Vurderingen i komponentlisten?
BSI holder i TR-03183-2 sårbarheder helt ude af komponentlisten. Vurderingerne hører efter retningslinjen hjemme i særskilte sikkerhedsmeddelelser, og den nævner CSAF og VEX. Retningslinjen er ikke bindende, men skellet er nyttigt. Komponentlisten beskriver, hvad produktet indeholder. Vurderingen beskriver, hvad en bestemt sårbarhed betyder for produktet, og den kan ændre sig fra dag til dag.
Når vurderingen ældes
En vurdering af, at produktet ikke er berørt, gælder for en bestemt version på en bestemt dato. Den kan blive forkert. Produktet kan begynde at kalde den sårbare funktion i en ny version. Der kan komme ny viden om, hvordan sårbarheden kan udnyttes.
En gennemgang trækker typisk et antal ældre vurderinger ud og prøver dem mod den nuværende version. Kaldes koden stadig ikke? Er den kompenserende kontrol stadig til stede? Er der kommet nye oplysninger om sårbarheden? Stikprøven er praksis. Den viser, om vurderingerne bliver set efter, eller om de står, til nogen spørger.
Hvad det kræver, og hvad det koster at lade være
Det kræver en fast skabelon for vurderinger med de tre spørgsmål, en dato og en version, og en regel om, hvornår en vurdering skal gentages, for eksempel ved hver ny version eller når der kommer ny viden om sårbarheden.
Uden skabelonen bliver “ikke berørt” et ord i et sagsstyringssystem. Det kan ikke bruges som bevis, og det kan ikke genbruges, når den næste kunde spørger om den samme sårbarhed.
Det skal I lade være med
- At markere en sårbarhed som irrelevant uden begrundelse · dokumentationen efter artikel 13, stk. 7, skal kunne følges.
- At lade en gammel vurdering gælde for en ny version uden at se efter · koden kan have ændret sig.
- At skrive vurderingen ind i komponentlisten · listen og vurderingen har hver sin opgave.
Det skal auditten kunne vise
- ☐ En dateret vurdering for hver kendt sårbarhed i en afhængighed, der ikke er rettet.
- ☐ Svar på, om koden kaldes, om den kan nås, og under hvilke driftsforhold.
- ☐ Version og konfiguration, vurderingen gælder for.
- ☐ Spor af, at ældre vurderinger er set efter mod nyere versioner.
Kilder
- Forordning (EU) 2024/2847, dansk udgave, artikel 3, nr. 41, og artikel 13, stk. 7, læst 13. november 2026.
- Kommissionens tjenestegrene, FAQs on the Cyber Resilience Act, version 1.4, afsnit 4.2.2 og 4.3.1, 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.
- BSI, TR-03183-2, version 2.1.0, afsnit 3.1 og 8.1.14, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Find tre sårbarheder, I har markeret som ikke relevante, og se, om vurderingen svarer på de tre spørgsmål.
- Softwarekomponentliste, afhængigheder og tredjepartskomponenter
- Alle sårbarheder skal håndteres, ikke alle skal rettes
Læs også: Ingen kendte udnyttelige sårbarheder ved frigivelse · Overvågning af komponenter for hver understøttet version
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
