Azuls rapport over de AI-kwetsbaarheidskloof van 2026 laat zien dat bedrijven achterlopen met patchen ten opzichte van AI-dreigingen

Azuls rapport over de AI-kwetsbaarheidskloof van 2026 laat een verschil zien tussen de snelheid waarmee beveiligingsverantwoordelijken denken dat aanvallers met AI kwetsbaarheden kunnen misbruiken en de tijd die hun organisaties nodig hebben om oplossingen uit te rollen. In een enquête onder 300 Amerikaanse beveiligingsverantwoordelijken zei 69% dat aanvallers binnen drie dagen een werkende exploit konden bouwen, terwijl 44% aangaf dat hun organisatie vier dagen of langer nodig heeft om een kritieke kwetsbaarheid in de productieomgeving te patchen.

De opvallendste bevinding in het rapport betreft de ervaringen die respondenten met die vertragingen in verband brengen: 85% meldde een incident, een vermoedelijk incident of een bijna-incident als gevolg van traag patchen. Dat cijfer geeft gerapporteerde ervaringen weer, geen onafhankelijk geverifieerd aantal datalekken, en bewijst niet dat AI deze gebeurtenissen heeft veroorzaakt.

Het onderzoek is in opdracht van Azul uitgevoerd door Censuswide en richt zich op organisaties met omvangrijke Java-implementaties. De bredere boodschap is praktisch van aard: een kwetsbaarheid herkennen is pas het begin. Een oplossing moet de tests doorstaan, de getroffen systemen bereiken en de blootstelling wegnemen in een omgeving die teams mogelijk niet volledig in beeld hebben.

Twee klokken die niet gelijklopen

De enquête maakt onderscheid tussen de verwachtingen van beveiligingsverantwoordelijken over aanvallers en de implementatiemogelijkheden van hun eigen organisaties:

• 69% denkt dat aanvallers die AI gebruiken binnen drie dagen of minder een exploit kunnen bouwen. Daarvan denkt 22% dat dit minder dan 24 uur duurt.
• 56% zegt binnen drie dagen een kritieke patch in de productieomgeving te kunnen uitrollen: 13% binnen 24 uur en 43% binnen één tot drie dagen.
• 44% heeft meer tijd nodig: 32% heeft vier tot zes dagen nodig en 12% nog langer.

Dit zijn verdelingen van enquêteantwoorden, geen metingen van aanvallers die bij specifieke organisaties proberen sneller te zijn met het misbruiken van dezelfde kwetsbaarheden. Het verschil geeft reden tot bezorgdheid over de paraatheid, maar moet niet worden opgevat als een precieze blootstellingsperiode van drie dagen voor elke onderneming.

Ook bij een grens van één dag is dezelfde disbalans zichtbaar: 22% verwacht dat aanvallers zo snel te werk gaan, tegenover 13% dat zegt dat de eigen organisatie binnen die termijn een oplossing kan uitrollen. Tegelijkertijd erkent 59% dat AI-aangedreven aanvalstools de blootstelling vergroten, zonder de eigen beveiligingsaanpak te hebben aangepast.

Testen vormt een belangrijk deel van de vertraging

Bij 58% van de ondervraagde organisaties voegt het testen van updates voor de Java-runtime vier dagen of meer toe aan de patchcyclus. Daarvan meldt 36% een vertraging van vier tot zes dagen en 22% een week of langer. Nog eens 33% meldt één tot drie dagen en 9% minder dan 24 uur. Geen enkele respondent zei dat testen werd overgeslagen.

Wijzigingen in de runtime kunnen gevolgen hebben voor veel applicaties. Testen heeft daarom een praktisch doel: een beveiligingsupdate die een kritieke dienst verstoort, veroorzaakt een nieuw operationeel probleem. Volgens het rapport draagt de omvang van updates bij aan die belasting, omdat volledige driemaandelijkse OpenJDK-releases naast oplossingen voor kwetsbaarheden ook wijzigingen kunnen bevatten die niets met beveiliging te maken hebben.

Azul beoordeelde afzonderlijk 26 driemaandelijkse OpenJDK-updates over een periode van meer dan zes jaar en classificeerde er zes als veroorzakers van een ernstige regressie. Dat cijfer van 23% is de beoordeling van de leverancier van zijn releases; het is geen schatting op basis van een enquête van hoe vaak de applicatie van een individuele klant niet meer werkt.

Van de belangrijkste gemelde belemmeringen voor sneller patchen noemt 44% uitgebreide tests, 40% de complexiteit of ouderdom van getroffen systemen en 36% beperkt zicht op bekende kwetsbaarheden. Vertragingen bij patches van leveranciers werden door 25% genoemd. Dit patroon wijst erop dat een groot deel van de hersteluitdaging binnen het eigen implementatieproces van ondernemingen ligt.

