Mise à jour du 19 juillet : Depuis la publication initiale de ce blog, Kimi K3 a été lancé. Nous l'avons également benchmarké, et il a égalé GPT-5.6 pour le score le plus élevé, ne le devançant que légèrement en termes de capacités globales. Voir la section Kimi K3 à la fin pour plus de détails.
TL;DR
- GPT-5.6 obtient le score de rappel le plus élevé, atteignant un maximum de 23/26, devant grok-4.5 (20), les modèles Claude Opus (15 à 18), et tous les autres que nous avons testés. Cela signifie qu'il peut redécouvrir 88,5 % des CVE.
- L'option la plus coûteuse n'est pas nécessaire. Les variantes moins chères de GPT-5.6 se situent à un ou deux résultats de son modèle phare pour une fraction du coût, et le regroupement de quelques exécutions d'un modèle de milieu de gamme rivalise avec une seule exécution d'un modèle phare.
- Les exécutions de modèles sont incohérentes, mais le regroupement les rend gagnantes. Toute exécution individuelle manque des bugs qu'elle détecterait lors d'une autre ; exécuter un modèle plusieurs fois et regrouper les résultats (pass@3) surpasse de manière fiable une seule exécution d'un modèle plus puissant et plus cher.
- Le poids ouvert rattrape rapidement son retard. GLM-5.2 redécouvre déjà 59 % de l'ensemble (16/26), se situant au milieu du peloton des modèles propriétaires.
Chaque lancement de modèle de pointe s'accompagne désormais de la même affirmation en matière de cybersécurité : il détecte les vulnérabilités. Mais fonctionne-t-il sur un vrai bug dans un vrai dépôt, ou seulement sur un exemple sélectionné ? Parmi la douzaine de modèles que vous pourriez choisir, lequel mérite d'être utilisé pour la code review ? Et puisque les modèles les plus puissants coûtent dix fois ou plus par exécution que les moins chers, qu'est-ce que cet investissement supplémentaire vous apporte réellement en termes de bugs détectés ?
Il est facile de classer les modèles par capacité brute et de désigner le plus cher comme vainqueur, mais la question la plus importante est de savoir si le prix en vaut la peine. Nous avons donc testé 13 des modèles entre lesquels les équipes choisissent aujourd'hui contre 26 vulnérabilités connues de la base de données de conseils de GitHub. Ils couvrent un éventail de langages et de types de projets. Nous avons mesuré deux choses : combien de bugs chaque modèle a détectés et ce que cela a coûté pour les trouver.
Comment fonctionne le benchmark
Nous avons pris 26 vulnérabilités de la base de données de conseils de GitHub, réparties aléatoirement entre différents langages et types de projets, de l'injection SQL dans un framework web à une RCE par désérialisation dans une boîte à outils ML, et avons demandé à chaque modèle de les redécouvrir un dépôt à la fois à l'intérieur du même environnement d'analyse de code par IA que nous utilisons en production. Plutôt qu'une fenêtre de chat, il s'agit d'un modèle doté de véritables outils qui navigue dans le dépôt et raisonne sur le code comme le ferait un auditeur.
L'environnement est ce qui transforme un modèle de langage en auditeur. Un assistant de codage généraliste est conçu pour une tâche différente, qui consiste à prendre une tâche et à produire du code fonctionnel. Si vous le pointez vers un dépôt et lui demandez s'il est sécurisé, il se comporte comme un développeur qui recherche quelque chose d'évidemment cassé, puis s'arrête une fois qu'il a trouvé quelque chose de plausible. L'analyse de code par IA est construite différemment. Elle explore la base de code à la recherche de points d'entrée candidats, examine chaque flux suspect en profondeur, puis trie ce qui est remonté afin que seules les vraies vulnérabilités subsistent.
Parce que nous savions où se trouvait chaque vulnérabilité, nous avons dirigé chaque agent d'investigation directement vers l'extrait de code vulnérable. Ainsi, un échec reflète un problème de raisonnement plutôt qu'un budget gaspillé à explorer la mauvaise partie de la base de code. Le modèle doit toujours comprendre le flux, juger de l'exploitabilité et le signaler correctement. Les prompts ont été maintenus courts et agnostiques au modèle afin qu'aucun fournisseur ne soit avantagé par la formulation.
Nous avons exécuté chaque modèle trois fois et regroupé les résultats. Une CVE est considérée comme « trouvée » si le modèle la détecte lors de n'importe quelle exécution (pass@3).
Nous avons sélectionné une variété des derniers modèles de différents fournisseurs :
- OpenAI : gpt-5.4-nano, gpt-5.4-mini, gpt-5.5 et la série gpt-5.6 (luna / terra / sol)
- Anthropic : claude-haiku-4-5, claude-opus-4-7, claude-opus-4-8
- xAI : grok-4.5
- Google : gemini-3.1-pro, gemini-3.5-flash
- Poids ouverts : glm-5.2
Résultats par sévérité et vulnérabilité
Chaque modèle a redécouvert les deux CVEs critiques (une RCE par désérialisation et une XSS stockée). La véritable distinction apparaît sur les vulnérabilités de sévérité haute et moyenne.
CVEs les plus difficiles et les plus faciles
Les deux failles critiques et plusieurs failles d'injection/de contrôle d'accès évidentes ont été trouvées par chaque modèle. Cependant, quelques chaînes d'attaques spécifiques ont mis en échec la quasi-totalité d'entre eux.
Les CVEs que chaque modèle détecte partagent le même schéma : des entrées contrôlées par l'attaquant atteignant une opération dangereuse bien connue via un flux court et local, comme un appel de désérialisation, une exécution de shell, un sink HTML ou une vérification de signature défectueuse. Il s'agit de reconnaissance de motifs, et ce problème est effectivement résolu. Les modèles économiques et les modèles phares obtiennent tous un score de 13/13, sans aucune distinction de capacité.
La véritable frontière, et là où la capacité des modèles se distingue réellement, réside dans le raisonnement sur les vérifications manquantes et le suivi de chaînes complexes qu'aucune ligne unique ne révèle. Le cas le plus clair est SQL Injection-1 dans notre jeu de données, une injection indirecte via un alias de colonne que l'ORM n'échappe jamais. Seuls GPT-5.5 et les modèles GPT-5.6 les plus puissants (sol & terra) l'ont tracée.
Ce que la différence entre la moyenne et l'union nous apprend
Le chiffre le plus utile dans ce benchmark est l'écart entre la moyenne des exécutions d'un modèle et l'union de ses exécutions. Étant donné que chaque passe révèle un sous-ensemble différent des bugs, les regrouper (pass@3) permet de récupérer une quantité surprenante :
Prenons l'exemple de gpt-5.4-nano : aucune exécution individuelle n'atteint 14, pourtant trois exécutions regroupées atteignent 18, soit un bond de quatre CVEs, car chaque passe révèle des bugs différents. claude-haiku-4-5 est le cas le plus frappant de variance, avec un score de 7 sur une exécution et de 13 sur une autre pour le même modèle sur la même tâche.
La leçon à retenir ici est qu'il n'est pas nécessaire de se tourner directement vers le modèle le plus cher. Trois exécutions de gpt-5.4-nano coûtent environ 170 $ et atteignent 18/26, soit autant qu'une seule passe d'un modèle phare comme gpt-5.6-terra en moyenne, pour une fraction du prix. Trois exécutions de gpt-5.4-mini (environ 460 $) atteignent 20. Répéter un modèle de milieu de gamme solide surpasse une seule passe d'un modèle phare bien plus souvent que la différence de prix ne le suggère.
Le raisonnement supérieur en vaut-il la peine ?
Nous avons exécuté les modèles applicables à deux niveaux de raisonnement : le niveau par défaut « high » et leur niveau le plus élevé disponible (« xhigh » pour les modèles GPT-5.4/5.5 et Claude, « max » pour GPT-5.6, grok-4.5 et glm-5.2). Tous les chiffres sont des unions pass@3, ils sont donc directement comparables.
Les gains nets sont gpt-5.5 (+3 pour 1,5 fois le coût) et glm-5.2 (+3 pour 1,3 fois). claude-opus-4-8 gagne +2 mais en paie le double. Partout ailleurs, le niveau supérieur n'apporte qu'une seule découverte, voire aucune, et pour gpt-5.6-luna et gpt-5.4-nano, le résultat a été inférieur d'un point, dans la marge d'erreur des exécutions. gpt-5.6-terra est le cas le plus flagrant de rendements décroissants : 2,2 fois le coût pour le même score de 23.
Les modèles Gemini n'ont pas de réglage au-dessus de « high », ils sont donc omis de cette comparaison.
Mise à jour : Kimi K3
Après la rédaction de cet article, Kimi K3 a été lancé. Nous avons benchmarké Kimi K3 ce week-end et partagé les résultats. Kimi K3 est le modèle open source le plus puissant pour la cybersécurité, bien plus performant que GLM-5.2.
Voici les résultats :
- Bien que GPT-5.6-Sol soit toujours plus puissant, Kimi K3 est extrêmement proche, et pour une fraction du coût.
- Il offre des performances similaires à GPT-5.6-terra, tout en étant 15 % moins cher.
- Grâce à notre harnais spécialisé qui déploie plusieurs agents en parallèle, il est capable de redécouvrir 23/26 CVE sur notre harnais, égalant les modèles de pointe tout en étant 4 fois moins cher que GPT-5.6-Sol, le modèle le plus puissant d'OpenAI !
Le benchmark est privé et utilise des CVE récemment divulguées. Cela signifie que le modèle n'a pas été entraîné sur celles-ci. Les performances reflètent un très grand bond dans les capacités des modèles Kimi.
Conclusion
Dirigez un modèle de pointe vers une base de code, au sein d'un environnement conçu pour cette tâche, et il redécouvre la plupart des vulnérabilités connues. Les bugs avec un sink dangereux évident sont résolus. Ceux qui distinguent encore les modèles n'ont pas de sink à cibler : une vérification d'autorisation manquante, ou une injection que l'on ne peut atteindre qu'en suivant une longue chaîne obscure à travers plusieurs fichiers.
Le niveau le plus cher justifie rarement son prix. Exécuter un modèle moins cher plusieurs fois et regrouper les résultats permet de trouver plus de vulnérabilités, pour moins cher, qu'une seule passe d'un modèle phare, et cet avantage ne fait que croître à mesure que les modèles deviennent moins chers et plus performants. L'environnement est toujours ce qui détermine si ce raisonnement est d'abord dirigé vers la bonne partie de la base de code.
