SEC-bench Pro : les agents IA savent-ils vraiment chasser les bugs dans V8 et SpiderMonkey ?
Un benchmark du 26 mai 2026 mesure les agents de code sur la découverte de vulnérabilités au long cours dans de vrais moteurs de navigateur. Les modèles de pointe restent sous 40 % — et l'écart compte autant pour l'attaque que pour la défense.
De quoi s’agit-il ?
“SEC-bench Pro: Can Language Models Solve Long-Horizon Software Security Tasks?” (arXiv:2605.26548, 26 mai 2026) est un benchmark qui pose la question que toute équipe sécurité doit désormais trancher : quand on lance un agent de code sur une vraie base de code volumineuse en lui demandant de trouver une vulnérabilité, à quelle fréquence réussit-il réellement ? La réponse, sur les deux cibles retenues par les auteurs — les moteurs JavaScript V8 de Google et SpiderMonkey de Mozilla — est « moins souvent que ne le laisse croire le marketing ».
Le travail prolonge le SEC-bench original (NeurIPS 2025), qui se limitait à des tâches courtes et bien cadrées, vers des tâches au long cours : chasse aux bugs en plusieurs étapes sur du logiciel de niveau navigateur, où l’agent doit naviguer dans une base de code d’un million de lignes, formuler une hypothèse, construire un proof-of-concept et confirmer le crash — sans harnais de fuzzing fourni et sans description pointant vers le bug. Ce réalisme est tout l’intérêt. Les auteurs soutiennent que les benchmarks antérieurs surestiment les modèles parce qu’ils s’appuient sur des indices spécifiques à la cible ou de simples tâches de reproduction.
Comment ça marche
SEC-bench Pro est instancié avec 183 vulnérabilités validées couvrant des bugs de sûreté mémoire, d’évasion de bac à sable, de JIT et de conditions de course — des catégories qui correspondent à la façon dont les moteurs de navigateur sont réellement cassés. Le sous-ensemble V8 représente à lui seul plus de 1,5 million de dollars de primes cumulées du Vulnerability Reward Program de Google : ce ne sont pas des bugs de démonstration, mais des failles que de vrais chercheurs ont été grassement payés pour trouver.
Chaque tâche s’exécute dans des conditions de niveau navigateur ou runtime, et l’agent est évalué sur sa capacité à découvrir et reproduire la faille de bout en bout. Surtout, le harnais mesure le flux de travail au long cours plutôt qu’une seule étape de récupération ou de correctif — c’est précisément là que les agents actuels s’effondrent.
Les résultats marquants, tels que rapportés dans le papier :
# Reported pass rates (higher = better), per the SEC-bench Pro paper
Open-weight baseline (Kimi-K2.6) V8: 11.7%
Strongest single frontier config V8: 32.0% SpiderMonkey: 38.8%
ClaudeCode + Codex (two-agent union) V8: 37.9% SpiderMonkey: 48.8%
Deux constats ressortent. D’abord, chaque configuration reste sous 40 % sur chaque moteur pris isolément — les agents de code de pointe sont loin d’être des chasseurs de bugs autonomes fiables sur des cibles difficiles. Ensuite, ClaudeCode et Codex résolvent des ensembles d’instances complémentaires : leur union dépasse chacun pris séparément (un gain d’environ 18 % sur V8 et ~26 % sur SpiderMonkey par rapport au meilleur scaffold seul, selon les auteurs). Des scaffolds différents trouvent des bugs différents.
Pourquoi c’est important
C’est un papier de mesure de capacité, pas une attaque, mais les chiffres tranchent dans les deux sens et les deux publics doivent les lire attentivement.
Pour les attaquants, le résultat est dégrisant plus qu’alarmant : un agent prêt à l’emploi ne va pas miner de façon autonome des bugs V8 à 1,5 M$ aujourd’hui. Le battage autour d’une « IA qui trouve des zero-days à l’échelle » est, sur cette base, en avance sur la réalité pour les cibles les plus dures — cohérent avec ce qu’on a vu dans les empreintes de zero-days écrits par IA et l’échelle de capacité d’exploitation.
Pour les défenseurs, le constat de complémentarité est la partie actionnable. Si vous utilisez des agents de code pour la découverte proactive de vulnérabilités, un modèle unique laisse des bugs de côté ; un ensemble d’agents aux scaffolds variés augmente sensiblement la couverture. Et le plafond sous 40 % rappelle que la chasse aux bugs par IA augmente la revue humaine — elle ne la remplace pas. La trajectoire compte aussi : le plafond d’aujourd’hui n’est pas celui de demain, et la même compétence au long cours qui aide les équipes défensives aidera l’offensive — d’où l’intérêt de suivre des benchmarks honnêtes et sans harnais comme celui-ci. La difficulté plus large d’évaluer équitablement ces agents est exactement le problème pointé dans benchmarker les agents de sécurité, c’est difficile.
Défenses
Enseignements concrets pour les équipes qui adoptent l’IA en sécurité :
- Traitez la chasse aux bugs par IA comme une augmentation, pas une autonomie. Un taux de réussite sous 40 % sur des cibles difficiles signifie que des humains doivent trier, confirmer et assumer les résultats. Branchez la sortie des agents sur votre processus de revue existant, pas autour.
- Faites tourner des ensembles, pas un seul modèle. Comme ClaudeCode et Codex trouvent des bugs complémentaires, déployer plusieurs agents aux scaffolds différents augmente la couverture davantage que de mettre à niveau un seul d’entre eux. La diversité de scaffold bat le maximalisme mono-modèle.
- Benchmarkez sur votre propre code, sans harnais. La leçon de SEC-bench Pro : les indices et les harnais gonflent les scores. Évaluez fournisseurs et outillage interne sur des tâches réalistes et sans indice avant de croire une promesse de « détection automatique de vulnérabilités ».
- Anticipez la courbe, pas l’instantané. Construisez votre détection, votre divulgation et votre priorisation des correctifs en supposant que la capacité des agents continue de monter — la valeur défensive du red-teaming agentique qui compresse des semaines en heures s’applique symétriquement aux attaquants.
Statut
| Élément | Valeur |
|---|---|
| Publication | arXiv:2605.26548, 26 mai 2026 |
| Cibles | V8 et SpiderMonkey (183 vulnérabilités validées) |
| Classes de bugs | sûreté mémoire, bac à sable, JIT, conditions de course |
| Meilleure config seule | 32,0 % (V8) / 38,8 % (SpiderMonkey) |
| Union deux agents | 37,9 % (V8) / 48,8 % (SpiderMonkey) |
| Nature | Benchmark de capacité — aucun exploit publié |
C’est de la recherche publiée et relisable, avec une page de projet publique ; elle documente un plafond de capacité, pas une faille produit non corrigée. Le chiffre utile à retenir : sur des cibles vraiment difficiles et sans harnais, les meilleurs agents IA d’aujourd’hui résolvent bien moins de la moitié des bugs — et la façon de faire mieux passe par plus d’agents diversifiés et de la revue humaine, pas par une confiance aveugle en un seul modèle.