Le benchmark CyberGym expliqué : ce que mesure réellement le score E2E

Le score CyberGym qui circule le plus largement — le chiffre de la publication de lancement, celui que l’on compare d’un modèle à l’autre — est un taux de réussite aux tâches sur 131 tâches filtrées, où réussir signifie qu’un agent a produit une entrée de preuve de concept qui fait planter une version compilée C/C++ non corrigée, a écrit un correctif qui met fin à ce plantage et n’a pas cassé les tests écrits par les développeurs du projet. Dans la compilation de BenchLM, MiMo-V2.6-Flash mène avec 95,1 % et MiMo-V2.6-Pro avec 94,0 %, DeepSeek-V4.1-Flash étant quelques points derrière, dans les 85 à 89 %. Presque personne, parmi ceux qui citent ce tableau, ne mentionne trois choses qui déterminent si les chiffres sont comparables : le benchmark existe en plusieurs implémentations, la plupart des lignes sont des auto-déclarations de fournisseurs plutôt que des exécutions indépendantes, et l’étape la plus intéressante est consignée mais non comptabilisée. C’est la même norme d’attribution que l’archive des incidents d’IA applique à ses propres entrées — une affirmation sans source n’est pas un résultat — et le corpus CyberGym y échoue plus souvent que sa réputation ne le suggère.

Ceci est un guide de ce que le benchmark demande à un agent de faire, comment l’ensemble de tâches a été construit, où les implémentations divergent, et ce qu’un défenseur devrait et ne devrait pas conclure d’un score élevé.

La tâche : trouver, reproduire, corriger — sans rien casser

CyberGym provient du Berkeley Center for Responsible, Decentralized Intelligence, et sa prémisse est délibérément étroite. Chaque tâche cible une vulnérabilité de sûreté mémoire dans un projet C/C++ open source largement utilisé. L’agent doit localiser le bug, écrire une entrée de preuve de concept qui déclenche un plantage du sanitizer, puis corriger le code afin que le plantage ne se reproduise plus — tout en veillant à ce que les tests propres au projet continuent de passer. Cette séquence constitue tout l’enjeu. Un benchmark qui se contenterait de demander « trouver le bug » récompenserait la reconnaissance de motifs ; exiger une entrée de plantage fonctionnelle et un correctif non cassant force l’agent à fermer la boucle entre le soupçon, le défaut démontré et la correction.

RDI héberge ce benchmark au sein d’un observatoire plus large qui suit les capacités cyber de l’IA à travers les phases d’attaque et de défense, et ce cadrage mérite attention : CyberGym est un instrument sur un banc, aux côtés d’ExploitGym et de la variante de bout en bout. Le lire comme un classement autonome fait perdre ce contexte, ce qui explique en partie pourquoi les chiffres se transposent mal.

Quatre étapes, dont trois sont prises en compte dans le score

La règle de notation est l’élément le moins signalé du benchmark, car c’est là qu’un score d’apparence plausible peut s’écarter de ce qui s’est réellement produit.

Étape 1 est la reproduction : l'entrée de preuve de concept de l'agent fait-elle planter la version non corrigée. Étape 2 est le correctif : la modification soumise empêche-t-elle ce plantage spécifique. Étape 3 est la régression : les tests fonctionnels écrits par le développeur passent-ils toujours. Ces trois éléments produisent le score.

Étape 4 demande si le correctif élimine la vulnérabilité réelle de référence, et il est consigné à titre de diagnostic plutôt que compté dans le score. Cette asymétrie mérite qu'on s'y arrête un instant, car c'est la différence entre « l'agent peut faire disparaître un plantage » et « l'agent peut corriger le bug ». Les deux affirmations sont utiles ; ce ne sont pas la même affirmation. Un agent qui supprime un plantage en interceptant le signal, en élargissant un contrôle de limites au-delà du débordement, ou en désactivant entièrement le chemin de code, obtiendra un score aux étapes 1 à 3 et échouera à l'étape 4. Si un compte rendu ne donne qu'un seul chiffre sans préciser si l'étape 4 a été consultée, vous ne pouvez pas savoir laquelle des deux choses a été mesurée — et le diagnostic existe précisément pour que vous puissiez poser la question.

