En fremmed skriver, at der er fundet en sårbarhed på jeres hjemmeside eller i webshoppen, og spørger, om I betaler en dusør for detaljerne. Henvendelsen kan være en ærlig melding, et forsøg på at presse jer til betaling eller et tegn på, at nogen har testet jeres systemer uden tilladelse. Svaret hviler på tre ting: kontrollér påstanden, før I tager stilling til afsenderen; lad én person svare sagligt og uden løfter; og vurdér bagefter, om en bestilt test er det rigtige næste skridt.
Situationen kan ramme enhver virksomhed med en hjemmeside, ikke kun softwarehuse. Den kræver ikke, at I har et program for sårbarhedsmeldinger, men den bliver lettere at håndtere, hvis I har tænkt den igennem på forhånd.
Tre slags henvendelser
- Den ærlige melding · afsenderen beskriver, hvad der er set, hvor og hvornår, og tilbyder at give detaljerne uden betingelser. Tonen er saglig, og der er ingen frist.
- Presset for betaling · detaljerne gives kun mod betaling, der er en frist, eller der antydes offentliggørelse. Beskrivelsen er vag og kan passe på enhver hjemmeside.
- Tegn på uautoriseret test · beskrivelsen viser, at afsenderen har været inde i et system, set data eller forsøgt at logge ind. Uanset hensigten er det sket uden jeres tilladelse.
En henvendelse kan have træk af flere typer. Kategorien er et redskab til at vælge svar, ikke en dom over afsenderen.
Kontrollér påstanden
Send henvendelsen videre til den, der har ansvaret for systemet: IT-ansvarlig, driftsleverandør, hostingfirma eller webbureau. Bed dem vurdere, om den beskrevne svaghed findes, om den gælder jeres system, og om der er spor af aktivitet i logfilerne, der passer med tidspunktet. → Driftsleverandøren og testen
Nogle meldinger bygger på et automatisk udtræk, der markerer forhold uden at vurdere dem. Andre peger på en reel svaghed. Forskellen kan ikke ses ud fra mailen alene. Klik ikke på vedhæftede filer eller links i henvendelsen, før de er vurderet, og send dem ikke rundt i organisationen.
Viser kontrollen, at nogen har haft adgang til data, er det ikke længere kun en melding. Så skal I vurdere det som en mulig sikkerhedshændelse. → Kritiske fund: de første skridt
Hvem svarer, og hvad der skrives
Lad én person svare, og skriv fra en fælles adresse frem for en privat. Notér, hvornår henvendelsen kom, hvad der blev kontrolleret, og hvad der blev svaret. Notaterne er nyttige, hvis afsenderen skriver igen, eller hvis sagen senere skal forklares over for ledelsen eller en rådgiver. Den britiske myndighed NCSC anbefaler i sin vejledning til modtagere af sårbarhedsmeldinger, at man svarer hurtigt, takker finderen og fortæller, hvad finderen kan forvente. Det er et godt udgangspunkt, også når I ikke har en politik.
Et første svar kan kvittere for henvendelsen, bede om de konkrete oplysninger og sige, at I undersøger sagen. Det bør ikke love betaling, og det bør ikke opfordre afsenderen til at undersøge videre. Skriv udtrykkeligt, at svaret ikke er en tilladelse til yderligere test.
Om I vil give en påskønnelse, er jeres beslutning. Betal ikke under tidspres for oplysninger, I ikke har set. Stiller afsenderen krav eller trusler, så tal med jeres egen rådgiver, før I svarer igen. Et program, hvor I selv inviterer til meldinger mod belønning, er noget andet end en uopfordret mail. → Bug bounty eller penetrationstest
Tilladelsen og loven
En penetrationstest kræver tilladelse fra den, der råder over systemet. Uberettiget adgang til andres datasystemer er omfattet af straffeloven § 263, stk. 1. Om en konkret henvendelse rejser et juridisk spørgsmål, afhænger af, hvad afsenderen har gjort, og det er en vurdering for jeres egen rådgiver. Teksten er ikke juridisk rådgivning. → Er en penetrationstest lovlig?
Det samme princip gælder jeres egen kontaktinformation. RFC 9116, som beskriver filen security.txt, siger udtrykkeligt, at en offentliggjort fil ikke giver tilladelse til at teste domænet. Hvis I vil give tilladelse til noget, skal det stå i en politik.
Gør det lettere næste gang
En fast kontaktvej gør det enklere for den ærlige afsender og lettere for jer at genkende de henvendelser, der kommer uden om den. RFC 9116 beskriver en fil på adressen /.well-known/security.txt med mindst to felter: en kontaktvej og en udløbsdato. NCSC anbefaler desuden en kort politik, der siger, hvordan man melder, hvad meldingen skal indeholde, og hvad afsenderen kan forvente.
Rammeværket CSF 2.0 har et resultat om processer for at modtage, analysere og reagere på sårbarhedsmeldinger. ISO/IEC 29147 beskriver det samme for leverandører af produkter og tjenester. For et softwarehus med kunder er det en større opgave, og den er beskrevet på pentestrapport.dk.
Når en bestilt test er det rigtige svar
En bekræftet melding fortæller, at der var mindst én svaghed i det område, afsenderen så på. Den siger intet om resten. Hvis svagheden kunne findes udefra, kan det være relevant at få hele den internetvendte del undersøgt af en tester med tilladelse, et aftalt scope og en rapport. → Ekstern eller intern penetrationstest
En bestilt test er også svaret, hvis I vil vide, om rettelsen virker. En melding fra en fremmed kan ikke dokumentere det over for kunder eller ledelse. → Retest efter penetrationstest
Det skal I lade være med
- At betale under pres · se oplysningerne og få dem vurderet, før I tager stilling.
- At ignorere alle henvendelser · en ærlig melding kan pege på en reel svaghed.
- At invitere til mere · skriv, at svaret ikke er en tilladelse til yderligere test.
- At svare fra flere indbakker · én person og én adresse gør forløbet sporbart.
- At åbne vedhæftede filer ukritisk · lad dem vurdere først.
- At bruge meldingen som dokumentation · den erstatter ikke en test med scope og rapport.
Hvad kan og ikke kan konkluderes
En kontrolleret melding kan vise, at en bestemt svaghed fandtes på et bestemt tidspunkt. Den kan ikke vise, hvordan resten af jeres systemer står, og den siger intet om afsenderens hensigt. Fravær af spor i logfilerne er heller ikke et bevis for, at intet er sket, hvis logningen ikke dækker området.
Tjekliste, når mailen kommer
- ☐ Er henvendelsen sendt videre til den, der har ansvaret for systemet?
- ☐ Er påstanden kontrolleret, og er der set efter spor i logfilerne?
- ☐ Er det vurderet, om der kan være tale om en sikkerhedshændelse?
- ☐ Svarer én person fra en fælles adresse?
- ☐ Siger svaret, at det ikke er en tilladelse til yderligere test?
- ☐ Er krav eller trusler forelagt jeres rådgiver?
- ☐ Har I en security.txt med kontaktvej og udløbsdato?
- ☐ Er det vurderet, om en bestilt test er det næste skridt?
Kilder
- RFC 9116: A File Format to Aid in Security Vulnerability Disclosure: felterne Contact og Expires og afsnit 5.5 om, at filen ikke giver tilladelse til test.
- NCSC (UK): Vulnerability Disclosure Toolkit: kontaktvej, kvittering, tak og politik for modtagere af meldinger.
- ISO/IEC 29147:2018: leverandørers modtagelse og offentliggørelse af sårbarhedsoplysninger.
- NIST CSF 2.0 (CSWP 29): resultatet ID.RA-08 om processer for sårbarhedsmeldinger.
- Straffeloven, lovbekendtgørelse nr. 1294 af 7. november 2025: § 263, stk. 1.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler om penetrationstest
Læs også: Etisk hacker · Hackere og deres hatte
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
