De Vulnpocalypse: kwetsbaarheden groeien sneller dan ons vermogen om ze te beheersen

Waarom AI, zero-days en de economie van softwareonderhoud het traditionele kwetsbaarhedenbeheer fundamenteel onder druk zetten.

De cybersecuritysector heeft jarenlang geïnvesteerd in het sneller ontdekken van kwetsbaarheden. We beschikken over steeds betere scanners, uitgebreidere databases, geautomatiseerde analyses en inmiddels AI-systemen die zelfstandig beveiligingsproblemen kunnen identificeren. Maar er is een fundamentele vraag die veel minder aandacht krijgt: wat gebeurt er wanneer onze capaciteit om kwetsbaarheden te ontdekken structureel groter wordt dan ons vermogen om ze daadwerkelijk te verhelpen?

Het antwoord raakt niet alleen cybersecurity. Het raakt de economische houdbaarheid van softwareontwikkeling, de inrichting van enterprise-architecturen en uiteindelijk de bestuurlijke verantwoordelijkheid voor digitale continuïteit.

Drie recente bronnen maken deze spanning zichtbaar: de gepubliceerde advisories van het Zero Day Initiative, het Microsoft Patch Tuesday- en ZDI-dashboard van CybersecurityCompass en de publicatie The Four Horsemen of the Vulnpocalypse van Juan Pablo Castro.

Gezamenlijk illustreren zij een ontwikkeling die een fundamentele heroverweging van kwetsbaarhedenbeheer rechtvaardigt. Niet omdat iedere kwetsbaarheid onmiddellijk gevaarlijk is. Maar omdat de verhouding tussen ontdekking, exploitatie, mitigatie en herstel aan het veranderen is.

1. De paradox van vooruitgang: meer ontdekken betekent niet automatisch veiliger worden

Traditioneel berust kwetsbaarhedenbeheer op een betrekkelijk eenvoudig proces: een kwetsbaarheid wordt ontdekt, geregistreerd, beoordeeld, geprioriteerd en uiteindelijk verholpen. Dit proces veronderstelt impliciet dat organisaties voldoende capaciteit hebben om de instroom van relevante kwetsbaarheden te verwerken. Die veronderstelling verdient heronderzoek.

Het Zero Day Initiative publiceert voortdurend nieuwe kwetsbaarheden in besturingssystemen, applicaties, infrastructuurproducten en softwarecomponenten. In de geraadpleegde ZDI-publicaties over 2026 waren tot eind oktober 847 advisories zichtbaar. Daaronder bevinden zich meldingen over traditionele enterprise-software, maar ook over AI-gerelateerde componenten zoals MLflow en CrewAI.

Tegelijkertijd laat het Microsoft Patch Tuesday-dashboard een sterke groei van geregistreerde CVE's zien. De onderliggende dataset bevat:

Periode	Microsoft CVE-records
2024	1.022
2025	1.151
Januari tot en met oktober 2026	4.187

Deze cijfers moeten zorgvuldig worden geïnterpreteerd. Het aantal geregistreerde kwetsbaarheden is niet hetzelfde als het aantal kwetsbaarheden dat daadwerkelijk kan worden misbruikt. Evenmin betekent iedere CVE een afzonderlijke herstelactie. Een software-update kan tientallen kwetsbaarheden verhelpen; omgekeerd kan één kwetsbaarheid honderden systemen, afhankelijkheden en bedrijfsprocessen raken. Ook kunnen veranderende onderzoeksactiviteiten, registratiepraktijken en publicatieprocessen de aantallen beïnvloeden.

Toch maakt de ontwikkeling één probleem zichtbaar: de hoeveelheid beveiligingsinformatie die organisaties moeten verwerken groeit, terwijl hun capaciteit om software te onderhouden, te testen en gecontroleerd te wijzigen niet vanzelf meegroeit. Daarmee ontstaat een fundamentele asymmetrie. Aan de ontdekkingskant zorgen automatisering en AI voor schaalvergroting; aan de herstelkant blijven organisaties afhankelijk van ontwikkelaars, leveranciers, architectuurkeuzes, testomgevingen, onderhoudsvensters en complexe afhankelijkheden. Het ontdekken van een kwetsbaarheid is daarmee steeds minder hetzelfde als het oplossen van een beveiligingsprobleem.

