CWE-bench v2 : évaluer les IA en cybersécurité logicielle
Découvrez comment CWE-bench v2 évalue les agents IA sur 100 vulnérabilités réelles, ses résultats, ses limites et la manière de reproduire les tests.
CWE-bench v2 : mesurer ce que les agents IA savent vraiment corriger
Un agent d'intelligence artificielle peut-il repérer une vulnérabilité dans un vrai projet logiciel, la corriger sans casser le reste, et réussir de façon reproductible ? Les démonstrations "à la carte" répondent rarement à cette question. Elles prouvent qu'un modèle sait produire du code. Elles ne prouvent pas qu'il sait intervenir correctement dans un dépôt existant.
CWE-bench v2 veut évaluer cette capacité dans des conditions plus proches du travail de défense. Chaque tâche démarre à partir d'un dépôt open source réel et d'une consigne courte : repérer une faiblesse de sécurité, puis la corriger sans dégrader les fonctions existantes. Le benchmark fournit 100 tâches couvrant 91 catégories CWE, avec une notation automatisée et un ensemble pensé pour être rejoué.
L'intérêt n'est pas seulement le classement des modèles. La méthode aide aussi à juger la qualité des tests, le coût des essais, et les limites qui persistent souvent malgré les progrès. Voici ce que mesure réellement CWE-bench v2, comment interpréter ses résultats, et ce qu'une équipe peut en tirer avant d'essayer d'intégrer un agent à son processus de sécurité.
Que mesure CWE-bench v2 ?
CWE-bench v2 évalue la capacité d'un agent à effectuer une tâche de correction de sécurité dans un projet logiciel existant. L'agent reçoit une copie de travail d'un dépôt open source, plus une consigne brève. Son travail consiste à comprendre le contexte, trouver la faiblesse visée et proposer une modification qui la corrige sans rompre le comportement attendu.
Ce cadre est plus exigeant qu'une question de programmation "autonome". Dans un projet réel, la vulnérabilité ne se présente pas forcément comme un exemple minimal et isolé. Le modèle doit lire du code déjà structuré, déduire des contraintes "implicites", localiser le bon endroit pour intervenir, et éviter les changements trop étendus. Supprimer la fonction vulnérable peut faire disparaître le risque, mais ça peut aussi rendre le produit inutilisable - et le benchmark vise justement ce genre de piège.
Des tâches ancrées dans des dépôts réels
Le benchmark inclut 100 tâches réparties sur 91 catégories CWE, donc 91 familles de faiblesses logicielles. Cette diversité compte : une performance sur un type de problème ne dit pas grand-chose sur la capacité à raisonner sur d'autres surfaces d'attaque. Les erreurs de validation des entrées, les problèmes de contrôle d'accès ou les faiblesses de gestion des ressources ne se corrigent pas avec le même schéma.
Le chiffre de 91 catégories ne veut pas dire que chaque famille de vulnérabilités est couverte "à fond" ou de façon exhaustive. Il indique plutôt que l'évaluation veut sortir d'une simple répétition d'un même exercice. Pour une équipe, la bonne lecture est donc : un test de largeur et de robustesse, pas une certification.
La correction doit préserver l'usage
La tâche ne s'arrête pas à "faire disparaître" le problème. Le code de départ doit échouer aux vérifications prévues, et la correction de référence doit les faire passer. En parallèle, il faut confirmer que les fonctions légitimes continuent de fonctionner après le changement.
C'est une distinction pratique, pas un détail théorique. En production, bloquer une fonctionnalité métier peut être aussi grave qu'une vulnérabilité laissée telle quelle. CWE-bench cherche donc à juger deux choses à la fois : réduire le risque et préserver le comportement attendu.
Le benchmark cible ainsi les équipes qui comparent des modèles dans un scénario de maintenance logicielle défensive. Il ne mesure pas, à lui seul, la capacité à sécuriser une organisation complète, à détecter une attaque en cours, ou à remplacer une revue humaine. Il teste une compétence précise : produire une correction vérifiable, dans un dépôt donné.
Que disent les résultats sur les agents IA ?
Les résultats publiés montrent deux choses en même temps : les meilleurs modèles résolvent une part importante des tâches, mais on est loin d'un "problème résolu". Parmi les 11 modèles évalués dans les résultats rapportés, Gemini 4 Argon atteint 67,8 % en pass@1 et 81,0 % en pass@4. Claude Opus 5.5 suit de près : 67,3 % en pass@1 et 78,0 % en pass@4.
Le pass@1 correspond à la réussite avec une tentative. Le pass@4 indique si le modèle réussit au moins une fois parmi quatre tentatives. Ces deux mesures ne répondent pas exactement à la même question. Le premier score reflète davantage la fiabilité d'une exécution unique, tandis que le second montre ce que l'on peut obtenir en autorisant plusieurs essais - avec un coût de temps et de ressources.
Ce que dit l'écart entre pass@1 et pass@4
Quand pass@4 monte par rapport à pass@1, c'est souvent qu'une partie des tâches "passe" si le modèle a plusieurs occasions de corriger sa trajectoire. À l'inverse, un système qui ne réussit qu'après plusieurs essais peut être moins adapté à un flux automatisé, même s'il affiche de bonnes performances en pass@4.
Les auteurs précisent que 95 des 100 tâches ont été résolues par au moins un modèle. Ça suggère que, dans l'espace du benchmark, la majorité des exercices est atteignable. En revanche, même le modèle en tête échoue à chaque tentative sur 19 % de l'ensemble. Autrement dit : les tâches difficiles ne disparaissent pas juste parce qu'on a "le meilleur modèle".
Pour une entreprise, le score moyen ne suffit donc pas. Il faut regarder quels types de tâches posent problème, si les résultats tiennent dans le temps, et si les changements proposés restent raisonnables. Une équipe qui doit respecter des exigences réglementaires élevées ne peut pas avoir la même tolérance qu'une équipe qui utilise l'agent pour préparer des pistes de correction à relire.
Le coût fait partie du résultat
Le classement ne porte pas uniquement sur la réussite. Les résultats de coût montrent un compromis clair entre performance et dépenses par tentative. DeepSeek V4.1 Flash obtient 57,0 % en pass@1 pour environ 0,04 dollar par exécution. Claude Opus 5.5 gagne une dizaine de points, pour 1,83 dollar. Gemini 4 Argon progresse à 67,8 %, pour 3,92 dollars.
Ces chiffres décrivent une frontière coût/performance, pas une règle universelle. Le coût réel dépend notamment du nombre de tentatives, de la longueur des échanges avec le modèle et de l'infrastructure. Si vous travaillez en France ou en Europe, il faut aussi tenir compte des contraintes liées aux données, à la localisation et à la conformité au RGPD : le prix par appel ne donne pas à lui seul le coût opérationnel.
Le "bon" choix dépend donc du rôle confié à l'agent. Pour un outil d'assistance qui propose des correctifs à des développeurs, un modèle moins cher peut suffire. Pour une analyse plus exigeante, une équipe peut préférer un meilleur taux de réussite dès le premier essai, tout en gardant une revue humaine. Dans les deux cas, le benchmark donne une base de comparaison, pas une décision automatique pour l'entreprise.
Comment lancer CWE-bench v2 sur ses propres modèles ?
Les tâches sont fournies via des environnements Harbor autonomes. Chaque environnement contient un conteneur Docker, une consigne et un vérificateur déterministe. Le dépôt de données inclut un registre des tâches, ce qui permet à Harbor de récupérer le benchmark depuis le Hub, sans devoir cloner manuellement chaque projet.
Avant de lancer l'évaluation, il faut accepter les conditions d'accès au jeu de données, qui est restreint. Il faut aussi configurer l'authentification Hugging Face dans l'outil Git, car Harbor récupère les tâches avec Git. Enfin, l'agent choisi doit fonctionner dans l'environnement et pouvoir accéder au service du modèle utilisé.
Une commande reproductible
La commande ci-dessous lance quatre tentatives par tâche avec l'environnement Docker :
harbor run --repo "https://huggingface.co/datasets/collinear-ai/cwe-bench" -d cwe-bench@2.0 -k 4 \
--agent <agent> --model <model> --env docker \
--allow-agent-host <model API host>
Le paramètre -k 4 demande quatre tentatives par tâche. Le score communiqué correspond alors à la récompense moyenne sur 400 essais (100 tâches multipliées par quatre tentatives). Gardez ça en tête si vous comparez avec une mesure pass@1 : ce ne sont pas les mêmes protocoles.
Pour autoriser Git à utiliser le jeton Hugging Face enregistré, la procédure indiquée est la suivante :
hf auth login --token $HF_TOKEN --add-to-git-credentialLes options exactes dépendent ensuite de l'agent et du modèle évalués. Pour obtenir un résultat exploitable, documentez au minimum le nom et la version du modèle, l'agent, les paramètres, le nombre de tentatives, les coûts et les éventuelles erreurs d'environnement. Sans ces détails, un écart de score peut venir du protocole, pas du modèle.
Adapter l'évaluation au contexte de l'entreprise
Avant d'intégrer quoi que ce soit à un pipeline de production, une équipe a intérêt à commencer petit : lancer le benchmark dans un environnement isolé, puis regarder les échecs et les correctifs proposés. L'objectif est clair : vérifier si ce qui marche dans le benchmark correspond aux dépôts, aux langages et aux règles de revue de votre organisation.
CWE-bench v2 est aussi présenté comme un environnement d'apprentissage par renforcement. Les mêmes environnements et vérificateurs peuvent donc servir à produire des récompenses pour entraîner des agents défensifs, pas seulement à évaluer. C'est utile, mais ça ne supprime pas le risque d'un agent qui s'adapte aux limites d'un vérificateur. Autrement dit : optimiser "pour passer" n'est pas toujours optimiser "pour corriger proprement".
Les résultats sont suivis sur deux espaces du Hub. Une page de classement dédiée aux modèles à poids ouverts est mise à jour via des contributions de la communauté et de laboratoires. Un classement plus large inclut aussi les modèles accessibles uniquement par API, comme Gemini, Claude et GPT. Cette organisation facilite les contributions, mais elle oblige à comparer en gardant en tête les différences d'accès, de coût et de configuration.
Conclusion
CWE-bench v2 propose un cadre utile pour regarder une capacité souvent résumée trop vite : la correction de vulnérabilités par des agents IA. Avec ses 100 tâches, ses vérifications déterministes et ses résultats en pass@1, pass@4 et coût, il devient possible de comparer des modèles sur autre chose que des démonstrations ponctuelles.
Les résultats montrent des progrès, mais ils révèlent aussi un écart encore important entre "réussir un benchmark" et "déployer un correctif de façon fiable". La démarche la plus prudente pour une équipe technique reste de reproduire les tests, d'examiner les échecs, et de mesurer le coût complet avant toute intégration. Utilisez le score comme un indicateur de capacité, pas comme une preuve suffisante de sécurité.
Comment le benchmark cherche-t-il à garantir des tests fiables ?
Un benchmark de code n'a d'utilité que s'il évalue bien la compétence qu'il annonce. Un test trop simple se fait par mémorisation. Un test trop rigide peut rejeter une bonne correction sous prétexte qu'elle ne ressemble pas à la solution "attendue". Résultat : la qualité du vérificateur compte presque autant que la difficulté des tâches.
Pour CWE-bench v2, les contrôles sont déterministes et programmatiques. Les auteurs indiquent les avoir construits avec l'aide de panels de modèles jouant le rôle de juges, puis en vérifiant tâche par tâche. Leur objectif est d'aligner les tests sur un équilibre entre difficulté et équité. Les juges automatiques ne remplacent pas l'examen humain : ils servent à façonner les tests, et la validation manuelle reste une étape séparée.
Six questions de contrôle pour chaque tâche
La revue s'appuie sur plusieurs questions concrètes :
Cette grille vise à réduire des biais fréquents. Si la consigne n'apporte pas assez d'informations, un échec peut venir d'une ambiguïté. Si le test exige une implémentation précise, il mesure surtout la conformité à une forme de solution. Et si une correction déjà connue suffit, le benchmark peut récompenser plus la mémorisation que le raisonnement.
Un score reproductible, mais pas une vérité absolue
La notation programmatique permet à plusieurs équipes de rejouer les mêmes tâches et de comparer des résultats sans s'en remettre à une appréciation subjective après chaque réponse. C'est un vrai plus pour suivre l'évolution des modèles et vérifier une promesse publiée.
Mais cette reproductibilité ne règle pas tout. Les résultats dépendent de la configuration de l'agent, du modèle utilisé, du nombre de tentatives, des paramètres d'inférence et de l'environnement d'exécution. Une comparaison n'est pertinente que si ces éléments sont décrits et si les coûts sont pris en compte. Et même avec un bon score, rien ne dit que le correctif sera directement fusionnable : il faut toujours passer par les tests du projet, la revue de sécurité et la responsabilité de l'équipe.
Les auteurs gardent aussi un ensemble de tâches non divulguées pour suivre les progrès sur des cas que les modèles n'auraient pas vus. Cette séparation limite la contamination des évaluations publiques. Les résultats publics, eux, permettent surtout une comparaison reproductible sur les tâches ouvertes.