Sårbarheder, som andre melder til jer: forbindelsen til testen

En forsker skriver til jeres supportadresse om en fejl i jeres webportal, og en uge senere kommer der en tilsvarende melding via en myndighed. Begge dele er sårbarheder, som jeres penetrationstest ikke fandt. For en NIS2-kunde er spørgsmålet ikke kun, om fejlen bliver rettet, men om jeres arbejde med sårbarheder hænger sammen: kommer meldinger og testresultater ind samme sted, og bliver de behandlet lige grundigt?

Svaret hviler på, at reglerne behandler sårbarheder ens uanset kilde. Bilaget til gennemførelsesforordning (EU) 2024/2690, punkt 6.10, handler om at indhente, vurdere og håndtere tekniske sårbarheder, uden at skelne mellem fund fra test og meldinger udefra. Teksten er ikke juridisk rådgivning.

Hvordan meldinger kan nå jer

Den direkte vej er, at den, der har fundet fejlen, skriver til jer. Den indirekte vej går gennem en myndighed. NIS 2-lovens § 18 siger, at CSIRT’en sikrer, at fysiske og juridiske personer i anonymiseret form kan rapportere om sårbarheder. SAMSIK oplyser, at Forsvarets Efterretningstjeneste varetager opgaven som national CSIRT, og FE henviser på sin side om cybertruslen til en løsning til anonym indberetning af sårbarheder. Rammen for koordineringen er beskrevet i en anden artikel her på sitet. → Koordineret offentliggørelse af sårbarheder

Udvikler I produkter med digitale elementer, kan I desuden have en egen pligt. FE oplyser, at fabrikanter fra 11. september 2026 skal rapportere aktivt udnyttede sårbarheder og alvorlige hændelser efter forordningen om cyberrobusthed. Det er en anden regel end NIS2, og om I er fabrikant efter den, er en selvstændig vurdering.

Én liste, uanset kilde

Kunden har en interesse i, at alle kendte sårbarheder i jeres leverance håndteres efter samme proces. En melding fra en forsker, et fund fra kundens egen test og et fund fra jeres bestilte penetrationstest bør derfor ende i samme register med samme oplysninger:

Kilde og dato · hvor meldingen kom fra, og hvornår den blev modtaget.
Vurdering · alvor og betydning for de kunder, der bruger den berørte del.
Afbødning og plan · hvad der er gjort med det samme, og hvornår der rettes.
Efterprøvning · hvordan rettelsen er bekræftet.
Besked · hvilke kunder der har fået at vide hvad.

Forordningens punkt 6.5.2, litra c, kræver for test en vurdering af kritisk betydning og afbødende foranstaltninger for hver konstatering. At bruge samme felter for meldinger gør det let at vise kunden et samlet billede. → Status på rettelser

Meldingen som input til næste test

En melding siger noget om, hvor jeres leverance er sårbar, og den kan også sige noget om, hvilke dele andre interesserer sig for. Det er nyttig viden, når næste test skal afgrænses. Hvis meldingerne samler sig om én del, fx login eller en bestemt integration, kan det være et argument for at give den del mere plads i omfanget.

Forordningens punkt 6.5.2, litra a, siger, at behovet for, omfanget af, hyppigheden af og typen af sikkerhedstest fastlægges ud fra risikovurderingen. Meldte sårbarheder er en del af det billede. Skriv i testplanen, at omfanget er justeret efter tidligere meldinger, så kunden kan se sammenhængen. → Et testprogram over flere år

Når testen burde have fundet det

Nogle meldinger handler om fejl, der lå inden for testens omfang og var kendte på testtidspunktet. Det er værd at undersøge hvorfor, uden at gøre det til et spørgsmål om skyld. Måske var den berørte funktion ikke med i testkontoens rettigheder. Måske var den del af systemet ændret efter testen. Måske var tiden for kort til at nå den.