Incidentmeldingen en hiaten in de inventarisatie vragen om een verschillende interpretatie

Vijfenvijftig procent meldt een bevestigd incident als gevolg van traag patchen en 53% meldt een bijna-incident. Respondenten konden meerdere antwoorden selecteren, waardoor deze cijfers elkaar overlappen en niet bij elkaar mogen worden opgeteld. Het bredere cijfer van 85% in de kop omvat ook vermoedelijke incidenten.

De enquête toont niet aan dat al deze gebeurtenissen betrekking hadden op kwetsbaarheden in Java. De deelnemers werken bij organisaties die veel met Java werken, maar het onderzoek bevat zowel vragen over het patchen van software in bredere zin als vragen die specifiek over Java-runtimes gaan.

Ook de inventarisatie vormt een uitdaging. Slechts 19% zegt dat ten minste 90% van de Java-runtimeomgeving in de productieomgeving het meest recente beveiligingspatchniveau heeft. Dat betekent dat 81% onder die grens zit; het betekent niet dat 81% geen actuele runtimes heeft. Ongeveer één op de vijf zegt dat de helft of minder van de omgeving actueel is.

Daarnaast erkent 51% dat het zicht op kritieke Java-runtimes, waaronder ingebedde, verouderde en niet-beheerde exemplaren, gedeeltelijk of beperkt is. Een kwetsbare runtime in een verpakte applicatie of container vinden kan moeilijker zijn dan een centraal beheerde installatie opsporen. Een patch kan de blootstelling niet wegnemen op een systeem dat het implementatieproces nooit bereikt.

Wat de technologie van Azul aan het gesprek toevoegt

Azuls aanbod voor beveiligingsupdates beperkt geselecteerde releases tot beveiligingscorrecties op een eerder gestabiliseerde OpenJDK-basis. Het bedrijf biedt kwartaalupdates, gerichte maandelijkse updates en updates buiten de reguliere cyclus om, met als doel de hoeveelheid niet-gerelateerde wijzigingen te beperken die ondernemingen moeten beoordelen wanneer ze een dringende correctie doorvoeren.

Dat is een beperktere technische ingreep dan het wegnemen van de noodzaak van wijzigingsbeheer. Minder codewijzigingen kunnen de omvang van de validatie beperken, maar controles die specifiek zijn voor de toepassing, verantwoordelijkheid voor de implementatie en voorbereidingen voor terugdraaien blijven belangrijk. Azul is de sponsor van het rapport en verkoopt producten die de problemen aanpakken die het rapport meet.

Azuls inventarisatie- en kwetsbaarheidstools voor Java richten zich op de andere kant van het proces: runtimes, versies en blootstelling in kaart brengen, zodat een nieuwe kwetsbaarheidsmelding kan worden gekoppeld aan de getroffen systemen. Het rapport bevat geen gecontroleerde vergelijking die laat zien in hoeverre de onderzochte organisaties hun prestaties zouden verbeteren door deze producten te gebruiken.

‘Uit ons onderzoek blijkt dat beveiligingsleiders de dreiging begrijpen: bewustzijn is niet langer het probleem; de uitvoering wel’, aldus Scott Sellers, medeoprichter en CEO van Azul.

De intentie om sneller te patchen omzetten in een meetbaar proces

Voor het komende jaar noemt 32% sneller en vaker patchen als hun belangrijkste strategie om de blootstelling te verminderen, terwijl 26% de voorkeur geeft aan een betere inventarisatie van software en runtimes. Nog eens 17% geeft prioriteit aan detectie en respons in plaats van sneller patchen.

Het onderzoek wijst op het belang van het volgen van het volledige traject van bekendmaking tot herstel: welke systemen zijn getroffen, wie is ervoor verantwoordelijk, welke tests zijn vereist en heeft de correctie de productieomgeving daadwerkelijk bereikt? Een deadline is alleen nuttig als teams kunnen controleren of de werkzaamheden zijn afgerond in alle relevante systemen.

De bevindingen voor de VS zijn gebaseerd op veldonderzoek dat van 3 tot en met 7 augustus 2026 is uitgevoerd onder beveiligingsleiders bij organisaties met ten minste 1.000 werknemers en aanzienlijk gebruik van Java/JVM in productie. Het gaat om zelfgerapporteerde antwoorden van een afgebakende groep, niet om een volledige inventarisatie van ondernemingen of een directe meting van de ontwikkeling van exploits.

Het volledige rapport over de kloof op het gebied van AI-kwetsbaarheden in 2026 bevat de bevindingen en de methodologie. De duidelijkste conclusie is dat de snelheid waarmee patches worden uitgerold en het inzicht in runtimes samen moeten verbeteren: een snelle correctie heeft beperkte waarde als een organisatie niet alle getroffen implementaties kan identificeren of niet kan bevestigen dat de update die heeft bereikt.