Meer kwetsbaarheden worden zichtbaar. Kan jouw bedrijf ze ook oplossen?

Als een kwetsbaarheid wordt gemeld in de software achter je klantportaal, wil je weten of je geraakt wordt, wie ingrijpt en hoe snel dat kan zonder je dienstverlening stil te leggen. Een lange lijst beveiligingsmeldingen geeft op die vragen nog geen antwoord.

In 2026 stijgt het aantal gepubliceerde softwarekwetsbaarheden sterk. AI helpt onderzoekers om fouten te vinden. Voor ondernemers en CTO’s ligt de praktische vraag dichter bij huis: kun je relevante meldingen omzetten in geteste updates voor de systemen waarop je bedrijf draait?

Wat de stijging van CVE-publicaties laat zien

Een CVE is een openbaar identificatienummer voor een bekende kwetsbaarheid. De publicatie van zo’n record maakt een probleem zichtbaar. Ze vertelt nog niet of jouw applicatie geraakt wordt of dat iemand de kwetsbaarheid bij jou heeft misbruikt.

Bron: BlackTree, op basis van CVE.org-publicatierecords. Geraadpleegd op 1 november 2026, met bronrefresh van 31 oktober. Oktober 2026 staat in de bron nog als ‘partial’ en is daarom gearceerd. Bekijk alle maandcijfers en de telmethode.

De richting is duidelijk: vooral in de tweede helft van 2026 worden meer CVE-records gepubliceerd. De voorlopige oktoberstand ligt rond 17.000 publicaties, tegenover circa 4.300 in oktober 2025.

Welke van deze meldingen raken de software achter jouw orders, planning of dienstverlening?

Welke rol speelt AI bij het vinden van kwetsbaarheden?

Er is concreet bewijs dat AI kwetsbaarheden helpt ontdekken. De beschikbare onderzoeken beantwoorden verschillende vragen; hun aantallen kun je niet bij elkaar optellen.

Anthropic meldde op 2 oktober dat het met Claude-modellen 6.157 bevindingen bij beheerders van 591 opensourceprojecten had gemeld. Daar waren op dat moment 219 CVE-records aan gekoppeld. Dit is een eigen rapportage van Anthropic: gemelde bevindingen zijn niet automatisch evenveel bevestigde, gepubliceerde of verholpen kwetsbaarheden.

IBM X-Force zag bij Microsoft, Oracle, Google Chrome en Apache ongeveer 578% meer CVE-publicaties in januari tot en met september 2026 dan in dezelfde periode van 2025. Dat betreft die selectie van leveranciers, niet het hele softwarelandschap. IBM stelt expliciet dat een direct oorzakelijk verband met AI hiermee niet is aangetoond.

Google Threat Intelligence Group onderzocht januari 2025 tot en met augustus 2026. Het wijst naast AI ook op geautomatiseerde CVE-toekenning en geconcentreerde publicaties door leveranciers. In zijn onderzochte groep AI-vondsten kwamen kwetsbaarheden die uitvoering van code op afstand mogelijk maken relatief vaker voor.

Deze bronnen laten zien hoe AI de mogelijkheden vergroot om software op kwetsbaarheden te onderzoeken.

Meer publicaties betekenen niet automatisch evenredig meer bedrijfsrisico

Naast het aantal meldingen wil je weten welke kwetsbaarheden daadwerkelijk worden misbruikt. CISA houdt daarvoor de Known Exploited Vulnerabilities-catalogus bij.

Maandtellingen: BlackTree, bronstand gecontroleerd op 1 november 2026. KEV wordt geteld op opnamedatum; die kwetsbaarheid kan eerder zijn gepubliceerd.

Deze rijen meten verschillende zaken. Eén KEV-toevoeging kan betrekking hebben op veel aanvallen. De catalogus omvat bovendien niet alle misbruikte kwetsbaarheden en bewijs kan later beschikbaar komen. Je kunt de twee rijen dus niet delen om een exploitatiepercentage te berekenen.

De tabel is ook geen bewijs dat de dreiging nauwelijks groeit. Google rapporteert in zijn eigen onderzoeksperiode een stijging van waargenomen misbruikte kwetsbaarheden. Wel laat het onderscheid zien waarom alleen het publicatievolume onvoldoende is om jouw risico te beoordelen. Eén actief misbruikte kwetsbaarheid in een bereikbaar bedrijfskritisch systeem kan voor jou zwaarder wegen dan honderden meldingen over software die je niet gebruikt.

Het PHP-incident: een melding wordt een continuïteitsvraag

Op 21 oktober 2026 bracht het PHP-team beveiligingsupdates uit voor twee kritieke kwetsbaarheden die uitvoering van code op afstand mogelijk konden maken. Ook ondersteunde PHP-versies moesten worden bijgewerkt. Het NCSC meldde dat het zijn eigen website en meerdere andere organisaties hun websites uit voorzorg tijdelijk offline hadden gehaald. PHP-beveiligingsbericht van 21 oktober, NCSC-update.

Op 23 oktober nuanceerde het NCSC het dreigingsbeeld: misbruik bleek ingewikkelder en de kans op grootschalig misbruik kleiner dan aanvankelijk ingeschat. Het advies om de beveiligingsupdates snel te installeren bleef staan. Preventief offline halen is daarbij geen bewijs dat een organisatie is gehackt.