Comment les 131 tâches ont été choisies — et quel effet cela a sur le score

{{1}}Le jeu de données source est plus grand que l’ensemble évalué{{/1}}, et le filtrage est le facteur le plus déterminant pour la comparabilité. {{2}}Le jeu de données de RDI contient 920 vulnérabilités réparties sur 139 projets open source, issues d’OSS-Fuzz de Google.{{/2}} La variante de bout en bout utilisée par les outils de suivi tiers la réduit à 131 tâches, avec une tâche par projet, sélectionnées par difficulté, en excluant les tâches présentant des fuites d’oracle ou des contraintes de compatibilité avec le bac à sable.

Trois conséquences en découlent directement. Premièrement, une tâche par projet signifie que le score est dominé par l’étendue plutôt que par la profondeur : un agent moyen sur de nombreux projets surpassera un agent excellent sur trois, ce qui est un choix de conception défendable et une mesure différente de « combien de vulnérabilités cet agent peut-il corriger ». Deuxièmement, exclure les fuites d’oracle supprime les tâches où la réponse peut être découverte à partir de l’environnement plutôt que raisonnée, donc l’ensemble restant est plus difficile d’une manière spécifique — cela supprime des raccourcis plutôt que de supprimer des tâches faciles. Troisièmement, un budget de 90 minutes par tâche à l’intérieur d’un bac à sable construit à partir de l’image OSS-Fuzz du projet fait partie de la définition de la réussite, pas un détail, car une grande part du travail réel sur les vulnérabilités est bornée par exactement ce type de contrainte et les agents qui dépendent d’une exploration illimitée échoueront ici tout en réussissant ailleurs.

Toute comparaison qui ignore la règle de sélection des tâches revient à comparer deux tests différents qui se trouvent porter le même nom.

Deux implémentations, et pourquoi elles ne doivent pas nécessairement concorder

C'est là que réside l'essentiel de la confusion. CyberGym-E2E existe en tant que benchmark RDI et en tant qu'implémentation exécutée par un évaluateur tiers, et les deux ne sont pas garantis de produire le même nombre pour le même modèle. La documentation de l'évaluateur le dit clairement : son implémentation utilise un ensemble filtré de 131 tâches, une par projet, choisies selon leur difficulté, et elle exécute chaque tâche dans un bac à sable isolé construit à partir de l'image OSS-Fuzz du projet, à l'aide de son propre harnais d'agent avec un budget de 90 minutes par tâche.

Cette phrase contient les deux variables qui déterminent le score. Le harnais est la boucle dans laquelle l'agent évolue — comment il observe la sortie des outils, combien d'étapes il peut effectuer, comment il se remet d'une tentative échouée. Un harnais plus fort avec un modèle plus faible peut battre l'inverse, et le harnais ne fait pas partie des poids du modèle. Le budget interagit avec les deux. Ainsi, un chiffre CyberGym s'écrit correctement comme « ce modèle, dans ce harnais, dans cette implémentation », et un chiffre cité sans l'implémentation est un nombre sans dénominateur.

Il y a un effet de second ordre qu’il vaut la peine de souligner : comme le harness effectue un véritable travail, une amélioration du score CyberGym entre deux versions d’un modèle peut en partie être une amélioration du harness, et un fournisseur qui rapporte les résultats de son propre harness rapporte une capacité du système plutôt qu’une capacité du modèle. Les deux sont légitimes ; les confondre ne l’est pas.

Lire honnêtement le tableau de suivi

Le tableau que la plupart des gens rencontrent est une compilation secondaire, et il indique sa propre provenance — ce qui est la partie utile, si l’on lit l’étiquette. Sur les 29 lignes, 7 proviennent du propriétaire du benchmark ou d’une exécution indépendante, 21 sont des auto-déclarations de fournisseurs, et une est un rapport secondaire. La compilation déclare sans détour qu’elle présente le tableau à titre de référence et qu’elle ne classe pas sur cette base, et conseille de le lire avec prudence car la plupart des lignes sont des auto-déclarations. Sa propre note sur la saturation est la ligne la plus utile de la page : les trois premiers s’étalent sur environ 70 points tandis que les dix premiers tiennent dans à peu près 10, donc le tableau sépare encore les modèles — mais pas au sommet de la plage, où l’ordre est ténu.

