Lav alvorlighed, stor bekymring: forklar et fund for kunden

Et fund kan stå som lavt i rapporten og alligevel få en kunde til at ringe, fordi ordene i overskriften lyder alarmerende, eller fordi fundet angår netop de data, kunden er mest optaget af. Svaret er en kort, skriftlig forklaring, som sætter fundet i sammenhæng med produktet og kundens brug af det. Den skal bygge på rapportens egne oplysninger og på det, I ved om løsningen, og den skal kunne læses af en person, der ikke selv er tekniker.

Bekymringen er ikke et tegn på, at kunden har misforstået noget. Den er et tegn på, at rapporten er skrevet til dem, der skal rette, og ikke til dem, der skal træffe en indkøbsbeslutning.

Hvorfor små fund vækker uro

Rapportens fund kan have korte, tekniske titler. For en udvikler er de præcise. For en indkøber eller en databeskyttelsesansvarlig hos kunden kan de lyde som et brud. Ord som adgang, lækage og omgåelse står i titlen, mens forudsætningerne, der gør fundet lavt, står længere nede i teksten.

Rapporten kan også være læst i uddrag. Måske har kunden kun fået resuméet eller fundlisten, og så mangler de afsnit, der forklarer forudsætningerne. Spørg derfor, hvilken udgave kunden har læst, før I skriver forklaringen. Det sparer en runde, hvis svaret kan henvise til de sider, kunden faktisk har.

Dertil kommer kundens egen situation. En kunde, der behandler helbredsoplysninger eller økonomiske data, læser ethvert fund om adgang til data med større alvor. Det er rimeligt, og forklaringen skal tage højde for det i stedet for at afvise det.

Fem spørgsmål, forklaringen skal besvare

En forklaring, kunden kan bruge, svarer kort på fem spørgsmål:

Hvad er fundet? · typen af svaghed med almindelige ord, uden fremgangsmåde.
Hvor i produktet? · den funktion eller det modul, fundet angår.
Hvem kan berøres? · alle kunder, nogle opsætninger eller kun bestemte roller.
Hvad begrænser det? · forudsætninger som login, rettigheder eller andre beskyttelser.
Hvad er gjort? · status, dato og om rettelsen er efterprøvet.

Det britiske NCSC skriver, at en testrapport bør indeholde de fundne problemer og en måde at løse hvert af dem på. Forklaringen til kunden bygger videre på det: den oversætter løsningen til en status, kunden kan forholde sig til. → Pentestrapporten, der skal vises til kunder

Skriv til den, der skal læse det

Spørg, hvem hos kunden der har rejst spørgsmålet. En sikkerhedsansvarlig vil have forudsætningerne og alvorligheden. En indkøber eller en jurist vil vide, om fundet ændrer noget for kontrakten eller for kundens egne forpligtelser. En driftsansvarlig vil vide, om kunden selv skal gøre noget. Én forklaring kan godt dække alle tre, hvis den er bygget op med det vigtigste først.

Skriv i hele sætninger. Undgå forkortelser, som kun bruges internt, og forklar skalaen, rapporten bruger, hvis kunden ikke kender den. Hvis fundet er en kendt sårbarhed i en komponent, kan en henvisning til det offentlige CVE-nummer hjælpe kundens folk med at slå op selv. → Open source og tredjepartskomponenter

Overvej, om forklaringen skal gives mundtligt først. Et kort opkald med en, der kender produktet, kan afklare bekymringen hurtigere end en skriftlig udveksling, og kunden får lov at stille de spørgsmål, der faktisk optager den. Send bagefter den skriftlige forklaring, så kunden har noget at vise internt.

Bland ikke forklaringen sammen med salgsbudskaber. En sætning om, hvor seriøst I tager sikkerhed, tilfører intet og kan få resten til at lyde som et forsvar.

Afhjælpning, kunden selv kan bidrage med

Nogle fund begrænses bedst i kundens egen opsætning: færre administratorer, tofaktorlogin slået til for alle brugere eller en funktion, der kan slås fra, hvis kunden ikke bruger den. Når det er tilfældet, skal forklaringen sige det tydeligt og konkret, men på begrebsniveau. Kunden skal vide, hvilken indstilling eller hvilken praksis det drejer sig om, ikke hvordan fundet kunne udnyttes.

Sig samtidig, hvad I selv gør. Et råd til kunden må ikke ligne et forsøg på at flytte ansvaret for en fejl i produktet. → Kundernes eget ansvar: det, I ikke kan teste for dem

Et tænkt eksempel

Et softwarehus leverer en lønportal til mellemstore virksomheder. I rapporten står et lavt fund om, at en bruger kan se navnene på kolleger i andre afdelinger i en søgefunktion. Kundens HR-chef læser titlen og frygter, at lønoplysninger kan ses på tværs.

Forklaringen fra softwarehuset er på en halv side. Den gengiver fundets titel og testerens vurdering, forklarer, at kun navne og afdelinger var synlige, at lønoplysninger ikke indgik, og at fundet kræver login som bruger hos samme kunde. Den oplyser, at søgningen er begrænset til egen afdeling i en release, der er planlagt, og at retesten er bestilt. Den nævner, at kunden indtil da kan slå søgefunktionen fra for almindelige brugere. HR-chefen kan bruge forklaringen direkte i sin interne orientering og har en kontaktperson, hvis spørgsmålene fortsætter.

Gem forklaringen

Når én kunde har spurgt, gør andre det sandsynligvis også. Gem forklaringen sammen med rapporten og statusoversigten, så den samme tekst kan bruges igen og holdes opdateret. Notér, hvornår den sidst blev gennemgået, og hvem der har godkendt den. Når fundet er rettet og efterprøvet, opdateres teksten, så den ikke længere beskriver en plan, der er gennemført. → Et svarbibliotek: genbrug svar uden at love for meget

Hvis forklaringen fører til, at kunden alligevel er uenig i vurderingen, er det en anden samtale. → Kunden læser et fund anderledes end jer

Det skal I lade være med

Kalde fundet ubetydeligt · Lav alvorlighed er ikke det samme som ingen betydning for kunden.
Gentage rapportens titel uden forklaring · Titlen er skrevet til teknikere.
Beskrive, hvordan fundet kan udnyttes · Kontekst er nok; fremgangsmåden hører ikke hjemme her.
Pakke forklaringen ind i salgssprog · Saglighed giver mere tillid.
Lægge ansvaret over på kunden · Råd til kunden kommer oven i jeres egen rettelse.
Sende en udateret forklaring · Status ændrer sig, og kunden skal vide, hvornår teksten gjaldt.

Hvad kan og ikke kan konkluderes

En god forklaring hjælper kunden med at vurdere et bestemt fund i forhold til sin egen brug. Den ændrer ikke testerens vurdering, og den siger intet om dele af produktet, som testen ikke dækkede. Oplysninger om rettelser, der endnu ikke er efterprøvet, er jeres eget udsagn.

Tjekliste til forklaringen

☐ Svarer den på, hvad, hvor, hvem, hvad der begrænser, og hvad der er gjort?
☐ Er testerens vurdering gengivet uændret?
☐ Er teksten skrevet til den, der har spurgt?
☐ Er råd til kunden konkrete, men uden teknisk fremgangsmåde?
☐ Er forklaringen dateret og godkendt af en, der kender produktet?
☐ Er den gemt, så den kan genbruges og opdateres?

Kilder

NCSC (UK): Penetration testing: testrapporten bør indeholde de fundne problemer og en måde at løse hvert af dem på.
CVE: offentlige numre for kendte sårbarheder, som kunden kan slå op.

Senest gennemgået: oktober 2026.