Mandiant vond met een AI-harnas ruim honderd kritieke kwetsbaarheden in twee dagen, in gestolen bedrijfsrepository's die het onderzocht na een datalek bij een klant, schrijft Google.
Dat getal is vooral een klok. Lekt jouw broncode, via een gehackte leverancier, een verkeerd ingestelde opslagbucket of een vertrokken ontwikkelaar, dan kan een aanvaller met vergelijkbare techniek binnen dagen een lijst met uitbuitbare fouten in jouw eigen software hebben. Voor organisaties die maatwerksoftware laten bouwen verandert daarmee wat een broncodelek betekent: niet alleen verlies van intellectueel eigendom, maar het startsein voor gerichte aanvallen op de systemen die je zelf draait.
Wat het harnas in tien maanden opleverde
Google Threat Intelligence Group beschrijft het systeem, de Agentic Vulnerability Discovery Harness (AVDH), op 18 augustus voor het eerst in detail. Mandiant, het onderzoeks- en incidentresponsonderdeel van Google, gebruikt het tien maanden. In die periode analyseerde het bedrijf omgevingen van tientallen miljoenen regels code, met duizenden pijplijnen en tienduizenden bevindingen.
Twaalf van die bevindingen kregen een CVE-nummer, en nog eens een dozijn zit in het openbaarmakingstraject. Twee zijn al openbaar en gaan allebei over Drupal. In de module Geolocation Field zat een SQL-injectie in een views-filter dat aangeleverde invoer onvoldoende opschoonde, met een risicoscore van 19 op 25. In Drupal core zelf ging het om PHP-object-injectie via geserialiseerde velden in de JSON:API, score 18 op 25. Beide advisories noemen Michael Maturi als melder, een van de twee auteurs van het blog.
Bij een aanvalssimulatie haalde hetzelfde harnas uit de broncode van de webapplicatie van een klant een kwetsbaarheid voor uitvoering van code op afstand, waarmee de simulatie binnenkwam. Verdediging en aanval draaien dus op dezelfde pijplijn: proactieve reviews, pentests, red teaming en incidentrespons.
Hoe de pijplijn is opgebouwd
AVDH is geen enkel model dat je op een repository loslaat, maar een keten van gespecialiseerde agents die elkaar in vaste volgorde voeden, gebouwd op Google's eigen Agent Development Kit en bediend vanuit de agentwerkplek Antigravity. De keten kent vijf stappen.

- Dreigingsmodel. Een verkenner-agent stelt vast waar de code voor dient en in welk softwaredomein die valt, met subagents voor authenticatie, autorisatie en routering. Een menselijke consultant keurt het model goed voordat de rest mag draaien.
- Ingangen zoeken. Parallelle agents lopen elk bestand na met het lichte model Gemini Flash Lite en halen HTTP-routes, IPC-luisteraars en andere invoerpunten eruit, plus alle plekken waar gebruikersinvoer binnenkomt.
- Context verzamelen. Per invoerpunt haalt een agent de omliggende code op en bepaalt of er toegangscontrole-analyse nodig is, dataflow-analyse, of allebei.
- Hypotheses opstellen. De toegangscontrole-agent zoekt ontbrekende autorisatie, rechtenescalatie en CSRF. De dataflow-agent volgt invoer door geneste functies, opschoners en databases tot een gevaarlijke sink en vindt zo SQL-injectie, cross-site scripting, command-injectie en path traversal.
- Hypotheses toetsen. Meerdere validatie-agents draaien op een hoge temperatuur, dus met bewust veel variatie in hun antwoorden, waarna een synthese-agent hun oordelen weegt tot bevestigd, weerlegd of afgewezen.
Die opzet is een antwoord op het bekendste probleem van AI-codescanners: een berg meldingen waar niemand doorheen komt. Door het werk op te knippen, elke stap te laten controleren door een agent die er belang bij heeft de vorige onderuit te halen, en een consultant het dreigingsmodel te laten tekenen, blijft het aantal hypotheses beheersbaar.
De mens is de laatste filter
Wat de agents bevestigen, is nog geen rapport. Bij de overdracht naar de consultant gaan bevindingen eerst door een statische review en daarna door dynamisch testen: de fout moet in de praktijk reproduceerbaar zijn met een proof-of-concept. Wat die toets niet haalt, gaat de prullenbak in.

Google giet zijn eigen expertise daarnaast in regels die de pijplijn in gaan, geordend per softwaredomein, taal, framework en kwetsbaarheidstype. De kwaliteit meet het bedrijf met eigen synthetische codebases waarin consultants elke ingebouwde fout handmatig nalopen op echte bereikbaarheid en uitbuitbaarheid, plus een beoordelingsagent die vondsten tegen die grondwaarheid legt en dubbelingen en valse positieven apart classificeert. Daarom betekent "ruim honderd" hier ruim honderd geverifieerde treffers, en geen ruwe meldingenlijst.
Waar dit de balans verschuift
De golf van AI-gevonden kwetsbaarheden liep al. Bij dezelfde eigenaar dichtte AI-hulp 1.072 lekken in twee Chrome-releases, meer dan in de 23 versies ervoor samen, en bij een concurrent vond het systeem NOVA 14.090 vrijwel allemaal onbekende kwetsbaarheden in 3.915 open-source projecten. Die vondsten gingen over code die de eigenaar zelf beheert en op zijn eigen tempo kan patchen.
Nieuw aan deze publicatie is de situatie erachter. De code is al weg, en verdediger en aanvaller beginnen op hetzelfde moment aan dezelfde bestanden. Daarmee krijgt de waarschuwing van het NCSC dat de tijd tussen een gevonden fout en actief misbruik van weken naar dagen naar minuten is gegaan ook een getal aan de verdedigingskant: ongeveer twee dagen om te weten wat er in je eigen code te halen valt.
Die twee dagen beginnen alleen te lopen als je weet welke repository's je hebt, waar ze staan, bij welke leverancier en wie er toegang toe had. Organisaties die dat pas na een inbraak gaan uitzoeken, zijn hun voorsprong kwijt voordat de eerste scan draait.
Veelgestelde vragen
Weet jij waar je code staat
Als je software laat bouwen, wil je weten welke repository's er zijn, wie erbij kan en wat er in je keten meedraait. Ik denk mee over die opzet, ontwerp hem en bouw en automatiseer hem, self-hosted waar dat kan.
Dit artikel is geproduceerd samen met het Agent Team. Meer over de redactie.
