340 kwetsbaarheden gevonden. Maar welke is vandaag gevaarlijk?

Marc Ligthart

Gepubliceerd op 27-05-2026

---

Waarom kwetsbaarheden tellen iets anders is dan risico’s beheersen

Een vulnerability scan (kwetsbaarhedenscan) levert vaak een indrukwekkend beeld op: dashboards vol meldingen, risicoscores en CVE-nummers, samengevat in rapportages van tientallen pagina’s met honderden bevindingen. Dat wekt urgentie op en soms ook het gevoel van controleverlies. Rode labels versterken dat beeld.

Toch zegt het aantal gevonden kwetsbaarheden op zichzelf weinig over het daadwerkelijke bedrijfsrisico. Een kwetsbaarhedenscan toont wat technisch zichtbaar is: systemen met aandachtspunten, verouderde componenten, kwetsbare afhankelijkheden of configuraties die beter kunnen. Waardevolle informatie, maar het vertelt niet welke bevinding vandaag misbruikt kan worden, welke kwetsbaarheid in deze specifieke omgeving het meeste risico oplevert of wat als eerste prioriteit verdient.

Veel organisaties meten meer dan ooit. Ze gebruiken scanners, dashboards, monitoring, audits, pentesten en periodieke assessments. Toch leidt al die informatie niet vanzelf tot betere besluitvorming. In sommige gevallen ontstaat juist het tegenovergestelde: hoe meer signalen beschikbaar zijn, hoe moeilijker het wordt om te bepalen welke er echt toe doen.

 Op papier is er dan veel inzicht. In de praktijk ontbreekt handelingsperspectief. Er zijn rapportages genoeg, maar de volgorde is niet scherp. Er zijn bevindingen genoeg, maar onvoldoende duiding. Iedereen ziet dat er iets moet gebeuren. Alleen is niet altijd duidelijk wat eerst moet gebeuren en waarom.

Juist in cybersecurity leidt die onduidelijkheid tot verkeerde prioritering, en daarmee tot reëel verhoogd risico.

 Het probleem is niet dat niemand kijkt

Het zou te makkelijk zijn om te concluderen dat organisaties hun security niet serieus genoeg nemen, dat IT-teams structureel achterlopen met patching of dat systemen door tijdgebrek, complexiteit en gebrek aan overzicht niet goed beheerd kunnen worden. Meestal ligt het genuanceerder.

De meeste securityteams weten heel goed dat kwetsbaarheden aandacht nodig hebben. Alleen vallen kwetsbaarheden niet altijd onder het eigenaarschap van beheerteams, waardoor bevindingen in de praktijk soms blijven liggen. Zij werken in een omgeving waarin bijna alles tegelijk urgent lijkt. Oude systemen moeten blijven draaien omdat ze gekoppeld zijn aan cruciale processen. Applicaties mogen niet zomaar uit omdat klanten of medewerkers ervan afhankelijk zijn. Leveranciers hebben hun eigen planning. De business wil snelheid. Change windows zijn beperkt. Ondertussen groeit de lijst met bevindingen sneller dan teams ze kunnen wegwerken.

Wie van buitenaf naar zo’n lijst kijkt, ziet misschien achterstallig onderhoud. Wie erin werkt, ziet een dagelijkse afweging tussen risico, capaciteit, continuïteit en haalbaarheid.

Vulnerability management is daardoor zelden alleen een technisch vraagstuk. Het is vooral een prioriteitsvraagstuk. Niet: staat deze kwetsbaarheid ergens op een lijst? Maar: vormt deze kwetsbaarheid in déze specifieke omgeving een risico dat nu voorrang verdient?

Die afweging wordt vaak onvoldoende gemaakt. Niet uit onwil, maar omdat veel processen nog steeds zijn ingericht op het verzamelen en classificeren van kwetsbaarheden. Een bevinding krijgt een score, daarna een prioriteit, daarna een ticket. Dat geeft structuur, maar het is niet hetzelfde als risicobeheersing.

