In veel organisaties begint security met inzicht: welke kwetsbaarheden hebben we en welke systemen vragen aandacht? Een vulnerability scan lijkt dan een logische eerste stap. De scan is relatief snel uit te voeren, betaalbaar en levert een concreet rapport op met kwetsbaarheden, CVE’s, scores en technische aanbevelingen.
Dat voelt overzichtelijk.
En precies daar zit het risico.
Een scanrapport kan de indruk geven dat je goed zicht hebt op de veiligheid van je omgeving. Zeker wanneer er weinig kritieke bevindingen in staan, ontstaat al snel het gevoel dat de grootste risico’s onder controle zijn.
Maar een vulnerability scan laat maar een deel van het risico zien.
Niet omdat de scan waardeloos is, maar omdat organisaties soms meer waarde hechten aan de uitkomst dan dat zij zouden moeten doen.
Een vulnerability scan geeft inzicht, maar geen volledig beeld van wat een aanvaller in de praktijk kan misbruiken.
Wat een vulnerability scan goed doet
Een vulnerability scan is nuttig wanneer je bekende kwetsbaarheden wilt vinden.
De scanner controleert systemen, applicaties of IP-adressen op herkenbare patronen. Denk aan verouderde software, bekende CVE’s, zwakke TLS-configuraties, ontbrekende security headers, openstaande poorten of duidelijke configuratiefouten.
Voor dat soort controles is vulnerability scanning waardevol.
Het wordt snel duidelijk welke systemen achterlopen. Inzicht in laaghangend fruit ontstaat direct. Bovendien ondersteunt het patchmanagement en maakt het mogelijk om periodiek te controleren of bekende problemen terugkeren.
Zeker in grotere omgevingen is dat belangrijk. Handmatig controleren of alle systemen up-to-date zijn, is meestal niet realistisch.
Het probleem ontstaat pas wanneer een scanrapport wordt gezien als bewijs dat de omgeving veilig is.
Dat is een stap te ver.
Waarom een schoon scanrapport niet hetzelfde is als veilig zijn
Een scanrapport kan schoon zijn, terwijl er toch nog steeds serieuze risico’s aanwezig zijn.
Dat komt doordat een scanner vooral kijkt naar bekende en herkenbare signalen. De scanner vergelijkt wat hij ziet met databases, signatures en vooraf ingestelde controles.
Maar veel echte risico’s zitten niet in bekende kwetsbaarheden.
Ze zitten in context;
Gebruikers die via een aangepaste ID toegang krijgen tot data van anderen. API’s die meer gegevens teruggeven dan nodig. Applicaties die betalingen voortijdig als afgerond beschouwen. Cloudrollen met meer rechten dan noodzakelijk. Interne systemen die bereikbaar zijn vanaf een plek waar dat niet zou moeten..
Dit soort problemen hebben niet altijd een CVE. Ze veroorzaken niet altijd foutmeldingen. Ze verschijnen ook zeker niet altijd in een scanrapport.
Toch kunnen ze grote impact hebben.
Daarom is een schoon scanrapport geruststellend, maar nooit voldoende bewijs dat een omgeving écht veilig is.
Het probleem zit in de interpretatie
De scan zelf is meestal niet het probleem.
Het probleem zit in de conclusie die daarna wordt getrokken.
Als een scan geen kritieke bevindingen heeft, klinkt het logisch om te zeggen:
“Er zijn geen grote risico’s gevonden.”
Maar eigenlijk zou je moeten zeggen:
“De scanner heeft geen bekende, zichtbare kritieke kwetsbaarheden gevonden.”
Dat is een belangrijk verschil.
De eerste zin klinkt alsof het risico laag is.
De tweede zin beschrijft wat er echt is vastgesteld.
Een vulnerability scan kijkt niet naar alles. Hij begrijpt meestal niet hoe jouw applicatie hoort te werken. Hij weet niet welke data gevoelig is en kent niet altijd de rollen, processen, koppelingen en uitzonderingen binnen je omgeving.
Daardoor kan een scanrapport technisch correct zijn, maar misleidend worden zodra je er bredere conclusies aan verbindt.
Waar vulnerability scanners vaak tekortschieten
Vulnerability scanners hebben moeite met risico’s die afhankelijk zijn van context, gedrag en samenhang.
Denk aan autorisatieproblemen. Een scanner kan zien dat een endpoint bestaat, maar begrijpt meestal niet of een specifieke gebruiker die data hoort te mogen zien. Bij websites komen dit soort risico’s vaak naar voren tijdens een webapplicatie pentest, omdat dan wordt gekeken naar rollen en autorisatie.
Denk aan businesslogica. Een scanner weet niet of twee kortingscodes samen een onbedoelde prijs opleveren, of dat een retourproces misbruikt kan worden.
Denk aan laterale beweging. Een scanner kan een kwetsbaarheid op een server detecteren, maar begrijpt niet altijd welke systemen te benaderen zijn als iemand eenmaal toegang heeft weten te verkrijgen tot die server.
Denk aan configuratiefouten. Een scanner kan zien of een poort openstaat en welke service erop draait, maar niet altijd beoordelen of dat logisch of gevaarlijk is binnen jouw omgeving.
Dat zijn precies de risico’s die in de praktijk veel impact kunnen hebben.
Een vulnerability scanner checkt op bekende patronen/kwetsbaarheden. Maar een aanvaller onderzoekt wat hij hiermee kan bereiken.
Voorbeeld: geen kritieke findings, toch een serieus risico
Stel dat een organisatie een klantportaal laat scannen.
Het scanrapport ziet er goed uit. Geen kritieke kwetsbaarheden. Een paar lage bevindingen rondom headers en informatieve meldingen. Technisch lijkt er weinig aan de hand.
Tijdens handmatig onderzoek blijkt iets anders.
Een normale gebruiker kan inloggen en zijn eigen documenten bekijken. In de interface ziet alles er correct uit. Maar in de API-responses staan interne document-ID’s. Door zo’n ID te gebruiken in een ander endpoint, kan dezelfde gebruiker documenten van een andere klant inzien.
De scanner vond geen kritieke kwetsbaarheid, omdat er geen bekende CVE of signature was.
De applicatie werkte technisch correct.
Maar de autorisatie was niet goed afgedwongen.
Dit is precies waarom vulnerability scan rapporten een vals gevoel van veiligheid kunnen geven. Het rapport lijkt geruststellend, terwijl het werkelijke risico in het gedrag van de applicatie zit.
Waarom compliance dit probleem kan versterken
Vulnerability scans passen goed binnen complianceprocessen.
Ze zijn aantoonbaar. Ze leveren rapporten op. Ze zijn periodiek uit te voeren. Ze geven duidelijke scores en bevindingen.
Dat maakt ze aantrekkelijk voor audits en managementrapportages.
Maar compliance kan onbedoeld het verkeerde beeld versterken. Als de vraag vooral is of er een scan is uitgevoerd, verschuift de aandacht van risico naar bewijs. Dat is ook waarom pentesten niet bij compliance mogen eindigen.
Dan wordt het scanrapport een vinkje.
Er is getest.
Er is een rapport.
De bevindingen zijn opgevolgd.
Dat is waardevol, maar het zegt nog niet genoeg over de werkelijke weerbaarheid van een omgeving.
Security begint pas echt bij de vervolgvraag:
Wat weten we nu nog niet?
Waarom false positives en false negatives beide riskant zijn
Scanrapporten bevatten vaak false positives: meldingen die technisch worden gesignaleerd, maar in de praktijk weinig impact hebben, of zelfs helemaal niet aanwezig zijn.
Dat kan leiden tot ruis.
Teams besteden tijd aan bevindingen die weinig risico vormen, terwijl belangrijkere problemen buiten beeld blijven. Na verloop van tijd ontstaat scanmoeheid: veel meldingen, veel uitzonderingen, weinig gevoel voor prioriteit.
Maar het omgekeerde is minstens zo belangrijk: false negatives.
Dat zijn risico’s die niet in het rapport verschijnen, maar wel aanwezig zijn. Juist die zijn gevaarlijk, omdat ze geen aandacht krijgen.
Een organisatie kan denken dat iets veilig is omdat er niets ontdekt is, terwijl de scanner het simpelweg niet kon beoordelen of detecteren.
Daarom is prioriteren op basis van alleen vulnerability scan resultaten meestal niet de juiste aanpak.
Wanneer vulnerability scans wél waardevol zijn
Vulnerability scans hebben absoluut waarde.
Ze zijn vooral nuttig voor structurele controle op bekende kwetsbaarheden. Denk aan patchmanagement, basisconfiguraties, externe blootstelling en periodieke monitoring.
Een scan helpt om sneller te zien waar systemen achterlopen of waar bekende kwetsbaarheden aanwezig zijn. Zeker bij grotere omgevingen hoort vulnerability scanning gewoon bij volwassen risicomanagement.
Een vulnerability scan moet gezien worden als signaleringsmiddel. Niet als een middel dat een volledig oordeel kan vellen over de beveiliging van een omgeving of applicatie.
Wat een pentest toevoegt
Tijdens een pentest wordt niet alleen gekeken naar kwetsbaarheden (die voortkomen uit vulnerability scans). Er wordt juist onderzocht hoe die kwetsbaarheden in de praktijk misbruikt kunnen worden en wat voor business impact dit heeft.
Dat maakt het verschil.
Waar een vulnerability scan vooral antwoord geeft op de vraag:
“Welke bekende kwetsbaarheden zijn zichtbaar?”
geeft een pentest antwoord op de vraag:
“Wat kan een aanvaller hiermee doen?”
Tijdens een pentest komen juist risico’s naar voren die context nodig hebben: autorisatieproblemen, businesslogica, configuratiefouten, laterale beweging en misbruik van bestaande functionaliteit.
Dat betekent niet dat een pentest een vulnerability scan vervangt. Het betekent dat beide een andere rol hebben. In het artikel over het verschil tussen een vulnerability scan en een pentest leggen we die rollen uitgebreider naast elkaar.
Hoe je voorkomt dat vulnerability scans schijnzekerheid geven
De oplossing is niet om vulnerability scans te negeren, maar om ze goed te interpreteren.
Een scanrapport moet het begin zijn van een gesprek, niet het eindpunt.
Welke bevindingen zijn echt relevant?
Welke systemen ontbreken in de scope?
Welke risico’s kan de scan niet beoordelen?
Waar is handmatig onderzoek nodig?
Welke kwetsbaarheden kunnen in combinatie met andere kwetsbaarheden meer impact hebben?
Door die vragen te stellen, voorkom je dat een scanrapport meer zekerheid suggereert dan het kan bieden.
Vooral bij applicaties, API’s, cloudomgevingen en interne netwerken is die nuance belangrijk. Daar zitten risico’s vaak in samenhang, rechten, datastromen en gedrag.
Precies de onderdelen waar een vulnerability scan beperkt zicht op heeft.
Van scanrapport naar realistisch risicobeeld
Vulnerability scans zijn nuttig, maar ze vertellen niet het hele verhaal.
Ze helpen om bekende problemen te vinden, maar missen vaak context, samenhang en misbruikscenario’s. Daardoor kan een omgeving veilig lijken op papier, terwijl er in de praktijk nog steeds serieuze risico’s aanwezig zijn.
Een goed securityproces gebruikt vulnerability scans daarom niet als eindpunt, maar als onderdeel van een bredere aanpak.
Scannen geeft overzicht.
Pentesten geeft inzicht.
Wie die twee uit elkaar houdt, voorkomt schijnzekerheid en krijgt een realistischer beeld van de werkelijke risico’s.
Wil je weten of jouw scanrapport voldoende zegt over de echte risico’s in je applicatie, API of cloudomgeving? Dan kan een gerichte pentest helpen om te onderzoeken wat een aanvaller in de praktijk daadwerkelijk kan bereiken.