Pentest of vulnerability scan: wat is het verschil en wanneer zet je wat in?

Pentest en vulnerability scan worden in offertes en beleidsstukken vaak door elkaar gebruikt, en dat leidt tot verkeerde verwachtingen. Het zijn twee verschillende dingen: de een is een geautomatiseerde controle op bekende zwakke plekken, de ander is handwerk waarbij iemand daadwerkelijk probeert binnen te komen. Wie een pentest inkoopt en een scanrapport terugkrijgt, betaalt te veel. Wie denkt met een maandelijkse scan aan een auditeis te voldoen, komt er soms pas bij de audit achter dat dat niet klopt.

Wat een vulnerability scan doet

Een vulnerability scan is een geautomatiseerd proces. Een tool zoals Nessus, Qualys of OpenVAS benadert je systemen, stelt vast welke software en versies draaien, en vergelijkt dat met databases van bekende kwetsbaarheden. Het resultaat is een rapport met gevonden issues, meestal gesorteerd op CVSS-score.

De kracht zit in snelheid en herhaalbaarheid. Een scan over een heel netwerk kost uren, niet weken, en kan wekelijks of dagelijks draaien. Daarmee is het bij uitstek geschikt om te bewaken dat patches worden uitgerold en dat er geen vergeten servers meedraaien.

De beperking zit in wat een scanner kan zien. Hij herkent bekende kwetsbaarheden in bekende software. Hij begrijpt niet wat jouw applicatie doet, dus hij ziet niet dat gebruiker A het dossier van gebruiker B kan opvragen door een nummer in de URL te veranderen. Dat soort fouten zit in de bedrijfslogica en staat in geen enkele database.

Wat een pentest doet

Bij een pentest onderzoekt een tester je omgeving met dezelfde denkwijze als een aanvaller. Er wordt verkend, gecombineerd en doorgestoten. Een pentester gebruikt ook scanners, maar dan als startpunt in plaats van als eindproduct.

Het verschil zit in het combineren. Een scanner meldt drie losse bevindingen met een lage score. Een pentester ziet dat de eerste hem een geldige sessie oplevert, de tweede toegang geeft tot een intern koppelvlak en de derde daar een commando laat uitvoeren, en toont daarmee aan dat de combinatie wel degelijk tot datalek leidt. Dat inzicht komt niet uit een tool.

Een pentester vindt bovendien de categorieën die scanners structureel missen: verbroken toegangscontrole, zwakke plekken in authenticatie en sessiebeheer, fouten in de bedrijfslogica zoals een korting die je twee keer kunt toepassen, en misconfiguraties die alleen in samenhang problematisch zijn.

Diepgang, doorlooptijd en kosten

Een vulnerability scan is goedkoop, snel en oppervlakkig. Een pentest is duurder, duurt dagen tot weken en levert diepgang. Dat is geen waardeoordeel: het zijn instrumenten met een ander doel.

De rapportage verschilt navenant. Een scanrapport is een lijst bevindingen met scores. Een pentestrapport beschrijft per bevinding hoe de tester te werk ging, wat de aantoonbare impact is voor jouw organisatie, en welk herstel wordt geadviseerd. Bij een goed rapport kun je als ontwikkelaar de bevinding reproduceren.

Wanneer je wat inzet

Zet vulnerability scanning in als continue bewaking. Draai wekelijks of maandelijks over je externe en interne systemen, en koppel de uitkomsten aan je patchproces. Meet niet het aantal bevindingen maar de tijd tot herstel, want dat getal zegt iets over hoe je organisatie werkt.

Zet een pentest in op momenten die ertoe doen. Voor de livegang van een nieuwe applicatie of een grote release. Bij een wijziging in de architectuur, bijvoorbeeld een migratie naar de cloud of een nieuw koppelvlak. Periodiek, meestal jaarlijks, op je belangrijkste applicaties. En wanneer een klant, verzekeraar of norm erom vraagt.

Wat normen en assessments vragen

Hier zit voor veel organisaties de praktische reden om het onderscheid scherp te hebben. Het DigiD-assessment verwacht een penetratietest die aansluit op de scope, niet alleen een scanrapport. Bij ISO 27001 en SOC 2 gaat het om het aantoonbaar beheersen van technische kwetsbaarheden, waarbij scanning en pentesting elkaar aanvullen: de scan levert de continue bewaking, de pentest de periodieke diepgang. Wie alleen scant, krijgt bij die audits regelmatig de vraag waar de diepere toetsing blijft.

Wat je in beide gevallen moet regelen

Het rapport is niet het einde. Bij een scan gaat het om triage: welke bevindingen zijn echt van toepassing, welke zijn false positives, wat pak je eerst op. Bij een pentest gaat het om herstel en hertest. Een bevinding die is opgelost maar nooit opnieuw is getoetst, blijft in een audit een openstaand punt.

Leg bij een pentest vooraf de scope, de testperiode en de spelregels vast: welke systemen mogen worden benaderd, welke technieken zijn toegestaan, wie is bereikbaar als er iets omvalt. Zonder die afspraken wordt een test halverwege stilgelegd, of blijft juist het interessantste deel onbeproefd.

Secure Audit voert penetratietests uit op webapplicaties, API's en infrastructuur, en beoordeelt in audits of scanning en pentesting samen voldoende dekking geven. Neem contact op als je wilt weten welke combinatie bij jouw omgeving en normkader past.