Un rapport auto-déclaré de fournisseur est une preuve affichable. Ce n’est pas une mesure indépendante, et cette différence compte dans ce benchmark plus que dans la plupart, car la variable du harnais laisse à un fournisseur une marge considérable pour ajuster le chiffre qu’il déclare. Lorsqu’un rapport auto-déclaré et une exécution indépendante divergent, c’est l’exécution indépendante qui l’emporte. Lorsqu’il n’existe qu’un rapport auto-déclaré, la lecture honnête est « non vérifié, plausible, sans référence comparable ».

La même prudence s’applique, inversement, au piège que ce benchmark tend aux lecteurs : un modèle sans ligne CyberGym n’a pas obtenu zéro. Il n’a pas été mesuré dans ce harnais, ce qui est une affirmation différente. Traiter l’absence comme un échec, c’est ainsi qu’un tableau cesse d’être une mesure et devient un classement.

Ce qu’un score élevé signifie et ne signifie pas pour un défenseur

La question qu’une équipe de sécurité se pose réellement n’est pas « quel modèle arrive en tête du classement », mais « quel impact un agent qui obtient un bon score à ce benchmark a-t-il sur mon risque ». Le benchmark répond à une question plus étroite que celle qui est posée, et cet écart mérite d’être nommé.

Cela signifie que l’agent peut, en 90 minutes et dans un build connu, localiser un bug de sûreté mémoire dans du code open source réel, produire une entrée de plantage fonctionnelle et écrire une modification qui met fin au plantage sans casser les tests. C’est une capacité authentique, directement pertinente pour le triage et le travail de correction, et c’est le genre de tâche où un agent compétent réduit sensiblement la file d’attente d’un analyste.

Cela ne signifie pas que l'agent comprend votre base de code, votre modèle de menace ou votre déploiement. Les tâches sont tirées de cibles OSS-Fuzz publiques dont la vulnérabilité de référence est connue et qui disposent d'une suite de tests indiquant à l'agent s'il a terminé. Le code de production n'offre pas un tel oracle. Cela ne signifie pas non plus que l'agent trouvera le bug plutôt qu'un bug : l'étape 4 existe précisément parce que ces cas divergent, et l'étape 4 n'entre pas en compte.

Et cela ne se transpose pas du côté offensif, où la même capacité prend un sens différent. Un agent capable de localiser et de reproduire une faille de sécurité mémoire peut le faire dans du code qu'il n'a pas été autorisé à tester, et c'est précisément pourquoi une capacité de cet ordre justifie un contrôle d'accès au niveau du modèle plutôt qu'un avertissement dans une invite système.

Que demander avant de faire confiance à un chiffre CyberGym ?

Cinq questions auxquelles un rapport bien rédigé permet de répondre et auxquelles un article de lancement ne permet généralement pas de répondre.

• Quelle implémentation ? Le benchmark de RDI, ou une variante filtrée d'un évaluateur tiers. Si le rapport ne le précise pas, le chiffre n'est comparable à rien.

• Qui a réalisé le test ?Évaluation indépendante ou autodéclaration du fournisseur. Le tableau de compilation l’indique ligne par ligne ; la plupart des supports marketing ne le font pas.

• Quel banc d’essai, et quel budget ? Si le banc d’essai est celui du fournisseur et n’est pas décrit, considérez le résultat comme une affirmation au niveau du système concernant une configuration produit spécifique.

• L’étape 4 a-t-elle été consultée ? Un taux signalé accompagné du diagnostic vous indique si les correctifs ont corrigé le bogue ou ont simplement fait taire le plantage.

• Quel ensemble de tâches ? Les 131 tâches, une par projet, choisies selon leur difficulté constituent l’ensemble courant ; un filtre différent correspond à un test différent.

Cybergym est un benchmark bien construit pour une tâche difficile et réelle, et sa construction est plus intéressante que son classement. Les étapes indiquent ce qu’un agent devait faire ; le filtrage indique ce que le score mesure ; le harnais indique à qui revient le crédit. Un chiffre qui arrive avec ces trois éléments attachés est réellement utile. Un chiffre qui arrive seul est un communiqué de presse avec un signe de pourcentage.