Pentestrapport lezen: CVSS, risico en wat je eerst oplost

Een pentestrapport met veertig bevindingen is geen takenlijst van veertig dingen. Wie op CVSS-score sorteert, lost soms de verkeerde dingen eerst op.

Je hebt net een rapport ontvangen. Er staan rode, oranje en gele labels in, met cijfers erachter. Wat moet je nu doen? In dit artikel leggen we uit wat die cijfers betekenen, waarom een score niet jouw risico is, hoe je false positives herkent en hoe je van rapport naar backlog komt. Als je nog moet kiezen of je een pentest wilt, lees dan eerst wat een pentest kost en oplevert.

Hoe is een rapport opgebouwd?

De meeste rapporten hebben dezelfde onderdelen:

1. Management-samenvatting. Algemene indruk, grootste risico's, aanbevolen volgorde.
2. Scope en methode. Wat is getest, met welke rollen en wanneer. Belangrijk: wat is niet getest.
3. Bevindingenlijst. Per bevinding: beschrijving, impact, ernst, bewijs, reproductiestappen, aanbeveling.
4. Bijlagen. Ruwe output, requests, tooling.

Begin met de samenvatting en de scope. De scope bepaalt wat het rapport waard is. Een shop zonder bevindingen in een scope waar de checkout niet in zat, is niet "veilig". Hij is "niet getest op die plek".

CVSS in gewone taal

CVSS staat voor Common Vulnerability Scoring System. Het geeft een kwetsbaarheid een score van 0 tot 10. De base score is gebaseerd op eigenschappen van de kwetsbaarheid zelf, zoals:

• Aanvalsvector. Kan het via het internet, of moet de aanvaller lokaal zijn?
• Complexiteit. Is het simpel te misbruiken of vraagt het speciale omstandigheden?
• Benodigde rechten. Moet de aanvaller ingelogd zijn?
• Gebruikersinteractie. Moet iemand ergens op klikken?
• Impact. Vertrouwelijkheid, integriteit en beschikbaarheid: lekt data, kan data worden gewijzigd, ligt de dienst eruit?

De uitkomst valt in vier hoofdniveaus: laag, gemiddeld, hoog en kritiek. Als voorbeeld uit de praktijk: de Magento-kwetsbaarheid SessionReaper (CVE-2025-54236) kreeg een CVSS van 9.1, kritiek, omdat ze via het internet te misbruiken was zonder inloggen en grote impact had.

Er bestaan ook scores die tijd en omgeving meenemen (temporal en environmental). Die worden in rapporten zelden ingevuld, terwijl juist die jouw situatie beschrijven.

Waarom score niet gelijk is aan jouw risico

CVSS beantwoordt de vraag: "hoe erg is dit type fout in het algemeen?" Jij wilt weten: "hoe erg is dit bij ons?" Dat zijn verschillende vragen. Drie factoren veranderen de uitkomst.

Bereikbaarheid. Een kritieke fout in een admin-functie die alleen via een VPN bereikbaar is, is minder urgent dan een gemiddelde fout op een publieke pagina. Het omgekeerde kan ook: een "gemiddelde" fout die iedereen kan misbruiken, weegt zwaarder dan een "hoge" fout die vraagt dat de aanvaller al beheerder is. Welke data zit erachter? Een IDOR die orders van andere klanten toont, is voor een webshop met persoonsgegevens zwaarder dan dezelfde fout op een pagina met publieke productinformatie. Een datalek met risico voor betrokkenen moet je binnen 72 uur melden bij de Autoriteit Persoonsgegevens (AVG art. 33). Dat maakt bepaalde bevindingen zakelijk zwaarder dan de score suggereert. Combinaties. Een tester ziet soms dat drie "lage" bevindingen samen een kritiek pad vormen. Bijvoorbeeld: informatielekkage van gebruikersnamen, geen rate limiting op login, en geen 2FA. Elk afzonderlijk is klein, samen leiden ze tot accountovername. Een goede tester beschrijft zulke ketens. Zie ook credential stuffing op klantaccounts.

Het omgekeerde bestaat ook. Een score van 9 voor een fout die in jouw configuratie niet te bereiken is, kan in de praktijk een 3 zijn. Vraag de tester of de ernst is aangepast aan jouw situatie en waarom.

De ernstlabels vertaald naar actie

Elk bedrijf kiest eigen termijnen. Als vertrekpunt, geen norm:

Wat in je backlog komt, is een keuze. Kritieke dingen laat je niet in een backlog staan; die doe je nu.

False positives en discussiepunten

Ook een handmatige pentest kan er naast zitten, en zeker tool-output in een rapport. Beoordeel elke bevinding kritisch.

Controleer:

• Is de reproductie te volgen? Een goede bevinding bevat requests en stappen waarmee jouw developer het zelf ziet. Lukt dat niet, vraag om uitleg.
• Was de test op de juiste omgeving? Een bevinding op staging die niet op productie bestaat (of omgekeerd) vraagt context.
• Is de aanname van de tester juist? Bijvoorbeeld: "de admin is publiek bereikbaar", terwijl er een IP-beperking in de CDN zit die de tester niet zag.
• Is het gewenst gedrag? Soms is iets een bewuste keuze. Documenteer dan waarom.
• Is het een duplicaat? Eén oorzaak kan op tien plekken zichtbaar zijn. Los de oorzaak op, niet tien symptomen.

