En nuldagssårbarhed, som etiske hackere, et testlaboratorium eller jeres egne folk finder, udløser ikke indberetningspligten i artikel 14, så længe intet tyder på, at en ondsindet aktør har udnyttet den. Sådan forklarer Kommissionen det i sin FAQ, og den grænse betyder meget for et softwarehus, der tester meget.
Til gengæld skal vurderingen kunne vises. Grænsen mellem test og udnyttelse er netop det sted, hvor en myndighed vil spørge, hvordan I nåede frem til konklusionen.
Pligten følger udnyttelsen
Artikel 14, stk. 1, handler om aktivt udnyttede sårbarheder. Definitionen i artikel 3, nr. 42, forudsætter pålidelige beviser på, at nogen med ond hensigt har brugt sårbarheden i et system uden ejerens tilladelse. En sårbarhed er altså ikke indberetningspligtig, blot fordi den er alvorlig, ny eller ukendt for omverdenen.
Kommissionens FAQ (punkt 5.2) siger, at nuldagssårbarheder skal indberettes efter artikel 14, når fabrikanten har pålidelige beviser for ondsindet udnyttelse. Uden den dokumentation gælder pligten ikke.
Kommissionens to eksempler
FAQ’en giver to eksempler, som begge falder uden for den obligatoriske pligt:
- En nuldagssårbarhed, som etiske hackere finder i et bug bounty-program, og hvor der ikke er tegn på tidligere ondsindet udnyttelse.
- En nuldagssårbarhed, som et testlaboratorium finder på fabrikantens vegne, og hvor der heller ikke er tegn på tidligere udnyttelse.
I begge tilfælde peger FAQ’en på frivillig indberetning efter artikel 15. Artikel 15 gælder efter artikel 71, stk. 2, først fra 11. december 2027. Den frivillige ordning er beskrevet i frivillig indberetning efter artikel 15.
FAQ’en henviser til betragtning 68 i forordningen. Som FAQ’en gengiver den, bør sårbarheder, der findes uden ondsindet hensigt med henblik på test, undersøgelse, rettelse eller offentliggørelse i god tro, ikke være omfattet af den obligatoriske underretning. Vi har ikke slået betragtningen op i den danske tekst, så formuleringen her bygger på FAQ’ens engelske gengivelse.
Tre situationer, der kræver en vurdering
Eksemplerne er rene. Virkeligheden er det sjældent. Tre tænkte situationer viser, hvor vurderingen bliver svær.
Testeren finder spor af andre. Under en test opdager en konsulent, at sårbarheden har efterladt spor i logfilerne fra før testen begyndte. Nu handler sagen om, hvorvidt en anden har været der først. Hvornår kendskabet opstår i sådan en sag, står i aktivt udnyttet sårbarhed og kendskab.
Forskeren nævner udnyttelse i naturen. En forsker melder en sårbarhed og skriver, at den ser ud til at blive brugt mod andre produkter med samme komponent. Det dokumenterer endnu ingen udnyttelse i jeres produkt. Signalet skal alligevel vurderes straks.
Dusørjægeren går for langt. En deltager i et bug bounty-program henter mere data end aftalt. Om det er ondsindet udnyttelse, afhænger af programmets regler og af, hvad der skete bagefter. Forordningen giver ikke et færdigt svar, og en vurdering af en konkret sag er en juridisk vurdering, vi ikke foretager her.
Vurderingen “ingen tegn på udnyttelse”
Forordningen kræver ikke, at I skriver en særskilt vurdering for hver melding. Det er praksis. Men uden den står I uden bevis, hvis en myndighed senere spørger, hvorfor en alvorlig nuldagssårbarhed ikke blev indberettet.
En kort vurdering pr. melding kan have disse felter:
- Kilde · (bug bounty-program, intern test, ekstern forsker)
- Dato for melding · (dato og klokkeslæt)
- Hvad der er undersøgt · (logfiler for de seneste 90 dage, fejlrapporter, kundehenvendelser)
- Fund · (ingen spor af udnyttelse uden for testen)
- Konklusion og begrundelse · (ikke aktivt udnyttet, ingen indberetning efter artikel 14)
- Ansvarlig · (navn og rolle)
- Genvurdering · (ved nye signaler eller efter offentliggørelse)
Det sidste felt er vigtigt. Vurderingen er et øjebliksbillede. Bliver sårbarheden offentligt kendt, før rettelsen er ude, kan den blive udnyttet, og så opstår pligten fra det tidspunkt, I får kendskab til udnyttelsen.
Hvad en gennemgang ser efter
Ved en gennemgang udtages som regel en række meldinger fra test, bug bounty og forskere og ser, om hver har en vurdering af udnyttelse. Den ser også på, om programreglerne for bug bounty og aftalerne med testere siger noget om, hvornår testeren skal stoppe og melde spor af andre aktører. Metoden er praksis.
For eksterne testere er aftalen det sted, hvor grænsen sættes. En testaftale kan sige, at testeren straks stopper og giver besked, hvis der dukker spor op af en anden aktør, og at testerens egne handlinger logges, så de kan skilles fra fremmede. Programreglerne for et bug bounty-program kan tilsvarende beskrive, hvor langt en deltager må gå, og hvad der sker med data, deltageren får adgang til. Jo klarere reglerne er, jo lettere bliver det at afgøre, om en handling var test eller noget andet.
Kravene i bilag I, del II, om et kontaktpunkt og en politik for koordineret offentliggørelse gælder fra 11. december 2027. Mange softwarehuse har dem allerede, og meldingerne derfra er den naturlige kilde til stikprøverne.
Hvad det kræver, og hvad det koster at lade være
Det kræver en skabelon til vurdering af hver melding, en klar regel for, hvem der vurderer, og programregler og testaftaler, der beder om besked ved spor af tidligere udnyttelse.
Uden vurderingerne kan I ikke skelne en ren testmelding fra en sag, der burde være indberettet. Og en sårbarhed, der først blev fundet af en tester, kan senere vise sig at være brugt af andre i samme periode.
Det skal I lade være med
- At indberette alle testfund som aktivt udnyttede · det belaster CSIRT’en og er ikke det, artikel 14 beder om.
- At afvise enhver indberetning, fordi fundet kom fra en test · spor af andre aktører ændrer billedet.
- At lade vurderingen stå uændret, når sårbarheden bliver kendt · udnyttelse kan komme senere.
Det skal auditten kunne vise
- ☐ En vurdering af udnyttelse for hver melding fra test, bug bounty og forskere.
- ☐ Programregler og testaftaler, der kræver besked ved spor af andre aktører.
- ☐ En navngiven ansvarlig for vurderingerne.
- ☐ Genvurdering, når en sårbarhed bliver offentligt kendt før rettelsen.
Kilder
- Forordning (EU) 2024/2847, dansk udgave, artikel 3, nr. 42, og artikel 14-15, læst 13. november 2026.
- Europa-Kommissionen, FAQs on the Cyber Resilience Act, version 1.4, punkt 5.2, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Tag de tre seneste meldinger fra test eller bug bounty og se, om der står en vurdering af udnyttelse ved hver.
Læs også: En udnyttet sårbarhed i et bibliotek · Regelmæssige afprøvninger i supportperioden
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
