Antaeus : un raisonnement LLM ancré dans le dépôt pour les failles de logique

What is this?

Le 1er juillet 2026, Michele Armillotta, Nicolò Romandini, Rebecca Montanari et Lorenzo Cavallaro ont publié Antaeus: Hunting Repository-Level Logic Vulnerabilities via Context-Grounded LLM Reasoning (arXiv:2607.01138). Il s’agit d’un travail d’outillage défensif, pas d’une attaque : un pipeline qui détecte des failles de logique — contrôle d’accès défaillant et exposition d’informations sensibles — dans de grandes bases de code C et C++, en ancrant le raisonnement d’un modèle de langage dans le dépôt qui l’entoure plutôt que dans une fonction isolée.

Les failles de logique sont la catégorie que les outils classiques traitent le plus mal. Un bug mémoire se manifeste par un accès invalide, un bug de flux de données par une propagation de données teintées d’une source vers un puits, mais une faille de logique est l’absence d’un contrôle que les conventions de l’application exigent. L’exemple choisi par les auteurs est une faille de contrôle d’accès de 2020 dans libvirt : un point d’entrée public configurant le délai d’attente d’un agent invité était localement correct à chaque ligne, mais il lui manquait un unique garde en lecture seule ; un client en lecture seule pouvait donc mettre ce délai à zéro et provoquer un déni de service. Chaque ligne paraissait bénigne isolément ; la vulnérabilité résidait dans le modèle de confiance du dépôt. Le constat central de l’article est que même les modèles agentiques de pointe peinent ici, et qu’un ancrage contextuel structuré comble une grande partie de l’écart.

How it works

Antaeus exécute un pipeline à l’échelle du dépôt en quatre étapes. La priorisation élague d’abord vers les seuls fichiers C/C++, applique des heuristiques par mots-clés larges pour ne conserver que les fonctions touchant à l’autorisation, au contrôle d’accès, aux frontières de confiance ou à la configuration, puis compresse chaque fonction survivante en sa signature et les fonctions appelées. Un modèle agentique classe ces représentations compactes, réduisant d’environ 29 à 33× le nombre de fonctions soumises à l’analyse détaillée.

L’ancrage contextuel construit ensuite les preuves nécessaires pour juger une fonction priorisée : une augmentation locale (types, macros, constantes et corps des fonctions appelées qui fixent le sens de chaque ligne) plus une vue à l’échelle du dépôt de la finalité de l’application, des ressources qu’elle médie et de l’emplacement de ses frontières de confiance. Le raisonnement structuré demande au modèle de nommer les puits sensibles à la sécurité dans la fonction, de dériver les conditions de sûreté requises pour que chacun soit sûr, et de vérifier si ces conditions sont localement satisfaites. Enfin, la validation comparative — une étape fondée sur des embeddings — élague les résultats qui ne font que refléter des normes du projet plutôt que des violations distinctives, et l’outil rapporte le puits, la condition violée et les preuves à l’appui.

Why it matters

Évalué sur 28 dépôts réels issus d’un jeu de données de CVE au niveau du dépôt (12 cas d’exposition d’informations et 16 cas de contrôle d’accès, chacun avec son projet complet comme vérité terrain), Antaeus a détecté et expliqué 15 vulnérabilités sur 28 avec un modèle de pointe et 12 sur 28 avec un autre, et a reproduit 15 sur 28 sur une version de modèle plus récente. Toutes les configurations des lignes de base — invites LLM au niveau d’une fonction unique et scanners agentiques autonomes sur dépôt brut comme pré-classé — plafonnaient à 4 sur 28. Les lignes de base agentiques maintenaient un faible taux de faux positifs surtout en examinant moins de code : même avec le même ensemble de fonctions classées, elles restreignaient la recherche en interne, produisant donc davantage de faux résultats plutôt que d’atteindre la faille. La leçon : un simple passage « agent, audite ce dépôt » n’est pas une revue complète des failles de logique ; le rappel provient de l’analyse exhaustive du code priorisé et de l’ancrage, pas d’un modèle plus intelligent à lui seul.

Defenses

Pour les défenseurs, les enseignements pratiques sont concrets. Ne considérez pas le scan d’un dépôt par un agent autonome comme une couverture des failles de logique — les agents de cette étude limitaient silencieusement la quantité de code inspecté. Privilégiez les outils dont la sortie nomme le puits, la condition de sûreté précise non satisfaite et les preuves, car cette structure est ce qui rend le tri praticable et un résultat actionnable plutôt qu’un signalement vague. Pour les classes sous-jacentes, imposez les invariants de contrôle d’accès à chaque point d’entrée public et frontière de confiance (un contrôle de lecture seule ou de privilège sur chaque opération modifiant l’état), auditez ce qui franchit une frontière au titre de l’exposition d’informations sensibles, et écrivez explicitement les invariants de sécurité du projet pour qu’ils soient vérifiables mécaniquement. Enfin, gardez à l’esprit la réalité à double usage : le même ancrage contextuel qui améliore le rappel défensif renforce aussi la découverte offensive ; les équipes livrant beaucoup de code C/C++ ont intérêt à adopter ces méthodes dès maintenant pour garder une longueur d’avance sur les attaquants.

Status

Antaeus est un prototype de recherche. Aucun exploit ni outillage armé n’est publié ; le travail est une évaluation d’un pipeline de détection face à des failles connues et corrigées.

Élément	Détail
Publication	arXiv:2607.01138, 1er juillet 2026
Type	Cadre de détection défensif + évaluation (aucun exploit publié)
Périmètre	Failles de logique au niveau du dépôt en C/C++ (CWE-284 contrôle d’accès défaillant, CWE-200 exposition d’informations sensibles)
Résultat	15/28 détectées et expliquées ; meilleure ligne de base 4/28
CVE illustrative	CVE-2020-10701 (faille de contrôle d’accès en lecture seule dans libvirt)