Zo verkort AI de tijd tussen zero-day en oplossing
Sophie Jansen ·
Luister naar dit artikel~5 min
AI versnelt de jacht op zero-days, maar alleen als je weet waar kwetsbare software draait. Ontdek hoe containers, SBOM's en minimalisatie de reactietijd bepalen.
Kunstmatige intelligentie geeft security-onderzoekers nieuwe manieren om code te onderzoeken, afwijkend gedrag te traceren en zwakke plekken te vinden die traditionele tools over het hoofd zien. De druk is vooral zichtbaar rond zero-day kwetsbaarheden. Een recente Minimus-analyse bekijkt hoe container-samenstelling, afhankelijkheidsregistraties en herbouwsnelheid de reactie 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 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 weaponization. Hun beoordeling was gebaseerd op de ongewoon gedetailleerde instructie-commentaren 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 of dat de code aan een specifiek model kon worden toegeschreven.
Wat deze zaak significant maakt, is de fout zelf. 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 duidelijke technische sporen 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 2025 in het wild werden misbruikt, vergeleken met 78 in 2024. Bedrijfssoftware en apparaten waren verantwoordelijk 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 fout openbaar wordt, moeten security-teams eerst uitzoeken waar die draait. Dat kan lastig zijn in een containeromgeving. Een image kan besturingssysteempakketten, applicatiebibliotheken en afhankelijkheden bevatten die zijn overgenomen 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 elke server, applicatie en container identificeren die een kwetsbare versie bevatte voordat ze de remediëring konden afronden.
Software bills of materials bieden een duidelijker overzicht van wat elke image bevat. Kleinere images kunnen de zoektocht ook verkorten door pakketten uit te sluiten die de workload niet nodig heeft. Minimus onderzoekt dit via pakketreductie, zichtbaarheid van afhankelijkheden en het herbouwen van images nadat een getroffen onderdeel is onthuld.
Het voordeel is eenvoudiger dan het helemaal 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 praktijk leert dat een snelle patch alleen effectief is als je weet waar die moet worden toegepast. Zonder actuele software bills of materials en een duidelijk beeld van je containerlandschap blijf je in het donker tasten. AI kan de analyse versnellen, maar de fundamentele vraag blijft: welke systemen draaien er eigenlijk en welke versies hebben ze?
Voor security-teams is de les duidelijk: investeren in overzicht en minimalisatie betaalt zich dubbel terug op het moment dat een zero-day opduikt. Niet alleen vind je sneller waar het probleem zit, je hebt ook minder werk om alles te updaten. AI helpt je sneller te reageren, maar alleen als je basis op orde is.