Bliver en ny sårbarhed kendt få dage før en planlagt release, er det jeres afgørelse ud fra risikovurderingen, om versionen kan frigives, eller om sårbarheden skal rettes først. Efter Kommissionens læsning kan en frigivelse være forsvarlig, når afvejningen bygger på risikovurderingen, og en beslutningsnote viser den bagefter.
Kravet om, at software gøres tilgængelig uden kendte sårbarheder, der kan udnyttes, er litra a under del I, nr. 2, i bilag I til CRA, forordning (EU) 2024/2847. Det skal være opfyldt for versioner, der bringes i omsætning fra 11. december 2027. Afvejningen før release beskriver Kommissionen i vejledningen C(2026) 5252, punkt 236-237, som ikke er bindende.
Kravet gælder på frigivelsesdagen
Kravet knytter sig til det tidspunkt, produktet bringes i omsætning (artikel 13, stk. 1). For selvstændig software er det den dag, en version første gang udbydes. Hvad der tæller som kendt og udnytteligt, er behandlet i artiklen om kendte udnyttelige sårbarheder ved frigivelse. Her handler det om den sene opdagelse og beslutningen om den.
Kommissionens tjenestegrenes FAQ 4.2.2 minder om, at forordningen ikke kræver et produkt uden sårbarheder. Udnytteligheden vurderes konkret. FAQ’en peger på, om koden med fejlen overhovedet bliver kørt, hvor meget adgang en angriber skal have, og om andre kontroller allerede dækker.
Afvejningen i vejledningen
Vejledningen erkender, at nye mulige sårbarheder kan blive opdaget i de sidste faser, kort før produktet går ud. Fabrikanten afgør på grundlag af risikovurderingen, om produktet kan bringes sikkert i omsætning, eller om sårbarheden skal rettes først. Fire forhold nævnes:
- sårbarhedens alvor,
- hvor let den kan udnyttes,
- den mulige virkning,
- risici for produktet, når det er i brug.
Vejledningen tilføjer, at fabrikanten også kan veje risikoen ved at udskyde. Den nye release kan rette andre sårbarheder, der kan udnyttes, eller være nødvendig for, at kritiske systemer fortsat kan køre. At holde en version tilbage er altså ikke automatisk det sikre valg.
Er versionen først ude, gælder sårbarhedshåndteringen i bilag I, del II. Sårbarheder, der opdages efter omsætning, men før produktet når brugeren, skal efter FAQ 4.2.3 ikke rettes i distributionskæden, men håndteres efter del II.
Tre tænkte situationer
Situationerne er tænkte og skal vise afvejningen, ikke facit.
Sårbarhed i en afhængighed, koden kaldes ikke. En ny sårbarhed offentliggøres i et bibliotek to dage før release. Analysen viser, at den sårbare funktion ikke kaldes. Versionen frigives, og vurderingen af, at sårbarheden ikke kan udnyttes, gemmes med begrundelse.
Alvorlig fejl i egen kode, release retter andre fejl. En intern test finder en fejl, der kan udnyttes uden login. Releasen retter samtidig to andre udnyttelige fejl i den version, kunderne har nu. Valget står mellem at frigive med en kendt fejl, der rettes i en hurtig opfølger, og at lade kunderne blive på en version med to kendte fejl. Afvejningen skal stå skrevet.
Uafklaret melding. En sikkerhedsforsker melder en mulig sårbarhed aftenen før release. Vejledningen siger, at en rapport ikke i sig selv betyder, at sårbarheden gælder produktet, og at bekræftelse kan tage begrænset tid (punkt 233-235). Beslutningen kan være at udskyde nogle dage, til meldingen er undersøgt.
Beslutningsnoten
Ingen regel kræver en skriftlig note for hver beslutning. At skrive den er praksis. Den kan forbindes med artikel 13, stk. 7, der kræver, at fabrikanten systematisk dokumenterer relevante cybersikkerhedsforhold, men det er en tolkning.
Felterne nedenfor er et forslag med tænkt indhold i parentes.
- Version og planlagt dato · (5.2.0, 14. marts 2028)
- Sårbarhed og kilde · (offentlig database, intern test eller ekstern melding)
- Alvor og udnyttelighed · (høj, kan udnyttes uden login)
- Virkning i produktet · (adgang til andre brugeres data)
- Risiko ved at udskyde · (to kendte fejl i nuværende version forbliver hos kunderne)
- Beslutning · (frigiv med opfølgende rettelse inden for kort tid)
- Hvem besluttede, og hvornår · (produktchef og sikkerhedsansvarlig, dato)
Noten gemmes sammen med de øvrige dokumenter for versionen, så den kan findes i hele dokumentationens opbevaringstid.
Efter beslutningen
Noten bør også pege fremad. Den kan angive, hvornår rettelsen forventes, og hvem der følger op. Når versionen er ude, overgår sagen til sårbarhedshåndteringen efter bilag I, del II, og noten bliver det første dokument i sagen.
Viser det sig senere, at sårbarheden udnyttes aktivt, gælder indberetningspligten i artikel 14. Pligten gælder fra 11. september 2026 og omfatter også versioner fra tiden før 11. december 2027.
Hvad det kræver, og hvad det koster at lade være
Det kræver et fast punkt i release-forløbet, hvor nye sårbarheder siden sidste scanning samles, og en person med mandat til at beslutte. Det tager kort tid, når skabelonen findes.
Uden noten kan I ikke vise, hvorfor en version gik ud med en kendt sårbarhed. Beslutningen kan have været rigtig, men den kan ikke forsvares, hvis den ikke er skrevet.
Det skal I lade være med
- At lade release-datoen afgøre sagen · afvejningen skal bygge på risikovurderingen.
- At udskyde uden at veje risikoen ved at vente · vejledningen nævner den som en del af afvejningen.
- At træffe beslutningen mundtligt · uden note er der intet spor.
Det skal auditten kunne vise
- ☐ Et fast punkt i release-forløbet til nye sårbarheder siden sidste scanning.
- ☐ Beslutningsnoter for versioner frigivet med kendte sårbarheder.
- ☐ Navnet på den, der har mandat til at beslutte.
- ☐ Spor af, at sårbarheder fundet efter frigivelsen er håndteret efter bilag I, del II.
Kilder
- Forordning (EU) 2024/2847, dansk udgave, artikel 13, stk. 1 og 7, og bilag I, del I, nr. 2, litra a, og del II, læst 13. november 2026.
- Europa-Kommissionen, C(2026) 5252, vejledning om anvendelsen af forordningen, punkt 233-237, læst 13. november 2026.
- Kommissionens tjenestegrene, FAQs on the Cyber Resilience Act, version 1.4, afsnit 4.2.2 og 4.2.3, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Find den seneste release, hvor en sårbarhed blev kendt i sidste øjeblik, og se, om beslutningen kan genfindes.
Læs også: “Ikke berørt”: den dokumenterede vurdering · Alle sårbarheder skal håndteres, ikke alle skal rettes
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