2. De vier ruiters van de Vulnpocalypse

Juan Pablo Castro beschrijft in The Four Horsemen of the Vulnpocalypse vier krachten die gezamenlijk druk uitoefenen op traditionele beveiligingsprocessen. Het artikel is een auteursessay en geen empirisch gevalideerd voorspellingsmodel. De waarde ligt vooral in de manier waarop het verschillende oorzaken van kwetsbaarhedenrisico uit elkaar haalt.

Pestilence: de groeiende hoeveelheid kwetsbaarheden. De eerste ruiter vertegenwoordigt de toenemende hoeveelheid kwetsbaarheden die onderzoekers en beveiligingssystemen identificeren. AI kan deze ontwikkeling versterken: waar traditionele beveiligingsonderzoekers handmatig code analyseren, kunnen moderne systemen grote hoeveelheden broncode onderzoeken, patronen herkennen en mogelijke kwetsbaarheden identificeren. Het probleem is echter niet uitsluitend het aantal ontdekkingen, maar het moment waarop de instroom van relevante herstelopgaven structureel groter wordt dan de beschikbare herstelcapaciteit.

We kunnen dit beschrijven met een eenvoudig wachtrijmodel. Laat λ de gemiddelde instroom van herstelopgaven zijn, μ de gemiddelde verwerkingscapaciteit en B(t) de openstaande werkvoorraad op tijdstip t. Dan geldt, zolang er voldoende werk beschikbaar is:

dB(t)/dt = λ − μ

Wanneer λ langdurig groter is dan μ, groeit de achterstand; wanneer λ kleiner is dan μ, kan de achterstand afnemen. Dit model is een vereenvoudiging: herstelopgaven verschillen in complexiteit, kunnen parallel worden uitgevoerd en zijn niet altijd onafhankelijk. Maar het illustreert een belangrijke bestuurlijke realiteit: een organisatie kan haar kwetsbaarhedenproces uitstekend uitvoeren en toch structureel achteropraken wanneer de instroom groter blijft dan haar capaciteit. Meer scanners vergroten dan mogelijk vooral de zichtbaarheid van het probleem, niet noodzakelijk het vermogen om het op te lossen.

War: de toenemende snelheid van exploitatie. De tweede ruiter betreft de tijd tussen het bekend worden van een kwetsbaarheid en de mogelijkheid om deze daadwerkelijk te misbruiken. AI verandert hier vooral de economische toegankelijkheid van bepaalde technische vaardigheden. Geavanceerde modellen kunnen onderzoekers ondersteunen bij codeanalyse, proof-of-concepts te ontwikkelen en exploitketens te onderzoeken.

De cijfers die Anthropic's Frontier Red Team publiceerde in GLM-5.3 and the spread of advanced cyber capabilities maken dit concreet. Op ExploitBench, dat meet hoe goed modellen kwetsbaarheden in de V8-engine van Google Chrome kunnen exploiteren, ontwikkelde GLM-5.3 end-to-end exploits in 50 van de 410 pogingen; Claude Mythos Preview deed dat in 56 van de 410 pogingen. Op de interne Binary Exploitation-benchmark bereikte GLM-5.3 volledige control-flow-hijacks in 4% van de trials en Mythos Preview in 6%, terwijl eerdere modellen zoals Claude Opus 4.6 en GLM-5.2 in geen van de trials slaagden. Een betekenisvolle drempel is overschreden.

Dit zijn geen universele percentages voor het aanvallen van willekeurige organisaties, maar benchmarkresultaten onder specifieke omstandigheden. Ze laten wel zien dat AI-systemen inmiddels taken kunnen uitvoeren die voorheen aanzienlijke specialistische kennis vereisten. Dat heeft economische gevolgen: wanneer bepaalde onderzoeks- en ontwikkeltaken goedkoper worden, kunnen meer partijen deze uitvoeren, en verandert mogelijk de verhouding tussen de kosten van aanvallen en verdedigen. Voor organisaties is daarom niet alleen de ernst van een kwetsbaarheid relevant; ook de beschikbare tijd om effectieve tegenmaatregelen te treffen wordt belangrijker.

