Het treurigste dat een pentester kan overkomen, is het schrijven van een briljant rapport dat niemand leest. En het gebeurt vaker dan je denkt. Niet omdat de bevindingen niet belangrijk zijn, maar omdat het rapport is geschreven als een academisch paper in plaats van als een boodschap die tot actie moet leiden.
Een pentest-rapport heeft één doel: ervoor zorgen dat kwetsbaarheden worden opgelost. Niet: indruk maken. Niet: laten zien hoe slim je bent. Niet: elke mogelijke technische nuance documenteren. Ervoor zorgen dat de juiste mensen begrijpen wat er aan de hand is en wat ze moeten doen.
De twee doelgroepen
Elk pentest-rapport heeft minstens twee lezers die totaal verschillende dingen willen weten:
Het management wil weten: Hoe erg is het? Wat is het risico voor de organisatie? Wat kost het om te fixen? Wat gebeurt er als we niets doen? Ze willen dit in maximaal twee pagina's, zonder jargon, met een duidelijke prioritering.
Het technisch team wil weten: Waar zit het precies? Hoe reproduceer ik het? Wat is de aanbevolen fix? Is er een workaround? Ze willen screenshots, payloads, stapsgewijze reproductie-instructies en concrete code-voorbeelden.
De fout die veel pentesters maken, is een rapport schrijven voor één van beide doelgroepen. Een management summary van zeven pagina's die begint met "In het kader van de periodieke beveiligingsaudit..." is voor niemand nuttig. Een technisch rapport zonder business impact is dat evenmin.
CVSS: het gemeenschappelijke vocabulaire
Het Common Vulnerability Scoring System geeft kwetsbaarheden een score van 0 tot 10. Het is niet perfect — geen enkel scoresysteem is dat — maar het geeft een gemeenschappelijke taal. Een CVSS van 9.8 zegt: dit is urgent. Een CVSS van 3.1 zegt: dit moet je fixen, maar het hoeft niet vandaag.
De valkuil is blindelings op CVSS vertrouwen. Een SQL-injection in een interne testomgeving zonder echte data heeft misschien een hoge technische CVSS, maar het daadwerkelijke risico voor de organisatie is beperkt. Omgekeerd kan een "medium" kwetsbaarheid in een betaalsysteem een enorm bedrijfsrisico vormen. Context is alles.
De structuur die werkt
- Management Summary (1 pagina) — Scope, tijdlijn, overall risicobeoordeling, top 3 bevindingen in mensentaal, aanbeveling.
- Scope en Aanpak — Wat is getest, wat niet, welke methode, welke beperkingen.
- Bevindingen — Gesorteerd op ernst (kritiek → laag). Elke bevinding bevat:
- Titel die het probleem beschrijft (niet de techniek)
- Ernst (CVSS + business impact)
- Beschrijving in begrijpelijke taal
- Technisch bewijs (screenshots, payloads)
- Impact: wat kan een aanvaller hiermee?
- Aanbeveling: concrete fix met code-voorbeeld indien mogelijk
- Positieve bevindingen — Wat gaat er goed? Dit wordt te vaak vergeten, maar het is belangrijk voor het moraal van het team.
Tips uit de praktijk
- Schrijf de titel vanuit impact, niet vanuit techniek. Niet: "Reflected XSS in zoekparameter." Wel: "Aanvaller kan sessies van klanten overnemen via zoekfunctie."
- Screenshots zijn goud waard. Een screenshot van andermans klantgegevens op je scherm is overtuigender dan drie alinea's uitleg.
- Wees specifiek in je aanbevelingen. Niet: "Verbeter de inputvalidatie." Wel: "Gebruik parameterized queries in
/api/search(regel 142 van SearchController.java)." - Lever het rapport mondeling toe. Stuur het niet als e-mailbijlage. Presenteer het. Beantwoord vragen. Zorg dat het begrepen wordt.
Het rapport is niet het einde van de pentest. Het is het begin van de verbetering. Schrijf het alsof het gelezen gaat worden door iemand die er iets mee moet doen — want dat is precies wat er gaat gebeuren.