Les agents LLM open source échouent au scan SAST, selon une étude empirique

De quoi s’agit-il ?

Le 10 juin 2026, Derek Yohn, Luke Flancher, Mirajul Islam et Khaled Slhoub, du Florida Institute of Technology, ont publié Can Open-Source LLM Agents Replace Static Application Security Testing Tools? An Empirical Assessment (arXiv:2606.11672, cs.CR). La question est d’actualité : les équipes qui livrent du code généré par IA veulent de plus en plus qu’un agent IA le relise aussi, et beaucoup de petites équipes n’ont jamais intégré de véritable outil de Static Application Security Testing (SAST) dans leur pipeline.

Les auteurs ont construit un agent Python simple baptisé Snitch, alimenté tour à tour par trois modèles open-weight hébergés via Ollama — gemma3 (Google), llama3.1 (Meta) et qwen2.5 (Alibaba) — puis l’ont comparé à Bandit, un outil SAST Python éprouvé et fondé sur des règles, sur trois dépôts open source réels. Leur conclusion est nette : un agent LLM open source généraliste n’est pas adapté aujourd’hui au scan SAST en conditions réalistes.

Comment ça marche

Le dispositif est un face-à-face propre. Bandit et Snitch ont chacun analysé 224 fichiers Python / 101 816 lignes de code répartis sur Beaverhabits (un suivi d’habitudes), Fail2ban (un daemon de sécurité) et Yum (le gestionnaire de paquets RPM, mature). Les détections de sévérité moyenne/haute de Bandit ont servi de référence — 4 dans Beaverhabits, 37 dans Fail2ban, 0 dans le code mature de Yum. Snitch exécutait un prompt fixe d’expert SAST demandant à chaque modèle de produire du JSON avec les champs where, what, why et fix.

La performance était mesurée par le rappel (proportion des détections M/H de Bandit également trouvées, avec crédit partiel) moins un taux de faux positifs, donnant un score composite de -1 à 1. Toutes les cases ressortent négatives :

Modèle	Beaverhabits (R / FP / Comp)	Fail2ban	Yum
gemma3	0,25 / 0,88 / -0,62	0,00 / 0,80 / -0,80	0,00 / 0,89 / -0,89
llama3.1	0,25 / 0,46 / -0,21	0,03 / 0,40 / -0,37	0,00 / 0,59 / -0,59
qwen2.5	0,25 / 0,28 / -0,03	0,01 / 0,14 / -0,12	0,00 / 0,40 / -0,40

Le mode d’échec dominant était l’hallucination. Le champ where — fichier et plage de lignes de chaque problème — était fréquemment fabriqué, pointant vers des fichiers ou des emplacements inexistants. Seul le nom de fichier capturé séparément a permis d’exploiter la sortie. Les modèles ont aussi pris des motifs d’ingénierie normaux pour des vulnérabilités : une configuration .env / dotenv signalée comme secrets en dur, des constantes de bibliothèque standard comme calendar.MONDAY signalées comme secrets, des en-têtes de licence et des méthodes « dunder » Python signalés comme injections. qwen2.5 était le moins mauvais (moins de faux positifs) ; gemma3 le pire. Les auteurs notent que des modèles fermés ou spécialisés, avec un meilleur prompting, pourraient faire mieux — mais l’ampleur de l’écart suggère un problème structurel, pas un artefact de réglage de prompt.

Pourquoi c’est important

C’est le miroir défensif des travaux récents sur les agents chasseurs de vulnérabilités comme Code-Augur et les benchmarks de chasse aux bugs à long horizon : une fois l’échafaudage retiré, un modèle générique placé devant une base de code fait moins bien qu’un détecteur de motifs des années 1990. Le danger n’est pas que l’agent ne trouve rien — c’est qu’il produit une sortie fluide et assurée mais essentiellement bruitée, poussant les développeurs à « corriger » des non-problèmes pendant que les vraies détections se noient. Cette fausse confiance est elle-même une surface de risque, et elle aggrave les problèmes de confiance déjà documentés autour de l’ergonomie des LLM de code et des défauts de code introduits par l’IA. La vitesse n’arrange rien : Bandit traitait chaque dépôt en moins d’une minute, là où Snitch prenait une à quatre heures par dépôt (~672 appels LLM, 10-12 heures au total).

Défenses

Pour les équipes qui envisagent un agent LLM comme scanner de sécurité, les points pratiques :

1. Gardez l’outil déterministe comme source de vérité. Le SAST fondé sur des règles (Bandit, Semgrep, CodeQL) est rapide, reproductible, explicable et relié aux CVE. Traitez le LLM comme une passe secondaire optionnelle, jamais comme le verrou.
2. Ne faites jamais confiance aux numéros de ligne d’un LLM. Le champ where hallucinait régulièrement ; toute détection d’agent doit être ré-ancrée au code source réel avant qu’un humain n’agisse.
3. Attendez-vous à un flot de faux positifs. Réglez vos filtres pour les motifs .env/dotenv, constantes-comme-secrets et commentaires/licences observés dans l’étude — sinon vous apprendrez aux développeurs à ignorer l’outil.
4. Mesurez avant d’adopter. Reproduisez la métrique peu coûteuse de l’étude — rappel et taux de faux positifs face à une référence éprouvée, sur votre code — plutôt que de vous fier à une démo de fournisseur.
5. Utilisez les LLM là où ils sont forts. Fait notable, les chercheurs ont utilisé Claude pour générer le script de recoupement qui a analysé la sortie bruitée — LLM-assistant d’un pipeline déterministe, et non LLM-scanner.

Statut

Élément	Référence	Date	Notes
Évaluation empirique	arXiv:2606.11672	2026-06-10	Agent Snitch vs Bandit, 224 fichiers / 101 816 LOC
Modèles testés	gemma3, llama3.1, qwen2.5 (via Ollama)	2026-06-10	Modèles open-weight généralistes
Meilleur composite	qwen2.5	2026-06-10	Négatif sur les trois dépôts malgré tout
Outil de référence	Bandit (PyCQA)	—	SAST Python fondé sur des règles, relié aux CVE

À retenir : à la mi-2026, un agent LLM open source généraliste est un piètre substitut à un outil SAST déterministe — faux positifs élevés, emplacements fabriqués, des heures d’exécution. Le bon schéma est l’inverse du discours ambiant : laissez l’outillage éprouvé faire la détection, et laissez le modèle aider au tri et à l’explication sous contrôle humain.