Een aanvaller kijkt anders. Die denkt niet in de volgorde van het dashboard, maar in bruikbare routes: waar kan ik binnenkomen, waar kan ik verder bewegen en wat levert de verkregen toegang op? Dat kan gaan om data, verstoring, afpersing of een positie van waaruit later meer mogelijk wordt. Soms begint zo’n route bij een kritieke kwetsbaarheid. Soms bij iets wat op papier veel minder ernstig lijkt. Soms via social engineering, gestolen accounts, een vergeten extern systeem of een combinatie van kleine configuratiefouten.

Het onderscheid is wezenlijk. Een kwetsbaarhedenscan detecteert een technische afwijking. Een aanvaller zoekt een bruikbare mogelijkheid.

Een score is een beginpunt, geen eindbeslissing

Risicoscores zijn nuttig. Zonder classificatie wordt vulnerability management al snel onwerkbaar. Maar een score is geen volledige context.

Een kritieke kwetsbaarheid op een intern testsysteem zonder externe toegang vormt in de praktijk vaak minder risico dan een middelmatige kwetsbaarheid in een publiek toegankelijke applicatie met klantdata. Een extern bereikbare beheeromgeving met een zwakke configuratie kan urgenter zijn dan een theoretisch ernstigere kwetsbaarheid op een goed afgeschermd systeem. Veel ransomware-aanvallen beginnen bovendien niet met een CVSS 10-kwetsbaarheid, maar met gestolen credentials, een vergeten VPN-account of een publiek bereikbaar systeem dat al maanden niemand meer actief beheert.

Het helpt om verschillende lagen uit elkaar te houden.

Er is de technische vaststelling dat een systeem of applicatie kwetsbaar is. Er is exploitability: de vraag of misbruik praktisch mogelijk is, of er exploitcode beschikbaar is en of de kwetsbaarheid actief wordt misbruikt. Er is exposure: de vraag of het systeem bereikbaar is voor iemand met kwade bedoelingen. Er is impact: wat de gevolgen zijn als misbruik daadwerkelijk lukt. En er is waarschijnlijkheid: de kans dat deze factoren in de praktijk samenkomen binnen de specifieke context van de organisatie.

Bereikbaarheid speelt daarbij een grote rol. Een kwetsbaarheid kan technisch ernstig zijn, maar zonder realistische route naar het systeem blijft het praktische risico beperkt. Andersom kan een kwetsbaarheid met een lagere technische score juist urgent worden wanneer het systeem direct vanaf internet bereikbaar is, onderdeel is van een kritieke keten of misbruik leidt tot remote code execution. In de praktijk bepaalt niet alleen de ernst van de kwetsbaarheid het risico, maar vooral de combinatie van exploitability, exposure, bereikbaarheid en impact.

Veel organisaties lopen vast omdat deze lagen door elkaar gaan lopen. Een kwetsbaarheid wordt als ernstig behandeld omdat de technische score hoog is, terwijl de exposure beperkt is. Of andersom: een bevinding lijkt middelmatig, maar staat op een systeem dat vanaf internet bereikbaar is en toegang geeft tot gevoelige processen.

Ook actuele dreigingsinformatie verandert de prioriteit. Een kwetsbaarheid krijgt een andere urgentie wanneer bekend is dat deze actief wordt misbruikt, wanneer werkende exploits of proof-of-concept (PoC)-code beschikbaar zijn of wanneer de kwetsbaarheid aansluit bij aanvalstechnieken die op dat moment veel worden gezien. Dan gaat het niet meer om theoretische ernst, maar om de vraag of de kwetsbaarheid in de praktijk een aantrekkelijk doelwit is.

Dat is ook zichtbaar in de afwegingen van organisaties zoals het NCSC, waar niet alleen CVSS-scores worden meegewogen, maar ook factoren als actieve exploitatie, internetbereikbaarheid, aanwezige mitigaties

en de realistische kans op misbruik binnen een specifiek aanvalspad.