Famine: kwetsbaarheden waarvoor geen patch beschikbaar is. De derde ruiter is misschien wel de meest onderschatte. Niet iedere gepubliceerde kwetsbaarheid beschikt over een beschikbare, effectieve leverancierspatch. Soms is een leverancier nog bezig met onderzoek, soms is een product niet langer ondersteund, soms blijkt een oorspronkelijke patch onvolledig, en soms vereist de oplossing een ingrijpende architectuurwijziging. In dergelijke situaties kan een organisatie niet simpelweg besluiten sneller te patchen: de benodigde oplossing bestaat immers nog niet, of kan niet zonder aanzienlijke gevolgen worden toegepast.

Dit is waar architectuur en beveiliging elkaar raken. Netwerksegmentatie, privilegebeperking, configuratiewijzigingen en virtual patching kunnen de blootstelling verminderen, maar moeten niet worden verward met het daadwerkelijk verwijderen van de kwetsbaarheid. Een WAF-regel kan een bekende aanval blokkeren zonder dat de onderliggende kwetsbare code verandert; een netwerkregel kan een aanvalspad beperken zonder dat het product veilig is geworden. Een organisatie moet daarom onderscheid maken tussen een kwetsbaarheid die is opgelost en een kwetsbaarheid waarvan het risico tijdelijk is beperkt. Dat verschil is essentieel voor auditbaarheid, risicomanagement en bestuurlijke verantwoording.

Death: het onvermogen om tijdig te herstellen. De vierde ruiter vertegenwoordigt de operationele werkelijkheid van organisaties. Zelfs wanneer een patch beschikbaar is, betekent dat niet dat deze onmiddellijk kan worden geïnstalleerd. Een wijziging kan afhankelijk zijn van compatibiliteit met andere applicaties, beschikbaarheid van testomgevingen, ondersteuning door leveranciers, onderhoudsvensters, beschikbaarheid van ontwikkel- en beheerteams en continuïteitseisen van bedrijfskritische processen.

In complexe enterprise-omgevingen kan de technische installatie relatief eenvoudig zijn, terwijl de organisatorische uitvoering weken duurt. Hier ontstaat een tweede asymmetrie: een aanvaller hoeft slechts één bruikbaar aanvalspad te vinden, terwijl een organisatie meerdere systemen, afhankelijkheden en bedrijfsprocessen veilig moet blijven beheren. Dat betekent niet dat verdediging per definitie onmogelijk is, maar wel dat traditionele patchprocessen onvoldoende zijn wanneer zij losstaan van architectuur, softwareontwikkeling en operationele continuïteit.

3. AI verandert niet alleen de aanval, maar ook de software-economie

De discussie over AI en cybersecurity concentreert zich vaak op de vraag of AI nieuwe aanvallen mogelijk maakt. Dat is relevant, maar niet de volledige vraag. De diepere verandering betreft de economie van softwareonderzoek.

Historisch vereiste het vinden van complexe kwetsbaarheden aanzienlijke menselijke expertise en onderzoekstijd. AI kan bepaalde onderdelen van dat proces automatiseren of versnellen. Dat heeft minstens drie gevolgen: bestaande kwetsbaarheden kunnen sneller zichtbaar worden, exploitmogelijkheden kunnen voor een grotere groep onderzoekers toegankelijk worden, en softwareleveranciers kunnen geconfronteerd worden met een hogere instroom van meldingen die onderzocht, gevalideerd en verholpen moeten worden.

Maar AI vergroot niet automatisch in dezelfde mate de capaciteit om software veilig te herstellen. Een AI-model kan een kwetsbaarheid identificeren en een codewijziging voorstellen, maar daarmee is nog niet bewezen dat de wijziging functioneel correct is, geen regressies introduceert en veilig kan worden uitgerold. Het verschil tussen een gegenereerde patch en een betrouwbaar herstelproces blijft fundamenteel. AI kan de kosten van ontdekking verlagen, terwijl de kosten van verantwoord herstel grotendeels afhankelijk blijven van de kwaliteit van de softwarearchitectuur en de ontwikkelorganisatie.

Dit leidt tot een ongemakkelijke conclusie: organisaties die investeren in AI-gedreven kwetsbaarhedendetectie zonder tegelijkertijd hun herstelcapaciteit te moderniseren, kunnen hun eigen operationele achterstand vergroten. Ze worden beter in het identificeren van risico's, maar niet noodzakelijk beter in het beheersen ervan.

4. De verborgen oorzaak: onze softwarearchitecturen produceren onderhoudsschuld

