OpenAnt : la découverte de vulnérabilités par LLM en boucle fermée

De quoi s’agit-il ?

OpenAnt est un système open source de découverte de vulnérabilités signé Knostic (Nahum Korda et Gadi Evron). Il combine l’analyse statique de programme et le raisonnement d’un grand modèle de langage (LLM), puis valide chaque résultat par une étape adversariale automatisée et l’exécution d’un exploit en bac à sable. Le papier associé, « OpenAnt: LLM-Powered Vulnerability Discovery Through Code Decomposition, Adversarial Verification, and Dynamic Testing » (arXiv:2606.19149), a d’abord été pré-publié le 11 mars 2026, puis rendu public le 17 juin 2026. L’outil est diffusé sous licence Apache 2.0.

L’enjeu n’est pas une nouvelle attaque. C’est une démonstration mesurée : le coût pour trouver des failles réellement exploitables à l’échelle d’un dépôt entier chute rapidement — et c’est la vérification rigoureuse, et non la sortie brute du modèle, qui rend les résultats fiables.

Comment ça marche

OpenAnt déroule une chaîne en six étapes qui réduit l’espace de recherche avant de dépenser le moindre token, puis renforce la rigueur sur ce qui reste.

1. Parsing du code. Les fonctions sont extraites via des AST propres à chaque langage et reliées dans un graphe d’appels bidirectionnel (Python, JavaScript/TypeScript, Go, C/C++, Ruby, PHP). Aucun coût LLM.
2. Filtrage par atteignabilité. Seules les fonctions atteignables depuis un point d’entrée externe (handlers HTTP, parseurs CLI, handlers WebSocket, lecteurs de fichiers) sont conservées. À elle seule, cette étape a éliminé environ 97 % du code des gros projets. Aucun coût LLM.
3. Classification d’exposition. Un agent Claude Sonnet 4 trace les appelants et les flux de données pour étiqueter chaque unité : exploitable, vulnérable-interne, contrôle de sécurité ou neutre.
4. Détection de vulnérabilité. Claude Opus 4 raisonne sur chaque unité exposée : que fait ce code, d’où vient l’entrée, quel risque en découle.
5. Vérification adversariale. C’est l’élément différenciant. Plutôt que de demander au modèle « peux-tu exploiter ceci ? » — question à laquelle un modèle complaisant répond presque toujours oui — OpenAnt impose un persona d’attaquant contraint : accès navigateur uniquement, aucun privilège côté serveur, aucun identifiant administrateur, aucun accès aux fichiers locaux. Chaque étape d’exploitation doit être tracée explicitement, et une faille valide doit nuire à un tiers, pas à l’attaquant lui-même. Environ la moitié des résultats signalés ont été éliminés ici comme impraticables.
6. Vérification dynamique. Pour les survivants, le système génère un Dockerfile et un script de test, exécute l’exploit dans un conteneur isolé (système de fichiers en lecture seule, plafonds mémoire et CPU, délai de 120 secondes) et détruit ensuite chaque artefact. Le conteneur doit rapporter CONFIRMED, NOT_REPRODUCED, BLOCKED, INCONCLUSIVE ou ERROR.

Sur huit projets réels (OpenSSL, Flowise, n8n, WordPress, Rails, paperless-ngx, eShopOnWeb, object-browser) totalisant 64 132 fonctions, le filtrage a ramené l’ensemble à 2 281 unités atteignables, puis à 586 unités exploitables de l’extérieur. La détection en a signalé 376, la vérification adversariale en a confirmé 190, et le test dynamique en a reproduit 144 de façon indépendante — soit un taux de reproduction de 75,8 % — couvrant plus de 30 classes de vulnérabilités, dont IDOR/autorisation manquante, mass assignment, SSRF, path traversal et injections.

Pourquoi c’est important

Deux chiffres résument l’affaire. D’abord, le run complet a coûté environ 1 461 $ ; sans le filtrage par atteignabilité, la même analyse aurait coûté près de 23 700 $ : un cadrage discipliné a rendu l’analyse LLM à l’échelle d’un dépôt économiquement viable. Ensuite, trois quarts des résultats confirmés étaient accompagnés d’une preuve de concept fonctionnelle générée automatiquement — pas d’un simple avertissement « ceci paraît risqué ».

Cette combinaison compte, car l’analyse statique classique (SAST) noie les équipes sous les faux positifs — les études empiriques rapportent des taux allant de quelques pour cent à plus de 40 %, et seuls 20 % environ des développeurs utilisent activement le SAST en conséquence. La boucle fermée d’OpenAnt s’attaque précisément à ce problème : le persona adversarial et l’exécution dynamique écartent les résultats théoriques qu’aucun attaquant distant ne peut atteindre. L’outil s’inscrit aux côtés d’efforts industriels comme Big Sleep (Google), Aardvark (OpenAI) et Claude Code Security (Anthropic).

Le revers défensif est inévitable : la même économie qui permet à un mainteneur de scanner son propre code permet à un attaquant de le scanner aussi. Quand des failles vérifiées et exploitables se produisent pour le prix de quelques appels d’API, la fenêtre entre divulgation publique et exploitation réelle continue de se réduire.

Défenses

Pour les mainteneurs et les équipes sécurité, les enseignements sont concrets :

• Utilisez d’abord ces outils en boucle fermée sur vos propres dépôts. OpenAnt est gratuit et défensif par conception ; Knostic propose aussi des scans gratuits pour les projets open source. L’exécuter sur du code que vous possédez — et uniquement celui-là — renverse l’asymétrie en faveur des défenseurs.
• Ne faites jamais confiance à un verdict « vulnérable » brut d’un LLM. Les modèles complaisants confirment presque tout. Exigez une trace d’attaquant contraint et, idéalement, un exploit reproduit avant de traiter un résultat comme réel.
• Priorisez les points d’entrée atteignables de l’extérieur. Le filtrage par atteignabilité reflète la façon dont raisonnent les attaquants ; durcissez les handlers HTTP, les parseurs CLI et les lecteurs de fichiers avant les utilitaires internes.
• Raccourcissez votre cadence de correctifs. Partez du principe que des failles vérifiées contre des bugs divulgués peuvent apparaître en quelques heures. Associez cela à une divulgation coordonnée lorsque vous trouvez des problèmes dans le code d’autrui.
• Conservez des méthodes complémentaires. OpenAnt vise les failles entrée-vers-sink (injection, SSRF, path traversal, contournement d’autorisation, XSS). Il est plus faible sur les bugs de logique, les conditions de course, les classes de sûreté mémoire et les violations de protocole — gardez le fuzzing et, pour les composants critiques, les méthodes formelles.

Statut

Élément	Détail
Papier	arXiv:2606.19149, public le 17 juin 2026 (première pré-publication le 11 mars 2026)
Code	github.com/knostic/OpenAnt, Apache 2.0
Modèles d’éval	Claude Sonnet 4 (étapes 3, 6) et Claude Opus 4 (étapes 4, 5)
Périmètre	Failles pilotées par l’entrée, 6 langages ; pas les bugs de logique/course/mémoire
Maturité	Diffusé en tant que recherche, plusieurs fonctionnalités en bêta

Les auteurs précisent qu’OpenAnt fournit une preuve empirique d’exploitabilité, pas une preuve formelle, et que l’absence d’exploit reproduit ne démontre pas qu’une vulnérabilité est impossible.