De technische eigenschappen van een kwetsbaarheid zijn dus maar één kant van het verhaal. Minstens zo belangrijk is waar het systeem staat, wie erbij kan, welke data erachter zit, welke koppelingen bestaan, of exploitatie realistisch is en of de kwetsbaarheid gecombineerd kan worden met andere bevindingen.

Soms wijst een bevinding op iets groters dan het losse technische probleem. Als hetzelfde type kwetsbaarheid steeds terugkomt, kan dat duiden op een onderliggende oorzaak: onduidelijk eigenaarschap, tijdelijke systemen die ongemerkt permanent worden, ontbrekende procesafspraken of securityteams die te laat worden meegenomen in ontwikkeling en beheer. Dan is het oplossen van de individuele bevinding nuttig, maar niet voldoende. De organisatie wordt pas structureel weerbaarder als ook de oorzaak achter het patroon wordt aangepakt.

Hier ligt het verschil tussen informatie en inzicht. Informatie zegt wat er gevonden is. Inzicht zegt wat het betekent voor de organisatie. Die tweede stap is waar de echte waarde ontstaat: niet door technische informatie te versimpelen, maar door die informatie te plaatsen in de context van de omgeving, de business en het waarschijnlijke aanvalsscenario.

Bestuurlijke sturing vraagt om vertaling

Cybersecurity is de afgelopen jaren definitief verschoven van een technisch naar een bestuurlijk onderwerp. NIS2 speelt daarin een grote rol, omdat digitale weerbaarheid nadrukkelijker bij bestuur en directie is komen te liggen. DORA doet hetzelfde binnen de financiële sector. Ook de AVG blijft relevant zodra persoonsgegevens, datalekken en meldplichten in het spel zijn.

Maar wetgeving is niet de enige reden. Klanten, toezichthouders, auditors, partners en investeerders stellen steeds vaker vragen over aantoonbare weerbaarheid. Zij willen weten of risico’s in beeld zijn, of maatregelen werken en of een organisatie kan uitleggen waarom bepaalde keuzes zijn gemaakt.

Daarmee raakt cybersecurity niet alleen IT, maar ook continuïteit, reputatie, klantvertrouwen en commerciële slagkracht. In sommige markten draagt aantoonbare weerbaarheid direct bij aan vertrouwen, klantbehoud en het binnenhalen van nieuwe opdrachten.

Tegelijk ontstaat een nieuw probleem. Bestuurders worden verantwoordelijk gehouden voor digitale risico’s, terwijl de informatie die zij ontvangen nog vaak technisch is georganiseerd. Ze krijgen rapportages, overzichten en dashboards, maar daarmee kunnen ze niet automatisch sturen.

Een bestuurder hoeft geen CVE-nummers te kennen. Hij hoeft niet te weten welke poort openstaat of waarom een bepaalde dependency verouderd is. Maar hij moet wel kunnen uitleggen waarom bepaalde risico’s met voorrang worden aangepakt en andere bewust later komen.

Als morgen een klant, auditor of toezichthouder vraagt hoe de organisatie digitale risico’s beheerst, is “we hebben een scan laten uitvoeren” geen sterk antwoord. Het betere antwoord gaat over de keuzes die op basis van die scan zijn gemaakt: welke systemen bedrijfskritisch zijn, welke kwetsbaarheden daadwerkelijk blootgesteld zijn, welke bevindingen praktisch misbruikbaar zijn en welke maatregelen het risico aantoonbaar verlagen.

Daarvoor moet techniek worden vertaald naar bestuurlijke taal: niet platgeslagen tot rood, oranje en groen, maar teruggebracht tot de kern. Wat kan er gebeuren? Hoe waarschijnlijk is dat? Wat is de mogelijke schade? En wat doen we eerst?

Pas dan wordt cybersecurity bestuurbaar. Niet omdat het bestuur alles technisch begrijpt, maar omdat het kan sturen op prioriteit, risico en verantwoordelijkheid.

De gevaarlijkste kwetsbaarheid staat niet altijd bovenaan

