Åbne fund i den rapport, kunden skal have

En pentestrapport bliver ikke altid færdig på et tidspunkt, hvor alle fund er rettet, og alligevel kan den skulle sendes til en kunde. Spørgsmålet er ikke, om åbne fund må stå i rapporten, men hvordan kunden får et retvisende billede af dem uden at få en beskrivelse, der kan misbruges.

Svaret hviler på to adskilte dokumenter: rapporten, som beskriver situationen på testdagen, og en dateret status, som I selv holder ajour. Rapporten ændrer I ikke. Statussen viser, hvad der er sket siden, og hvad planen er for det, der stadig er åbent.

Rapporten er et øjebliksbillede

Det britiske NCSC påpeger, at en penetrationstest kun kan bekræfte forholdene på den dag, testen blev udført. Det gælder også fundene. Et fund, der står som åbent i rapporten, kan være rettet en uge senere, og et fund, I har planlagt at rette, kan være skubbet. Kunden har brug for begge oplysninger: hvad testeren så, og hvor I står nu.

Derfor bør I ikke redigere fundene i testerens rapport for at få dem til at se nyere ud. Rapporten er testerens udsagn, og den skal kunne læses som det. Jeres opdateringer hører hjemme ved siden af, med jeres eget navn som afsender. → Retestbevis: vis kunden, at fundene er rettet

En statusoversigt ved siden af rapporten

En kort oversigt over fundene, som I selv udarbejder, løser det meste. Den kan følge med rapporten eller kundeversionen og bør indeholde:

Fundets reference · samme nummer eller titel som i rapporten, så kunden kan slå op.
Alvorlighed · som testeren vurderede den, med rapportens egen skala.
Status · rettet og efterprøvet, rettet men ikke efterprøvet, under rettelse, planlagt eller accepteret.
Plan · en release eller en periode, hvis fundet ikke er lukket.
Dato for statussen · så kunden ved, hvornår oplysningerne var gældende.

Mange rapporter angiver alvorlighed med CVSS. FIRST beskriver CVSS som et mål for en sårbarheds alvorlighed i forhold til andre sårbarheder, og nævner at forhold uden for systemet, som fx lovkrav, ligger uden for det, CVSS vurderer. Brug derfor testerens score som fælles reference, men forklar jeres egen vurdering, hvis I ser risikoen anderledes. → Kunden læser et fund anderledes end jer

Hvad kunden skal se om et åbent fund

Kunden skal kunne vurdere, om et åbent fund berører kundens egen brug af produktet. Det kræver en overordnet beskrivelse af, hvilken type svaghed der er tale om, hvilken del af produktet den angår, og om der er andre beskyttelser, der begrænser den. Det kræver ikke trinvise beskrivelser, eksempler på forespørgsler eller præcise adresser.

Hold de detaljer i den fulde rapport og del dem kun under fortrolighed og med en begrundelse. En kundeversion, hvor de tekniske detaljer om åbne fund er fjernet, mens resten står uændret, er ofte den rigtige løsning. Det skal tydeligt fremgå, at noget er udeladt, og hvad det er for noget. → Kundeversionen af rapporten

Nogle kunder vil alligevel vide mere om et bestemt åbent fund, fx fordi det angår en funktion, kunden er afhængig af. Et kort møde, hvor jeres sikkerhedsansvarlige forklarer fundet, de beskyttelser der begrænser det, og planen for rettelsen, giver ofte mere tillid end en udvidet skriftlig beskrivelse. Det, der siges, bliver ikke liggende i en mailtråd, og kunden får lejlighed til at stille de spørgsmål, der faktisk optager den. Skriv bagefter kort ned, hvad der blev oplyst, så næste samtale med samme kunde bygger videre på det.

Accepterede fund kræver en begrundelse

Nogle fund retter I ikke. Måske er funktionen på vej ud, måske kræver rettelsen en tredjepart, eller måske vurderer I, at andre beskyttelser dækker. Det er legitime beslutninger, men over for en kunde skal de begrundes, og det skal fremgå, hvem der har truffet dem, og hvornår de tages op igen.

Skriv et accepteret fund som accepteret. Det er fristende at kalde det planlagt, men kunden vil før eller siden spørge til planen, og så er forklaringen svær. → Kompenserende foranstaltninger

Et tænkt eksempel

Et softwarehus leverer et system til elevadministration og skal sende rapporten til en ny kommunal kunde. Testen fandt fem fund: et højt, to middel og to lave. Det høje er rettet og efterprøvet ved retest, et middel er rettet og venter på retest, et middel ligger i næste release, og de to lave er accepteret, fordi de angår en eksportfunktion, der udfases.

Kunden får kundeversionen af rapporten og en statusoversigt på én side, dateret og underskrevet af den sikkerhedsansvarlige. Oversigten bruger rapportens nummerering. For det middel fund, der venter, står releasen, og for de lave står begrundelsen og datoen for udfasningen. Kunden kan se hele billedet uden at modtage en beskrivelse af, hvordan de åbne fund kan udnyttes.

Når statussen ændrer sig efter udleveringen

En statusoversigt bliver forældet. Aftal internt, hvem der opdaterer den, og hvornår kunder, der allerede har modtaget den, skal have en ny. Ved væsentlige ændringer, fx at et planlagt fund bliver forsinket, er det bedre at fortælle kunden det selv end at vente på næste spørgsmål. Er et åbent fund alvorligt nok til, at kunder bør handle, er det et andet spørgsmål, som bør afgøres for sig. → Testen finder noget alvorligt: skal kunderne have besked?

Notér, hvilken udgave af oversigten hver kunde har fået. Det gør det enkelt at sende en opdatering til de rigtige. → Log over, hvem der har fået rapporten

Det skal I lade være med

Rette i testerens rapport · Opdateringer skal komme fra jer og stå for sig.
Fjerne åbne fund fra kundeversionen · Kunden opdager det, når den fulde rapport en dag deles.
Udlevere tekniske detaljer om åbne fund · Beskriv typen og planen, ikke fremgangsmåden.
Kalde et accepteret fund planlagt · Begrundelsen er en anden og skal fremgå.
Sende en udateret status · Uden dato ved ingen, hvornår den var rigtig.
Love en release, der ikke er besluttet · Brug en periode, hvis datoen er usikker.

Hvad kan og ikke kan konkluderes

En rapport med åbne fund og en ærlig statusoversigt viser kunden, at fundene er kendt, vurderet og håndteret. Den viser ikke, at produktet er uden svagheder, og den dækker kun det, testen undersøgte. Status på rettelser, som ikke er efterprøvet, er jeres eget udsagn og skal fremstå som sådan.

Tjekliste til åbne fund i kundens rapport

☐ Er testerens rapport uændret?
☐ Har hvert åbent fund status, plan og ansvarlig i oversigten?
☐ Følger oversigten rapportens nummerering og skala?
☐ Er accepterede fund begrundet?
☐ Er tekniske detaljer om åbne fund holdt ude af kundeversionen?
☐ Er oversigten dateret, og ved I, hvem der har fået hvilken udgave?

Kilder

NCSC (UK): Penetration testing: en test kan kun bekræfte forholdene på testdagen.
FIRST CVSS v4.0: CVSS måler alvorlighed i forhold til andre sårbarheder; forhold uden for systemet ligger uden for CVSS.

Senest gennemgået: oktober 2026.