Afwijzen kan, maar leg het vast. "Geaccepteerd risico" mag, mits iemand met mandaat dat bewust besluit en datum en reden noteert.

Van bevindingen naar backlog

Een werkbare aanpak in vijf stappen.

1. Groepeer op oorzaak. Tien bevindingen over ontbrekende eigenaarschapscontrole zijn één technisch probleem: er is geen centrale check. Los dat structureel op. Voor het patroon zelf: broken access control en IDOR.
2. Beoordeel per groep de werkelijke ernst. Bereikbaarheid, data, ketens.
3. Schat de inspanning. Een kritieke fix van een uur gaat voor een hoge fix van een week. Snelle winst eerst.
4. Kies mitigaties voor wat niet direct kan. Een WAF-regel, een functie tijdelijk uitzetten, een IP-beperking. Zie WAF-bescherming voor webshops.
5. Maak tickets die een developer kan oppakken. Neem de reproductiestappen en de aanbeveling over. Verwijs naar het rapport.

Een eenvoudige prioriteitsvolgorde die vaak werkt: eerst alles met data-inzage of accountovername, dan alles met code-uitvoering of admin-toegang, dan de rest op ernst en inspanning.

Wie doet wat?

Wijs eigenaren aan. Een rapport zonder eigenaar blijft liggen.

• Developer: fixes in code en configuratie.
• Hosting of beheerder: serverconfiguratie, poorten, WAF.
• Eigenaar of manager: besluiten over geaccepteerd risico, budget, communicatie.
• Compliance-contact: meldplicht, PCI-gerelateerde bevindingen.

Heb je een extern team voor onderhoud? Geef het rapport rechtstreeks aan de developer, niet via vier tussenpersonen. Bij ons loopt dat zonder tussenlaag: je spreekt direct met degene die de fix schrijft.

Hertest: sluit de cirkel

Na het fixen laat je de bevindingen controleren. Zonder hertest weet je alleen dat er een ticket is gesloten, niet dat de fout weg is. Veelgemaakte fouten bij fixes:

• Alleen het symptoom gepatcht (één endpoint), niet de oorzaak.
• Fix op de voorkant, terwijl de API dezelfde fout heeft.
• Een blokkade die met een kleine variatie te omzeilen is.

Vraag aan het eind om een bijgewerkt rapport met per bevinding de status: opgelost, deels opgelost, open, geaccepteerd.

Wat je met het rapport doet

• Bewaar het veilig. Het bevat een routekaart naar je zwakke plekken. Deel het niet breed en niet per gewone e-mail.
• Gebruik het voor je jaarplan. Zie pentest, audit en scan in een jaarplan.
• Gebruik het als bewijs richting klanten, auditors of een QSA, in de vorm die de tester toestaat. Vaak is een samenvatting geschikter dan het volledige rapport. Voor PCI-context: PCI DSS 4.0.
• Leer ervan. Komt een type fout vaker terug, bijvoorbeeld ontbrekende ownership-checks of te ruime CORS-instellingen, pas dan je ontwikkelproces aan. Zie ook security misconfiguration in webshops.

Veelgestelde vragen

Wat betekent een CVSS-score van 9 of hoger?

Een score van 9 of hoger valt in de categorie kritiek. Het betekent dat de fout via het netwerk vaak eenvoudig te misbruiken is en grote impact heeft op vertrouwelijkheid, integriteit of beschikbaarheid. Je weet daarmee nog niet hoe erg het voor jouw shop is. Toets bereikbaarheid en data.

Moet ik alle bevindingen oplossen?

Niet allemaal even snel. Kritieke en hoge bevindingen pak je direct of binnen korte tijd aan. Lage en informatieve punten kun je bundelen of bewust accepteren. Leg elk besluit vast met reden en datum.

Hoe herken ik een false positive?

Een false positive heeft meestal geen reproduceerbare stappen, of de aanname klopt niet in jouw omgeving. Vraag de tester om bewijs. Kan jouw developer de fout niet reproduceren, dan bespreek je dat met de tester in plaats van het zelf af te doen.

Wat als twee bevindingen dezelfde oorzaak hebben?

Los dan de oorzaak op en niet elk symptoom afzonderlijk. Meerdere bevindingen over ontbrekende toegangscontroles wijzen bijvoorbeeld op een ontbrekende centrale check.

Moet ik na de fixes een hertest laten doen?

Ja, zeker voor kritieke en hoge bevindingen. Een hertest bevestigt dat de fix werkt en dat er geen eenvoudige omweg is. Spreek vooraf af of hij in de offerte zit.

Heb je een pentestrapport en weet je niet waar te beginnen? Neem contact op. Wij helpen met prioriteren en lossen ook op. Meer over testen en rapportages vind je op /security/pentest.