Voor een ondernemer maakt dit de onderhoudsvraag concreet. Als jouw klantportaal tijdelijk onbereikbaar moet blijven, hoe snel kun je dan vaststellen welke omgeving geraakt wordt, de juiste update uitvoeren en de dienstverlening verantwoord hervatten? De beschikbaarheid van een patch is pas het begin van dat werk. Dit incident illustreert die operationele opgave; het is geen bewijs dat AI de kwetsbaarheden heeft ontdekt.

Van beveiligingsmelding naar een werkende update

Onze praktische conclusie: de waarde van monitoring hangt af van wat er na de melding gebeurt. Voor een bedrijfskritische applicatie moet deze keten uitvoerbaar zijn:

Melding → toepasbaarheid → prioriteit → eigenaar → test → uitrol → verificatie.

Dat begint met een actueel overzicht van applicaties, onderliggende componenten en versies. Vervolgens beoordeelt iemand of een melding de daadwerkelijk gebruikte versie en configuratie raakt. Bereikbaarheid, toegangsrechten, bekend misbruik en de gevolgen voor het bedrijfsproces bepalen mee hoeveel haast nodig is.

Daarna moet een verantwoordelijke de maatregel kunnen uitvoeren. Is er een patch? Wie mag deze installeren? Welke afhankelijkheden moeten mee? Kan de belangrijkste workflow worden getest, en is herstel mogelijk als de update misgaat? Na de uitrol controleer je zowel de oplossing als de werking van het proces.

Automatisering kan helpen bij inventarisatie, het koppelen van meldingen aan gebruikte software en herhaalbare tests. Bij een kleine, overzichtelijke omgeving kan een vaste onderhoudsafspraak met een beheerpartner voldoende zijn. Bij meer systemen en afhankelijkheden wordt diezelfde handmatige werkwijze lastiger vol te houden. Ook een geautomatiseerde prioriteitenlijst heeft een eigenaar nodig die uitzonderingen beoordeelt en besluiten neemt.

Als de patch beschikbaar is, maar niemand hem durft uit te rollen

Stel je een dienstverlener voor met een klantportaal waarin klanten aanvragen doen en medewerkers de afhandeling plannen.

Een leverancier publiceert een patch voor een component in dat portaal. De IT-partner bevestigt dat de gebruikte versie geraakt wordt. Maar er is geen representatieve testomgeving en niemand weet zeker of de planningskoppeling na de update blijft werken. Het team stelt de update uit omdat de dagelijkse dienstverlening door moet gaan.

In dit scenario ontbreekt vooral de mogelijkheid om beheerst te veranderen. Nog meer waarschuwingen lossen dat niet op. De eerstvolgende investering kan een testbare omgeving, een controle op de kritieke workflow en een herstelprocedure zijn. Daarmee wordt een besluit om te patchen ook uitvoerbaar.

Soms kan een urgente update niet wachten op die verbeteringen. Dan moeten beheerder en beveiligingsspecialist beoordelen welke directe maatregel nodig is, bijvoorbeeld bereikbaarheid beperken of een kwetsbare functie tijdelijk uitschakelen. Zo’n maatregel vraagt opvolging; hij maakt de structurele onderhoudsachterstand niet vanzelf kleiner.

Vijf vragen voor je volgende onderhoudsoverleg

Vraag je IT-verantwoordelijke of leverancier om de antwoorden voor één bedrijfskritische applicatie concreet te maken:

1. Weten we welke onderdelen en versies we gebruiken? Inclusief de componenten waarop het systeem afhankelijk is, en wie die bijhoudt.
2. Hoe herkennen we een melding die ons raakt? Vraag hoe bereikbaarheid, configuratie, bekend misbruik en bedrijfsimpact worden meegewogen.
3. Wie beslist en wie voert uit? Spreek ook af wie vervangt bij afwezigheid en wanneer wordt geëscaleerd.
4. Kunnen we een urgente update testen en uitrollen? Laat de kritieke workflow en de herstelroute aanwijzen.
5. Hoe weten we dat het is opgelost? Vraag om bewijs van de wijziging en een controle dat de dienstverlening nog werkt.

Meet vervolgens bijvoorbeeld hoe lang een relevante melding op beoordeling wacht en hoe lang een geprioriteerde maatregel openstaat. Vergelijkbare systemen en urgenties geven daarbij een bruikbaarder beeld dan één gemiddelde voor alle meldingen. Extra registratie heeft pas nut als iemand met de uitkomst kan sturen.

Onderhoudbaarheid bepaalt hoeveel je met nieuwe informatie kunt

Dit vraagstuk raakt aan End of Life, maar is breder. Ook ondersteunde software vraagt tijdige beoordeling en onderhoud. Bij EOL kan daar het ontbreken van reguliere beveiligingsupdates bij komen. Het verwante artikel over het ongemerkte bedrijfsrisico van EOL-software gaat dieper in op dat verschil.

De stijging van ontdekkingen maakt een bestaande vraag dringender: kun je de software achter je dienstverlening blijven onderhouden? Als dat bij een oudere applicatie onduidelijk is, helpt een gerichte beoordeling van afhankelijkheden en moderniseringsopties om een vervolgstap te kiezen.

Met een Legacy Rescue Scan onderzoeken we wat je kunt behouden, verbeteren of vervangen en welke route past bij de continuïteit van je proces.

Maandcijfers bij de grafiek

Bron: BlackTree / CVE.org, geraadpleegd op 1 november 2026; bronrefresh 31 oktober. Overgenomen maandtotalen, geen onafhankelijke hertelling. CVE-publicaties worden geteld op publicatiedatum, KEV-toevoegingen op opnamedatum. KEV-toevoegingen zijn geen aantallen aanvallen. Historische cijfers kunnen wijzigen.