Les agents IA de Mandiant débusquent plus de 100 failles critiques en deux jours dans du code volé

19 août 2026. Le Google Threat Intelligence Group publie le fonctionnement interne d’un outil que Mandiant utilise depuis dix mois pour traquer les vulnérabilités dans du code source. Plus de 100 failles critiques vérifiées en deux jours lors d’une enquête sur des dépôts d’entreprise volés. 12 CVE déjà assignées, dont CVE-2026-13242 et CVE-2026-55803, et une douzaine d’autres en cours de divulgation.

Ce qui compte ici n’est pas un outil de plus. C’est la bascule que ce chiffre illustre : la revue de code manuelle ne peut plus suivre le rythme de l’IA, et les scanners traditionnels ratent trop de failles — mais un harnais d’agents bien construit peut, lui, reprendre l’avantage.

AVDH : une chaîne d’agents, pas un scanner

L’outil s’appelle AVDH, pour Agentic Vulnerability Discovery Harness. Il ne se présente pas comme un scanner, mais comme une chaîne d’agents spécialisés construits sur l’Agent Development Kit de Google, chaque agent transmettant sa sortie au suivant. En dix mois, il a scanné des dizaines de millions de lignes de code et produit des dizaines de milliers de résultats.

Les chiffres qui donnent la mesure : plus de 100 failles vérifiées à haute sévérité en deux jours sur une enquête réelle, des dizaines de failles assignables dans des extensions web et des projets open source largement utilisés, et 12 CVE publiées — avec, selon les chercheurs Alex Tselevich et Michael Maturi, « une douzaine supplémentaire en cours de divulgation active ».

La chaîne, étape par étape

La force d’AVDH tient moins à ses modèles qu’à son architecture. Le pipeline se décompose en cinq étapes, chacune avec un agent dédié.

• Modélisation de la menace : un agent cartographie le dépôt, identifie le type de logiciel et marque les parties à ignorer, comme les répertoires de tests. Un humain relit le modèle de menace avant tout le reste — la porte d’entrée est contrôlée.
• Découverte des points d’entrée : des agents scannent chaque fichier pour repérer où l’entrée utilisateur pénètre l’application, des routes web aux écouteurs inter-processus.
• Enrichissement du contexte : pour chaque point d’entrée, un agent rassemble le code pertinent éparpillé — contrôles de permission, assainisseurs d’entrée — qu’un relecteur humain aurait dû chasser à la main.
• Génération d’hypothèses : des agents distincts cherchent les problèmes de contrôle d’accès (autorisation manquante, élévation de privilèges, CSRF) et les flux de données dangereux (injection SQL, XSS, injection de commande, path traversal).
• Validation des hypothèses : plusieurs agents, délibérément lancés à température élevée pour élargir leur raisonnement, se prononcent sur chaque hypothèse ; un agent de synthèse la classe en confirmée, infirmée ou rejetée.

Le point décisif est la boucle humaine. Chaque résultat confirmé passe par un consultant : Mandiant reproduit l’exploit et exécute une preuve de concept pour vérifier que la faille est réelle et qu’aucun contrôle oublié ne la bloque. Les résultats qui échouent à ce test sont jetés.

La bataille contre les faux positifs

Les scanners automatisés traînent une réputation méritée de bruit : des résultats plausibles sur le papier, qui ne tiennent pas une fois vérifiés. AVDH a été construit spécifiquement contre ce défaut, en faisant contester les conclusions des agents entre eux et en les confronter à des règles écrites par les consultants de Mandiant, plutôt qu’en signalant de simples motifs de code qui ressemblent à des bugs connus.

Ces règles sont organisées par domaine logiciel, puis découpées en trois groupes — langage, framework et type de vulnérabilité — pour rester réutilisables quand l’outil est pointé vers un autre dépôt.

Un détail méthodologique mérite l’attention : pour évaluer sa propre performance, Mandiant a construit des dépôts synthétiques volontairement vulnérables plutôt que de s’appuyer sur des jeux de données publics. La raison est directe : les modèles actuels ont pu déjà voir ces jeux de données à l’entraînement, et « se souvenir » d’une réponse au lieu de raisonner dessus. C’est la marque d’une équipe qui mesure honnêtement ce que l’IA sait réellement faire.

Où AVDH se place face aux scanners classiques

Pour situer l’apport, il faut le comparer aux deux familles historiques. Le SAST (analyse statique) parcourt le code à la recherche de motifs connus : rapide, mais aveugle aux flux de données qui traversent plusieurs fichiers. Le DAST (analyse dynamique) teste l’application en cours d’exécution : il voit l’entrée et la sortie, mais pas le chemin interne. AVDH occupe une troisième place : il raisonne sur le code comme le ferait un relecteur humain, en formulant des hypothèses sur ce qui pourrait mal tourner, puis en les vérifiant par l’exploitation.

La différence tient à ce que Mandiant appelle la lutte contre l’IA adverse. Les attaquants utilisent déjà des modèles pour écrire des exploits, chercher des failles et chaîner des vulnérabilités — et ils le font à la vitesse d’un modèle, pas d’un humain. La réponse des défenseurs ne peut pas rester un scanner à motifs qui tourne une fois par semaine : elle doit être un harnais capable de générer et de vérifier des hypothèses au même rythme. C’est exactement ce que démontre le chiffre de plus de 100 failles critiques en deux jours : à cette cadence, un humain seul, ou un scanner classique, est hors course.

Ce que ça change pour les défenseurs

La conclusion de Google est sans détour : « sécuriser le pipeline de développement logiciel est devenu un défi déterminant de la défense d’entreprise moderne », et « la revue de code source manuelle ne peut pas suivre le rythme de l’IA ». La contrepartie est tout aussi nette : « le succès de notre harnais prouve que les défenseurs peuvent reprendre l’avantage face à l’IA adverse », en embarquée des modèles frontières dans un harnais défini par des experts.

L’enseignement pour un RSSI ou un responsable AppSec tient en trois points. D’abord, la valeur n’est pas dans le modèle, mais dans l’orchestration : la chaîne d’agents, les règles métier et la boucle humaine font la différence, pas la taille du modèle. Ensuite, le faux positif reste l’ennemi : la validation humaine par preuve de concept est ce qui sépare un outil utile d’un générateur de tickets. Enfin, le dépôt synthétique comme étalon d’évaluation est une pratique à reprendre : si votre métrique repose sur des jeux publics contaminés, vous mesurez de la mémorisation, pas de la découverte.

Verdict

AVDH n’est pas un produit que vous pouvez acheter — c’est une capacité que Mandiant garde en interne. La décision est donc indirecte : si vous évaluez des outils de revue de code assistée par IA, exigez la même preuve que celle que Google donne — des CVE réellement assignées, une validation humaine par exploit, et un étalon d’évaluation non contaminé. Si votre fournisseur ne publie ni l’un ni l’autre, vous achetez un assistant de relecture, pas un découvreur de vulnérabilités.

La question n’est plus de savoir si l’IA peut trouver des failles. Elle est de savoir si votre équipe a le harnais — et la boucle humaine — pour transformer une hypothèse en CVE.

Références

• Google Threat Intelligence Group, « Staying ahead of adversarial AI through agentic source code review », cloud.google.com, 19 août 2026.
• Help Net Security, « Google’s AI security agents found 100+ critical software vulnerabilities in just two days », 19 août 2026.
• NVD, fiches CVE-2026-13242 et CVE-2026-55803, consultées le 20 août 2026.