Zo verandert AI de reactietijd op zero-day kwetsbaarheden

Sophie Jansen · 2026-08-11

Kunstmatige intelligentie geeft beveiligingsonderzoekers nieuwe manieren om code te onderzoeken, ongebruikelijk gedrag te traceren en fouten te vinden die traditionele tools over het hoofd zien. Vooral rond zero-day kwetsbaarheden wordt de druk voelbaar. Een recente analyse van Minimus bekijkt hoe containersamenstelling, afhankelijkheidsregistraties en herbouwsnelheid de respons beïnvloeden nadat een onbekende fout is blootgelegd. Snellere analyse helpt alleen als organisaties ook kunnen vaststellen waar de kwetsbare software draait. ### AI vindt fouten die traditionele tools missen In mei 2026 meldde Google Threat Intelligence Group het eerste geval waarin zij vermoedde dat een aanvaller AI had gebruikt om een zero-day exploit te ontwikkelen. De exploit verscheen in een Python-script en omzeilde tweestapsverificatie op een veelgebruikt open-source systeembeheertool, wanneer er al geldige inloggegevens beschikbaar waren. Onderzoekers zeiden er hoge vertrouwen in te hebben dat een AI-model hielp bij zowel de ontdekking als de bewapening. Hun inschatting was gebaseerd op de ongewoon gedetailleerde instructiecommentaar in het script, een verzonnen kwetsbaarheidsscore en een zeer gestructureerde codeerstijl die kenmerkend is voor gegenereerde output. Google beweerde niet dat de bredere operatie autonoom was of dat de code aan een specifiek model kon worden toegeschreven. De kwetsbaarheid zelf maakt de zaak significant. Het ging om een hardcoded vertrouwensaanname in plaats van een crash, geheugenfout of onveilige invoer. Fuzzers en statische analysetools zijn goed in het vinden van veel conventionele implementatieproblemen. Een taalmodel kan ook onderzoeken hoe rechten, functies en verwacht gedrag op elkaar inwerken binnen een codebase. Dat creëert een extra route om logische tegenstrijdigheden te vinden die geen duidelijk technisch spoor achterlaten. De bredere data van Google suggereert dat dit geen geïsoleerd probleem is. Volgens de analyse van Google Threat Intelligence Group uit 2025 volgden onderzoekers 90 zero-days die in het wild werden misbruikt in 2025, tegenover 78 in 2024. Bedrijfssoftware en apparaten waren goed voor 43 gevallen, oftewel 48% van het totaal. Beide cijfers waren records in de dataset van Google. ### Complexe containers maken blootstelling moeilijker te traceren Zodra een kwetsbaarheid openbaar wordt, moeten beveiligingsteams eerst uitzoeken waar die draait. Dat kan lastig zijn in een containeromgeving. Een image kan besturingssysteempakketten, applicatiebibliotheken en afhankelijkheden bevatten die zijn overgeërfd van het basisimage, naast shells of hulpprogramma's die weinig te maken hebben met het zichtbare doel van de workload. Een kwetsbaar onderdeel kan daardoor enkele lagen onder de applicatie zelf zitten. Het kan in talloze images voorkomen, zelfs als de organisatie het nooit direct heeft toegevoegd. Log4Shell legde dit probleem op grote schaal bloot in 2021. De getroffen Log4j-bibliotheek was verwerkt in een breed scala aan producten en diensten. Voor veel organisaties was het verkrijgen van de patch slechts het begin. Ze moesten nog elke server, applicatie en container identificeren die een kwetsbare versie bevatte voordat ze de remediatie konden afronden. Software bills of materials (SBOM's) bieden een duidelijker overzicht van wat elk image bevat. Kleinere images kunnen de zoektocht ook verkorten door pakketten uit te sluiten die de workload niet nodig heeft. Minimus onderzoekt dit vraagstuk via pakketreductie, zichtbaarheid van afhankelijkheden en het herbouwen van images nadat een getroffen component is bekendgemaakt. Het voordeel is eenvoudiger dan het volledig voorkomen van zero-days. Een minimaal image kan nog steeds een onbekende fout bevatten. Het geeft teams echter minder pakketten om te onderzoeken, minder mogelijke blootstellingspunten en minder software om te vervangen of opnieuw te testen zodra het probleem bekend is. ### AI-gegenereerde fixes hebben nog steeds softwarecontext nodig AI wordt ook gebruikt om de tijd tussen openbaarmaking en patchontwikkeling te verkorten. Modellen kunnen broncode inspecteren, kwetsbaarheidsrapporten vergelijken met pakketregistraties en wijzigingen voorstellen voor getroffen versies. Niets daarvan is echter bijzonder nuttig wanneer pakketregistraties verouderd zijn of niemand weet welke images de kwetsbare component bevatten. De echte uitdaging ligt dus niet alleen bij het genereren van een fix, maar bij het verkrijgen van een accuraat beeld van de softwareomgeving. Zonder die context blijft zelfs de beste AI-ondersteunde patch een schot in het duister. Organisaties die investeren in transparante containers en actuele SBOM's staan sterker, omdat zij sneller kunnen reageren wanneer een zero-day wordt ontdekt. > Zoals een beveiligingsonderzoeker het ooit verwoordde: "Je kunt geen kwetsbaarheid verhelpen die je niet kunt vinden." AI versnelt de analyse, maar de vindbaarheid van software blijft de bottleneck. De combinatie van AI-gestuurde detectie en een opgeruimde containeromgeving biedt de beste kans om de responsetijd op zero-days te verkorten. Het is geen kwestie van kiezen tussen het een of het ander; beide zijn nodig om echt vooruit te komen in dit voortdurende kat-en-muisspel.