Veel organisaties vertrouwen op lijsten, scores, dashboards en classificaties. Dat brengt orde in een complex probleem. Maar aanvallers houden zich niet aan die volgorde.

Een aanvaller kiest niet automatisch de bevinding met de hoogste score. Een aanvaller kiest de route die werkt. Soms is dat een bekende kritieke kwetsbaarheid. Soms een vergeten subdomein. Soms een oud account. Soms een combinatie van matige configuraties. Soms een testomgeving die ooit tijdelijk online is gezet en nooit meer is opgeruimd.

Steeds vaker speelt identiteit daarin een grote rol. Veel moderne aanvallen draaien niet alleen om kwetsbare software, maar om toegang: accounts met te veel rechten, zwakke MFA-inrichting, serviceaccounts die breder inzetbaar zijn dan bedoeld of oude rechten die nooit zijn opgeruimd. In zo’n scenario zit de kwetsbaarheid niet in één CVE. Ze zit in de route die mogelijk wordt gemaakt door configuratie, rechten, bereikbaarheid en onvoldoende detectie.

Vulnerability management zonder aanvallersperspectief blijft daardoor beperkt. Je weet dan wat er technisch gevonden is, maar niet wat er praktisch misbruikt kan worden.

Met aanvallersperspectief bedoelen we niet dat security ingewikkelder moet worden gemaakt dan nodig. Het betekent dat kwetsbaarheden worden beoordeeld op bereikbaarheid, misbruikbaarheid, mogelijke vervolgstappen en wat er voor een aanvaller te halen of te verstoren valt. Pas dan wordt duidelijk welke bevindingen echt prioriteit verdienen.

Uiteindelijk wil een organisatie niet alleen weten hoeveel kwetsbaarheden zij heeft. Zij wil weten welke kwetsbaarheden haar daadwerkelijk kunnen raken. Welke bevindingen kunnen leiden tot echte schade? Welke maatregelen verlagen het risico het snelst? Waar is het team druk met security, maar niet met de juiste prioriteiten?

Dat vraagt om een andere manier van kijken. Niet dramatischer, wel realistischer.

Van momentopname naar continu beeld

Een goede, scenario-gedreven pentest blijft een van de krachtigste manieren om dat zichtbaar te maken. Niet omdat een pentest simpelweg een uitgebreidere scan is, maar omdat hij laat zien hoe kwetsbaarheden zich in de praktijk gedragen.

Een pentest maakt duidelijk welke aannames niet kloppen, welke maatregelen minder effectief zijn dan gedacht, welke bevindingen in combinatie ineens zwaarder wegen en welke route een aanvaller waarschijnlijk zou kiezen. Daar zit de waarde van handmatig testen en specialistische interpretatie.

Maar niet elke pentest levert dat niveau van inzicht op. De waarde hangt sterk af van kwaliteit, scope, timing en de mate waarin het onderzoek scenario-gedreven is opgezet. Een checklist-pentest kan nuttig zijn, maar geeft niet hetzelfde inzicht als een test waarin daadwerkelijk wordt gekeken naar aanvalspaden, realistische misbruikbaarheid en onderliggende oorzaken.

Bovendien blijft een pentest altijd een momentopname.

Moderne IT-omgevingen veranderen continu. Applicaties worden aangepast. Cloudomgevingen groeien. Nieuwe systemen komen online. Leveranciers krijgen koppelingen. Oude testomgevingen blijven toch bereikbaar. Wat vorige maand geen risico was, kan vandaag opnieuw zichtbaar zijn. Wat tijdens een pentest goed stond, kan na een wijziging weer kwetsbaar worden.

Alleen periodiek testen is daarom niet genoeg. Maar alleen continu scannen ook niet.

De waarde zit in de combinatie. Pentesten geven diepte. Continue monitoring geeft actualiteit. Dreigingsinformatie geeft urgentie. Validatie geeft betekenis. Het aanvallersperspectief helpt bepalen wat echt prioriteit verdient.