Een belangrijk deel van de kwetsbaarhedenproblematiek ontstaat niet tijdens het patchproces, maar jaren eerder, bij architectuur- en ontwerpbeslissingen. Elke aanvullende dependency introduceert mogelijke kwetsbaarheden; elke afwijkende configuratie vergroot de onderhoudscomplexiteit; elke verouderde component kan toekomstige herstelmogelijkheden beperken; elke koppeling tussen systemen kan nieuwe aanvalspaden creëren.

Dat betekent niet dat minder software automatisch veiliger is. Het betekent dat de samenstelling en beheersbaarheid van de softwareketen invloed hebben op de toekomstige beveiligingskosten. Neem een organisatie met honderden applicaties, verschillende programmeertalen, uiteenlopende deploymentprocessen en tientallen versies van dezelfde middleware. Zelfs wanneer alle teams hun individuele verantwoordelijkheden correct uitvoeren, ontstaat op organisatieniveau een enorme coördinatieopgave. Een kwetsbaarheid in een gedeelde component kan tientallen applicaties raken; wanneer iedere applicatie een afwijkende versie gebruikt, vereist herstel mogelijk tientallen afzonderlijke wijzigingen. Wanneer dezelfde applicaties gebruikmaken van gestandaardiseerde, centraal beheerde componenten, kan de herstelopgave aanzienlijk kleiner zijn.

Hier ligt een belangrijke rol voor enterprise-architectuur. Niet als documentatiefunctie, maar als instrument om structureel de hoeveelheid beveiligingswerk te verminderen. Een goede enterprise-architectuur verlaagt niet alleen technische complexiteit; zij verlaagt ook de toekomstige kosten van beveiligingsonderhoud. Dat is een economisch argument voor standaardisatie, lifecyclemanagement en beheersbare softwareafhankelijkheden.

5. Waarom CVSS alleen niet langer volstaat

Veel organisaties prioriteren kwetsbaarheden nog steeds voornamelijk op basis van CVSS-scores. Dat is begrijpelijk: CVSS biedt een gestandaardiseerde manier om technische ernst te beschrijven. Maar technische ernst is niet hetzelfde als operationeel risico. Een kwetsbaarheid met CVSS 9,8 in een volledig geïsoleerd, niet-bereikbaar systeem kan onder bepaalde omstandigheden minder urgent zijn dan een kwetsbaarheid met CVSS 7,5 in een publiek toegankelijke authenticatievoorziening.

Daarom moeten organisaties meerdere dimensies combineren: technische ernst (wat kan er gebeuren wanneer de kwetsbaarheid wordt misbruikt), exploitatiebewijs (wordt de kwetsbaarheid daadwerkelijk aangevallen), bereikbaarheid (bestaat er een uitvoerbaar aanvalspad), bedrijfsimpact (welke gegevens, processen of diensten kunnen worden geraakt) en herstelbaarheid (welke maatregelen zijn beschikbaar en hoe snel kunnen deze aantoonbaar worden toegepast).

Frameworks zoals CVSS, EPSS en CISA KEV ondersteunen verschillende onderdelen van deze beoordeling, maar geen van deze bronnen beschikt zelfstandig over de volledige context van een organisatie. Die context moet uit de eigen architectuur, configuraties, identiteiten en bedrijfsprocessen komen. Daarmee verschuift kwetsbaarhedenbeheer van een voornamelijk administratief proces naar een architectuurgedreven risicodiscipline.

6. De volgende stap: van vulnerability management naar exposure engineering

De traditionele benadering richt zich op kwetsbaarheden; een toekomstbestendige benadering moet zich richten op daadwerkelijke blootstelling. Dat verschil is groter dan het lijkt. Een kwetsbaarheid is een technische eigenschap van een systeem of component; blootstelling ontstaat wanneer die kwetsbaarheid binnen een concrete omgeving onder relevante voorwaarden kan worden bereikt of misbruikt.

Daarom stel ik een verschuiving voor naar exposure engineering: een engineeringdiscipline die kwetsbaarhedeninformatie voortdurend verbindt met assetinventarisatie, configuraties, identiteiten, aanvalspaden, herstelmaatregelen en controleerbaar bewijs. Een dergelijk proces bestaat uit vijf samenhangende functies.

