Hoe AI de reactietijd op zero-day kwetsbaarheden verandert

Sophie Jansen · 2026-08-11

Kunstmatige intelligentie geeft security-onderzoekers nieuwe manieren om code te onderzoeken, afwijkend gedrag te traceren en fouten te ontdekken die traditionele tools over het hoofd zien. De druk is vooral zichtbaar rond zero-day kwetsbaarheden. Een recente analyse van Minimus bekijkt hoe containercompositie, dependency-registraties 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 ontdekt fouten die traditionele tools missen In mei 2026 meldde de Google Threat Intelligence Group het eerste geval waarbij 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 geldige inloggegevens al beschikbaar waren. Onderzoekers zeiden er hoge vertrouwen in te hebben dat een AI-model hielp bij zowel de ontdekking als de bewapening van de kwetsbaarheid. Hun beoordeling was gebaseerd op de ongewoon gedetailleerde instructiecommentaren in het script, een verzonnen kwetsbaarheidsscore en een zeer gestructureerde codeerstijl die geassocieerd wordt met gegenereerde output. Google beweerde niet dat de bredere operatie autonoom was, noch schreven ze de code toe aan een specifiek model. Het is juist de fout zelf die deze casus belangrijk maakt. Het ging om een hardcoded vertrouwensaanname, niet om een crash, geheugenfout of onveilige invoer. Fuzzers en statische analysetools zijn goed in het vinden van veel conventionele implementatieproblemen. Een taalmodel kan echter 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 traceerden onderzoekers 90 zero-days die in 2025 in het wild werden misbruikt, vergeleken met 78 in 2024. Bedrijfssoftware en apparaten waren goed voor 43 gevallen, oftewel 48 procent van het totaal. Beide cijfers waren records in de dataset van Google. ### Complexe containers maken blootstelling moeilijker te traceren Zodra een fout openbaar wordt, moeten securityteams eerst uitzoeken waar die draait. Dat kan lastig zijn in een containeromgeving. Een image kan besturingssysteempakketten, applicatiebibliotheken en dependencies 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 meerdere 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 in 2021 op grote schaal bloot. 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 steeds elke server, applicatie en container identificeren die een kwetsbare versie bevatte voordat ze de remediëring 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 bekijkt dit vraagstuk via pakketreductie, zichtbaarheid van dependencies 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. Maar het geeft teams 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. Maar dat is niet erg nuttig wanneer pakketregistraties verouderd zijn of niemand weet welke image de kwetsbare code bevat. De les is duidelijk: AI versnelt de analyse, maar zonder een goed beeld van je softwarelandschap blijft de remediëring een race tegen de klok. Het begint allemaal met inzicht in wat er draait, waar het draait en welke dependencies eraan vastzitten. Alleen dan kun je de voordelen van AI echt benutten. > Zoals een security-analist het ooit treffend verwoordde: "Je kunt niet patchen wat je niet kunt vinden." Die uitspraak is actueler dan ooit in het tijdperk van AI-gedreven aanvallen. Door te investeren in overzichtelijke containers, actuele SBOM's en snelle herbouwprocessen, ben je beter voorbereid op de volgende zero-day. Niet omdat je ze kunt voorkomen, maar omdat je sneller weet waar je moet ingrijpen. En dat maakt het verschil tussen een incident en een crisis.