Waarom AI de respons op zero-day kwetsbaarheden versnelt (en waarom dat niet genoeg is)

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. Vooral rond zero-day kwetsbaarheden is de druk voelbaar. Uit een recente analyse van Minimus blijkt hoe belangrijk containeropbouw, afhankelijkheidsregistraties en herbouwsnelheid zijn voor de respons nadat een onbekende fout is blootgelegd. Maar snellere analyse helpt alleen als organisaties ook kunnen vaststellen waar de kwetsbare software draait. En dat blijkt in de praktijk vaak de grootste uitdaging. ### AI vindt fouten die traditionele tools missen In mei 2026 meldde Google Threat Intelligence Group voor het eerst dat een dreigingsactor waarschijnlijk AI had gebruikt om een zero-day exploit te ontwikkelen. De exploit zat in een Python-script en omzeilde tweefactorauthenticatie op een veelgebruikt open-source systeembeheertool, maar alleen wanneer er al geldige inloggegevens beschikbaar waren. Onderzoekers zeiden een hoge mate van vertrouwen te hebben dat een AI-model hielp bij zowel de ontdekking als de weaponization. Die inschatting baseerden ze op de opvallend gedetailleerde instructiecommentaar in het script, een verzonnen kwetsbaarheidsscore en een zeer gestructureerde codeerstijl die kenmerkend is voor gegenereerde output. Google beweerde niet dat de hele operatie autonoom was, en koppelde de code ook niet aan een specifiek model. De kwetsbaarheid zelf is wat deze casus bijzonder maakt. Het ging om een hardcoded vertrouwensaanname, niet om een crash, geheugenfout of onveilige invoer. Fuzzers en statische analysetools zijn uitstekend geschikt om veel conventionele implementatieproblemen te vinden. Een taalmodel kan daarnaast onderzoeken hoe rechten, functies en verwacht gedrag binnen een codebase op elkaar inwerken. Dat creëert een nieuwe route naar het vinden van logische tegenstrijdigheden 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 in dat jaar 90 zero-days die in het wild werden misbruikt, tegenover 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 kwetsbaarheid openbaar wordt, moeten security-teams eerst uitzoeken waar die draait. Dat kan lastig zijn in een containeromgeving. Een image kan operating-systeempakketten, applicatiebibliotheken en afhankelijkheden bevatten die zijn geë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 installeren van de patch slechts het begin. Ze moesten eerst elke server, applicatie en container met een kwetsbare versie identificeren 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 weg te laten 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 gemeld. 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 ingezet 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 bijzonder nuttig wanneer pakketregistraties verouderd zijn of niemand weet welke images de kwetsbare component bevatten. - Controleer of je SBOM's actueel zijn en automatisch worden bijgewerkt - Verminder het aantal pakketten in je images tot het strikt noodzakelijke - Test het herbouwproces regelmatig zodat je snel kunt reageren op nieuwe disclosures De les is duidelijk: AI versnelt de analyse, maar zonder goed inzicht in je softwarelandschap blijft die snelheid theoretisch. Wie vandaag investeert in overzichtelijke containers en betrouwbare registraties, staat morgen sterker bij de volgende zero-day.