1. Continue identificatie. Verzamel relevante kwetsbaarhedeninformatie uit meerdere bronnen (ZDI, MSRC, CISA KEV, leveranciersadvisories en softwarecomponentanalyses). Registreer niet alleen CVE-nummers, maar ook leveranciersidentificaties, productversies, publicatiedata en herstelstatus. Een melding zonder CVE mag niet automatisch buiten beeld verdwijnen.
2. Contextuele analyse. Bepaal welke kwetsbaarheden daadwerkelijk betrekking hebben op de gebruikte systemen. Combineer software-inventarisatie met configuraties, netwerkbereikbaarheid en identiteitsrelaties. Maak onzekerheid expliciet: een onbekende configuratie mag niet worden geïnterpreteerd als een veilige configuratie.
3. Aanvalspadanalyse. Onderzoek of een kwetsbaarheid onderdeel kan worden van een realistische aanvalsketen. Een geïsoleerde kwetsbaarheid krijgt een andere betekenis wanneer deze toegang geeft tot een serviceaccount met uitgebreide rechten. Daarom zijn Zero Trust-principes, least privilege en identiteitsbeveiliging essentieel.
4. Gecontroleerde mitigatie en herstel. Kies maatregelen op basis van het daadwerkelijke risico. Dat kan betekenen dat een patch direct wordt geïnstalleerd, maar ook dat tijdelijk netwerktoegang wordt beperkt, functionaliteit wordt uitgeschakeld of aanvullende monitoring wordt ingericht. De gekozen maatregel moet aantoonbaar effectief zijn.
5. Continue verificatie. Controleer of de kwetsbaarheid daadwerkelijk is verholpen of de blootstelling aantoonbaar is verminderd. Een succesvolle deployment is niet automatisch bewijs van herstel; een gesloten ticket evenmin. Pas wanneer de relevante technische toestand is gecontroleerd, kan het herstelproces verantwoord worden afgerond.

7. De rol van autonome AI-agents: versnelling onder controle

AI-agents kunnen een belangrijke bijdrage leveren aan exposure engineering: zij kunnen advisories analyseren, softwarecomponenten correleren, technische documentatie onderzoeken en herstelvoorstellen voorbereiden. Maar juist hier ontstaat een nieuwe categorie beveiligingsrisico's. Een agent die zelfstandig repositories kan wijzigen, deployments kan uitvoeren of netwerkconfiguraties kan aanpassen, beschikt over operationele bevoegdheden. Wanneer die agent wordt beïnvloed door kwaadaardige instructies, onbetrouwbare configuraties of gecompromitteerde dependencies, kan zijn automatiseringscapaciteit tegen de organisatie worden gebruikt.

Het Hugging Face-incident dat OpenAI in 2026 beschreef, illustreert waarom agentbeveiliging verder moet gaan dan modelprompts te beperken. Ook ondersteunende infrastructuur, gedeelde opslag, netwerktoegang en service-identiteiten maken deel uit van de beveiligingsgrens.

Daarom moet de inzet van autonome agents worden gebaseerd op een aantal harde architectuurprincipes: agents krijgen uitsluitend de bevoegdheden die nodig zijn voor hun taak; gevoelige acties worden buiten het model geautoriseerd; credentials zijn kortlevend en beperkt in reikwijdte; wijzigingen worden gelogd en zijn herleidbaar; onbetrouwbare code en configuraties worden geïsoleerd verwerkt; en herstelacties worden onafhankelijk gevalideerd. Het doel is niet om AI zoveel mogelijk autonomie te geven, maar om automatisering veilig genoeg te maken om verantwoord op grotere schaal te kunnen inzetten.

8. De economische dimensie: wie betaalt voor structureel softwareonderhoud?

De kwetsbaarhedenproblematiek raakt ook aan een bredere economische vraag: wie draagt de kosten van softwareonderhoud? Softwareleveranciers, open-sourceontwikkelaars, commerciële afnemers en eindgebruikers hebben verschillende belangen. Een organisatie kan profiteren van een open-sourcecomponent zonder rechtstreeks bij te dragen aan het onderhoud ervan; een softwareleverancier kan een product jarenlang distribueren terwijl de toekomstige onderhoudslast grotendeels buiten de oorspronkelijke ontwikkelkosten valt; en organisaties kunnen complexe afhankelijkheden opbouwen zonder de toekomstige beveiligingskosten volledig mee te nemen in hun investeringsbeslissingen.