Svaret kan bruges til at justere næste test og til at forklare kunden, hvad testen kunne og ikke kunne sige. Tag det op med testleverandøren som et spørgsmål om omfang og forudsætninger. Konklusionen kan være, at testen skal have bedre testkonti, mere tid eller et omfang, der følger ændringerne i leverancen. Skriv den ned, så kunden kan se, at næste test er tilpasset. → Årsagen bag fundet

Efterprøvning af en meldt sårbarhed

En melding er en påstand, indtil den er bekræftet. Det første skridt er at efterprøve, om fejlen findes, og hvor den sidder. Det kan I gøre selv eller få en testleverandør til. Kan fejlen ikke bekræftes, så skriv det ned med en begrundelse, og svar den, der meldte, så vedkommende kan sende flere oplysninger. En melding, der lukkes uden efterprøvning, er svær at forsvare, hvis den senere viser sig at være rigtig, og kunden spørger, hvad I vidste. Når rettelsen er på plads, bør den efterprøves på samme måde som et testfund, så kunden får den samme form for dokumentation. → Retest som dokumentation over for kunden

Et tænkt eksempel

En leverandør af et system til tidsbestilling hos en kæde af tandklinikker modtager via sin supportadresse en melding fra en studerende om, at en bestemt side viser oplysninger om andre patienters tider. Supporten sender meldingen videre til den sikkerhedsansvarlige samme dag. Fejlen efterprøves og bekræftes, funktionen begrænses, og klinikkæden får besked efter aftalen. Rettelsen kommer i næste udgivelse og efterprøves af den testleverandør, der også står for den årlige test. Meldingen registreres i samme oversigt som testfundene, og den studerende får et svar med tak. Ved planlægningen af næste test får sider med patientoplysninger mere plads i omfanget, og testplanen nævner meldingen som begrundelse.

Det skal I lade være med

At behandle meldinger uden for den normale proces · kunden skal kunne se et samlet billede.
At afvise en melding, fordi testen ikke fandt fejlen · testen er et øjebliksbillede.
At undlade at takke og svare den, der meldte · en melding uden svar kan gå videre ad andre veje.
At lade meldinger blive i supportsystemet · de skal nå den, der vurderer sårbarheder.
At glemme meldingerne, når næste test planlægges · de siger noget om, hvor I bør se efter.

Hvad kan og ikke kan konkluderes

En melding udefra viser, at en bestemt sårbarhed fandtes på et tidspunkt. Den siger ikke noget om resten af leverancen, og den siger ikke i sig selv, at jeres test var dårlig. Et samlet register for meldinger og testfund viser kunden, at I behandler sårbarheder ens, uanset hvor de kommer fra. Det viser ikke, at der ikke findes ukendte fejl. → Kundens egen test finder fejl i jeres løsning

Tjekliste for meldte sårbarheder

☐ Er der en kendt indgang for meldinger, og når de frem til den rette funktion?
☐ Registreres meldinger med samme oplysninger som testfund?
☐ Bliver hver melding efterprøvet, før den vurderes?
☐ Får den, der meldte, et svar?
☐ Indgår meldingerne i afgrænsningen af næste test?
☐ Har I vurderet, om forordningen om cyberrobusthed gælder jer som fabrikant?

Kilder

NIS 2-loven, lov nr. 434 af 6. maj 2025: § 18 om anonym rapportering af sårbarheder.
Gennemførelsesforordning (EU) 2024/2690: bilagets punkt 6.5.2, litra a og c, og 6.10.
SAMSIK, NIS2: FE håndterer opgaven som national CSIRT.
Forsvarets Efterretningstjeneste, cybertruslen: CSIRT-opgaven, anonym indberetning af sårbarheder og fabrikanters rapportering fra 11. september 2026.
Forordning (EU) 2024/2847 om cyberrobusthed: artikel 14 om fabrikantens rapportering og artikel 71 om anvendelse.

Senest gennemgået: oktober 2026.