Dit verklaart waarom volwassen securityprogramma’s steeds meer bewegen richting exposure management: het continu begrijpen, prioriteren en valideren van risico’s vanuit het perspectief van een realistische aanval. Daarin komen attack surface management, vulnerability management, threat intelligence, applicatietesten en validatie samen.

Hier ontstaat het verschil tussen een lijst met bevindingen en daadwerkelijk inzicht in risico.

Als er honderden kwetsbaarheden openstaan, is het zelden eerlijk om één schuldige aan te wijzen. IT heeft vaak te weinig capaciteit en te veel afhankelijkheden. Securityteams zien de risico’s, maar hebben niet altijd de positie om prioriteiten af te dwingen. Het bestuur is formeel verantwoordelijk, maar krijgt informatie vaak niet in een vorm waarmee het goed kan sturen. De business wil snelheid en continuïteit, maar onderschat soms wat technische schuld op termijn betekent.

Iedereen heeft een deel van de puzzel. Niemand heeft vanzelf het volledige beeld.

De vraag naar schuld is minder interessant dan de vraag naar verantwoordelijkheid. Die verantwoordelijkheid begint op het moment dat een organisatie niet langer genoegen neemt met een lijst bevindingen, maar wil begrijpen wat die bevindingen betekenen.

Daarbij gaat het niet om een extra classificatiekolom of een nieuw dashboard. Het gaat om een inhoudelijke vertaling: welke risico’s zijn in déze omgeving reëel, welke zijn vooral theoretisch, welke systemen zijn bedrijfskritisch, welke aanvalsroutes zijn aannemelijk en welke acties leveren aantoonbaar de meeste risicoreductie op?

Dat vraagt om een andere manier van werken. Niet meer alleen kwetsbaarheden verzamelen, classificeren en doorzetten, maar kwetsbaarheden beoordelen in samenhang met de omgeving, de business en het realistische aanvalsscenario.

Pas dan ontstaat echte prioriteit. Zonder die prioriteit blijven securityteams vaak druk, maar niet noodzakelijk effectief.

De betere startvraag

Elke organisatie heeft kwetsbaarheden. Dat is geen nieuws en ook geen schande. Wie systemen gebruikt, applicaties ontwikkelt, cloudomgevingen beheert of onderdeel is van complexe ketens van leveranciers en dienstverleners, heeft kwetsbaarheden. De relevante vraag is niet óf ze bestaan, maar welke er echt toe doen.

Daar zit het verschil tussen een technisch overzicht en risicobeheersing. Een technisch overzicht laat zien wat er gevonden is. Risicobeheersing laat zien wat dat betekent, wat eerst moet gebeuren en waarom.

Een goed gesprek over kwetsbaarheden begint daarom niet met de vraag welke tool wordt gebruikt. Ook niet met de vraag hoeveel findings er openstaan. En zelfs niet met de vraag of er recent een pentest is uitgevoerd.

Het begint met een eerlijkere vraag: heeft de organisatie haar reële risico’s scherp genoeg in beeld? Niet alleen op papier. Niet alleen in een dashboard. Niet alleen als export uit een scanner. Maar bekeken vanuit het perspectief van iemand die misbruik wil maken van wat zichtbaar, bereikbaar of verkeerd ingericht is.

Als het antwoord nee is, is dat geen verwijt. Het is een startpunt.

Misschien begint dat met een scenario-gedreven pentest. Misschien met het continu in kaart brengen van het externe aanvalsoppervlak. Misschien met applicatietesten of het opnieuw beoordelen van bestaande bevindingen vanuit daadwerkelijke misbruikbaarheid.

Maar begin niet met meer ruis. Begin met begrijpen wat een aanvaller vandaag ziet.

Want 340 kwetsbaarheden op een lijst is vervelend. Maar het is niet het echte probleem.

Het echte probleem is dat niemand met zekerheid kan zeggen welke daarvan vandaag gevaarlijk is.

Dat is precies waar wij bij SECWATCH mee beginnen.