Dit creëert een spanning tussen de partijen die profiteren van software en degenen die verantwoordelijk zijn voor het veilig houden ervan. De Europese Cyber Resilience Act probeert deze verhouding gedeeltelijk te corrigeren door beveiligingsverplichtingen op te leggen aan marktdeelnemers die producten met digitale elementen op de Europese markt brengen. De CRA neemt de kwetsbaarhedenproblematiek niet weg, maar maakt duidelijk dat softwarebeveiliging niet uitsluitend een verantwoordelijkheid is van de organisatie die uiteindelijk een patch installeert. Ook productontwerp, onderhoud, ondersteuning en de afhandeling van kwetsbaarheden behoren tot de verantwoordelijkheid van de softwareketen. Security wordt daarmee steeds nadrukkelijker een onderdeel van productverantwoordelijkheid en economische governance.

9. Wat bestuurders en CISO's anders moeten gaan meten

Wanneer organisaties uitsluitend sturen op aantallen openstaande kwetsbaarheden, ontstaat een onvolledig beeld. Een dalende CVE-achterstand kan betekenen dat risico's daadwerkelijk zijn verminderd, maar het kan ook betekenen dat kwetsbaarheden administratief zijn gesloten, systemen buiten de inventaris vallen of uitzonderingen zijn geaccepteerd zonder voldoende technische onderbouwing. Daarom zijn andere indicatoren noodzakelijk.

• Time to effective mitigation: hoeveel tijd verstrijkt tussen het vaststellen van een relevante blootstelling en het moment waarop een effectieve maatregel aantoonbaar werkt?
• Time to verified remediation: hoeveel tijd verstrijkt voordat de onderliggende kwetsbaarheid daadwerkelijk is verholpen en het herstel is gecontroleerd?
• Exposure backlog: hoeveel relevante blootstellingen staan nog open, hoe oud zijn ze en welke bedrijfskritische diensten raken ze?
• Recovery and change capacity: hoeveel herstelwerk kan de organisatie betrouwbaar uitvoeren zonder de continuïteit van dienstverlening onaanvaardbaar te beïnvloeden?
• Mitigation confidence: hoe zeker is de organisatie dat tijdelijke maatregelen de relevante aanvalspaden daadwerkelijk blokkeren?

Deze indicatoren maken het mogelijk om kwetsbaarhedenbeheer te verbinden met operationele prestaties, architectuurkwaliteit en bestuurlijke risicobereidheid. Zij maken ook zichtbaar wanneer een organisatie niet zozeer een detectieprobleem heeft, maar een structureel capaciteitsprobleem.

10. De werkelijke oplossing ligt vóór de volgende kwetsbaarheid

Het zou verleidelijk zijn om de Vulnpocalypse vooral te beantwoorden met betere detectie, geavanceerdere AI en meer geautomatiseerde beveiligingsprocessen. Die technologieën zijn nuttig, maar zij veranderen niet automatisch de onderliggende architectuur. Een organisatie met honderden verouderde applicaties, complexe afhankelijkheden en handmatige deploymentprocessen blijft kwetsbaar voor structurele onderhoudsproblemen, ook wanneer iedere nieuwe CVE binnen enkele minuten wordt gedetecteerd.

De meest effectieve langetermijnmaatregelen liggen daarom deels buiten het traditionele securitydomein: standaardisatie van softwarecomponenten, automatisering van betrouwbare deployments, lifecyclemanagement als architectuurverplichting, reproduceerbare infrastructuur, geautomatiseerde regressie- en beveiligingstests, beperking van overbodige afhankelijkheden, en het ontwerpen van systemen waarin fouten en kwetsbaarheden niet automatisch leiden tot grootschalige compromittering. Dat vraagt om samenwerking tussen enterprise-architectuur, softwareontwikkeling, platformengineering, cybersecurity en bestuur; niet als afzonderlijke disciplines die elkaar achteraf controleren, maar als gezamenlijk verantwoordelijke partijen voor de toekomstige beheersbaarheid van het digitale landschap.

Conclusie: de Vulnpocalypse is geen CVE-crisis, maar een beheersbaarheidscrisis

De drie onderzochte bronnen laten zien waarom traditionele kwetsbaarhedenprocessen steeds nadrukkelijker onder druk komen te staan. De hoeveelheid beschikbare kwetsbaarhedeninformatie neemt toe; AI vergroot de mogelijkheden om bepaalde kwetsbaarheden te ontdekken en te onderzoeken; leveranciers kunnen niet altijd onmiddellijk effectieve patches leveren; en organisaties moeten herstel uitvoeren binnen complexe technische en organisatorische afhankelijkheden.

Maar het zou te eenvoudig zijn om hieruit te concluderen dat de wereld onvermijdelijk afstevent op een exponentiële beveiligingscatastrofe; daarvoor ontbreekt voldoende empirisch bewijs. De belangrijkere conclusie is dat organisaties hun beveiligingsmodel moeten aanpassen aan een veranderende verhouding tussen ontdekking, exploitatie en herstel. De toekomst van kwetsbaarhedenbeheer ligt daarom niet uitsluitend in sneller patchen, maar in het structureel verminderen van blootstelling, betrouwbare herstelcapaciteit te vergroten en het ontwerpen van softwarelandschappen die veilig kunnen blijven veranderen.

De beste kwetsbaarheid is niet alleen de kwetsbaarheid die snel wordt ontdekt of gepatcht. Het is ook de kwetsbaarheid die dankzij goede architectuur nooit een kritiek aanvalspad kan worden. En misschien is dat de belangrijkste les van de Vulnpocalypse: we hebben jarenlang geprobeerd steeds sneller achter kwetsbaarheden aan te lopen, terwijl de volgende stap het bouwen is van digitale systemen waarin we minder vaak hoeven te rennen.

Wat de bronnen niet meten

Deze analyse combineert een conceptueel essay met empirische database-data, en die twee hebben een verschillende bewijsstatus.

Ten eerste is het CVE-volume een proxy, geen volledige telling. Of een kwetsbaarheid een CVE krijgt, hangt af van reporting-incentives, en de scherpe stijging van 1.151 (2025) naar 4.187 (januari tot en met oktober 2026) kan deels een registratie-effect zijn naast een werkelijke volumegroei. De 4.187 is daarmee een ondergrens van het werkelijke volume, geen exacte maat.

Ten tweede is "exploitatiesnelheid" de zwakst onderbouwde ruiter. De Anthropic-cijfers (50/410, 56/410, 4% en 6%) zijn benchmarkresultaten onder specifieke omstandigheden, geen veldmeting van de werkelijke tijd tussen disclosure en exploitatie. Wie ze als universele aanvalspercentages presenteert, overclaimt.

Ten derde is de vier-ruiters-analogie een retorisch kader, geen causaal model. Dat de vier krachten in volgorde gevaarlijker worden, is een interpretatie van de auteur, geen getoetste causaliteit. De waarde ligt in wat het kader zichtbaar maakt, niet in een bewezen causale keten.

Ten vierde is de conclusie dat de wereld afstevent op een exponentiële catastrofe niet door de bronnen gedragen; de bronnen zelf benoemen dat daarvoor onvoldoende empirisch bewijs bestaat. De houdbare conclusie is de structurele mismatch tussen ontdekking en herstel, niet een voorspelling van onheil.

Zie ook

• Het OpenAI-incident tegen Hugging Face: sciencefiction die werkelijkheid werd
• Defender zero days in telecom
• Agentic AI: autonome aanvalsketens

Bronnen

1. Published Advisories, Zero Day Initiative, actuele technische kwetsbaarheden, disclosure en leveranciersinformatie.
2. Microsoft Patch Tuesday & ZDI Dashboard, CybersecurityCompass, historische en actuele kwetsbaarhedentrends.
3. The Four Horsemen of the Vulnpocalypse, Juan Pablo Castro, 2026, DOI: 10.13140/RG.2.2.32097.88162.
4. Project Glasswing: Securing critical software for the AI era, Anthropic, 2026.
5. GLM-5.3 and the spread of advanced cyber capabilities, Anthropic Frontier Red Team, 2026.
6. SP 800-40 Rev. 4: Guide to Enterprise Patch Management Planning, NIST.
7. Exploit Prediction Scoring System (EPSS), FIRST.
8. Known Exploited Vulnerabilities Catalog, CISA.
9. Virtual Patching Cheat Sheet, OWASP.
10. Cyber Resilience Act, Verordening (EU) 2024/2847, Europese Unie.