Snyk VulnBench JS 1.0 : les LLM peuvent-ils détecter deux fois les mêmes bugs ?

Nous avons effectué 300 analyses de détection de vulnérabilités afin de mesurer la reproductibilité d’une revue de sécurité agentique par LLM sur un même code, avec le même prompt et le même environnement d’exécution. Le principal résultat n’est pas qu’un scanner « gagne » un classement autoréférentiel. C’est que les résultats de sécurité des LLM sont inégalement reproductibles : les détections correspondant à la référence étaient stables, mais les signalements supplémentaires des modèles variaient considérablement d’une exécution à l’autre.

En clair, lorsque Claude signalait des bugs absents de la liste de référence de Snyk Code, ces signalements supplémentaires étaient souvent incohérents. Sur 250 exécutions de modèles, 80 des 161 détections uniques non concordantes n’apparaissaient que dans une seule des cinq répétitions identiques, tandis que seulement 22 figuraient dans les cinq. En revanche, lorsque Claude détectait une vulnérabilité de référence, son comportement était beaucoup plus stable : 134 des 158 détections uniques correspondant à la référence apparaissaient dans les cinq répétitions. Cette différence est au cœur des résultats de Snyk VulnBench JS 1.0.

Le benchmark met également en évidence la complémentarité. Les modèles ont détecté de façon constante des schémas d’exploitation connus et à fort signal et, dans un cas, ont révélé une lacune probable dans les détections de Snyk Code. Snyk Code SAST était déterministe et plus performant pour énumérer systématiquement les flux de données répétés, tout en conservant des temps d’exécution nettement plus rapides pour l’analyse des vulnérabilités. Aucun de ces résultats ne justifie de remplacer une technique par l’autre. Les données plaident en faveur de leur association.

Points clés :

• La configuration LLM offrant le meilleur rappel n’a détecté que 81 % des vulnérabilités de référence de Snyk Code.

• La configuration LLM la mieux notée a atteint un F1 de 75,4 % par rapport à la référence Snyk, soit un écart de 24,6 points avec la reproduction déterministe de la référence par SAST.

• Près de 50 % des signalements de vulnérabilités propres aux LLM n’apparaissaient que dans 1 analyse sur 5 identiques.

• Le LLM offrant le meilleur rappel générait aussi le plus de bruit : 41 % de ses signalements ne figuraient pas dans l’ensemble de référence de Snyk Code.

• Dans le scénario d’application le plus complexe, le meilleur modèle n’a obtenu qu’un F1 de 40,0 % par rapport à la référence Snyk et a manqué à plusieurs reprises des vulnérabilités de traversée de chemin et de limites de ressources.

Pourquoi la reproductibilité est essentielle aux revues de sécurité par LLM

Les agents de programmation font désormais partie du cycle de développement. Ils écrivent du code, modifient les pull requests, expliquent les changements et sont de plus en plus utilisés pour effectuer des revues de sécurité du code et des applications avant même qu’une personne ne lise le diff. La fiabilité devient donc un enjeu produit : si le même agent examine deux fois le même code vulnérable, signale-t-il deux fois les mêmes problèmes de sécurité ?

Les outils SAST traditionnels sont conçus pour être déterministes. Si le code et les règles ne changent pas, les résultats ne devraient pas changer non plus. Les LLM fonctionnent différemment. Ils peuvent analyser du code qu’ils ne connaissent pas, décrire les risques dans un langage utile et parfois repérer des problèmes qui échappent à un analyseur statique. Mais leurs résultats peuvent aussi varier d’une exécution à l’autre, signaler excessivement des problèmes connexes ou s’arrêter après avoir trouvé un exemple représentatif d’un schéma répété.

Snyk VulnBench JS 1.0 a été conçu pour quantifier ce comportement. Le benchmark s’appuie sur de petites applications JavaScript et Express, de sorte que chaque exécution peut être examinée. L’objectif n’est pas de simuler un monorepo entier, mais de mesurer le comportement des modèles dans des conditions répétées et contrôlées.

Conception du benchmark : 300 analyses de sécurité répétées

Le benchmark comprend 10 projets JavaScript de test et 44 détections de référence Snyk Code. Chaque projet est une petite application basée sur Express, allant d’exemples compacts dans un seul fichier à une application de tâches plus vaste avec des routes serveur, un état de base de données, des téléversements et du JavaScript côté client.

Nous avons évalué six configurations :

Chaque configuration a exécuté chaque tâche cinq fois : 10 tâches x 6 configurations x 5 répétitions = 300 exécutions. Les configurations de modèles utilisaient le même prompt d’audit direct et renvoyaient les détections sous forme de JSON structuré. Le modèle pouvait lire les fichiers du projet, mais pas le fichier de référence findings.json.

Snyk Code définit l’ensemble de référence de ce benchmark. Son score de 100 % ne constitue donc pas une affirmation d’exactitude pour toutes les vulnérabilités possibles dans les projets. Il signifie que Snyk Code a reproduit ses propres détections de référence de manière déterministe lors des exécutions répétées. Nous utilisons cet ensemble de référence pour mesurer la concordance avec les modèles, leur variabilité et les écarts de leur comportement.

Le système d’évaluation est volontairement permissif : une détection du modèle est comptabilisée si elle signale le même type de vulnérabilité qu’une détection de référence. Il n’est pas nécessaire qu’elle corresponde au même fichier, à la même ligne, à la même gravité ou au même flux source-destination. Nous présentons le F1 par rapport à la référence Snyk : la moyenne harmonique de la précision et du rappel lorsque les détections de Snyk Code constituent l’ensemble de référence. C’est une mesure utile de concordance, mais ce n’est pas l’essentiel.

Comme ce benchmark ne s’appuie pas sur un jeu de vérité terrain indépendant et exhaustivement vérifié, le F1 par rapport à la référence Snyk ne doit pas être interprété comme une mesure de l’exactitude réelle de la détection des vulnérabilités. Un modèle moins concordant avec la référence Snyk Code pourrait obtenir un meilleur score par rapport à une vérité terrain indépendante si certaines de ses détections non concordantes sont valides ou s’il évite des problèmes exagérés par l’ensemble de référence. Dans ce rapport, le F1 par rapport à la référence Snyk répond à une question plus restreinte : dans quelle mesure les détections des modèles correspondent-elles aux détections de référence de Snyk Code, et avec quelle reproductibilité ?

Résultat 1 : la reproductibilité des LLM variait selon la configuration du modèle

Au niveau des configurations, la reproductibilité se mesure par le rapport entre le score et la variance. Le meilleur résultat se situe en haut à gauche : forte concordance avec l’ensemble de référence et faible variance entre les exécutions répétées. Snyk Code SAST occupe cette position avec un F1 de 100,0 % par rapport à la référence Snyk et un écart-type de 0,0 point de pourcentage, car il a reproduit son ensemble de référence de manière déterministe. Les configurations Claude sont réparties plus bas et à droite, Claude Sonnet 4.6 High affichant la variance la plus élevée, à 3,5 points de pourcentage.

Figure 1 : F1 par rapport à la référence Snyk en fonction de l’écart-type de ce F1. Les meilleurs points se rapprochent du coin supérieur gauche : score de concordance plus élevé et variance plus faible entre les exécutions. Snyk Code SAST est indiqué en violet, avec une variance nulle.

Le nuage de points met en évidence deux éléments. D’abord, le rôle de Snyk Code dans ce benchmark est de reproduire une référence de manière déterministe, et non d’effectuer une revue probabiliste. Ensuite, les configurations des modèles ne se classent pas selon leur coût ou leur nouveauté : Claude Opus 4.6 Medium et High sont proches l’un de l’autre, avec une faible variance et les meilleurs F1 parmi les modèles, tandis que Claude Opus 4.7 Max et Claude Sonnet 4.6 High se trouvent plus à droite, ce qui signifie que leurs résultats variaient davantage d’une exécution à l’autre.

Toutes configurations de modèles confondues, 80 des 161 signatures de détection uniques et non concordantes n’apparaissaient que dans une seule des cinq exécutions répétées. Ce résultat global explique en partie la variance, mais nous examinons aussi une vue potentiellement plus utile : la comparaison entre modèles :

Figure 2 : Part des signatures de détection uniques et non concordantes de chaque configuration de modèle apparues dans une seule des cinq exécutions répétées. Signature = tâche + type de vulnérabilité + fichier + ligne, regroupés par configuration de modèle.

Le tableau ci-dessous présente les valeurs exactes du graphique précédent, ainsi que les deux indicateurs de stabilité les plus importants.

L’instabilité n’est pas répartie uniformément entre les modèles. Claude Sonnet 4.6 Medium a produit le plus grand nombre de détections non concordantes, avec 60 signatures uniques ; 37 d’entre elles ne sont apparues que dans une seule des cinq exécutions. Claude Sonnet 4.6 High et Claude Opus 4.7 Max ont affiché une tendance similaire : de nombreux signalements supplémentaires n’apparaissaient qu’une fois et ne se répétaient pas. À l’inverse, les 0,0 % de Claude Opus 4.6 Medium dans le graphique indiquent une grande stabilité et peu de détections ponctuelles : tous ses signalements supplémentaires ont été relevés dans au moins deux exécutions, et aucun dans une seule des cinq répétitions.

Les configurations Opus 4.6 se sont comportées différemment. Elles ont produit beaucoup moins de détections non concordantes, et leurs signalements supplémentaires étaient plus stables. Cela ne signifie pas que tous ces signalements sont corrects, mais change leur interprétation opérationnelle : moins de détections inattendues, moins d’alertes ponctuelles et moins de fluctuations dans le triage.

Le graphique ci-dessous montre que la plupart des configurations autres que Opus 4.6 ont eu du mal à produire des détections supplémentaires (non concordantes) stables lors des exécutions répétées. Claude Sonnet 4.6 Medium et High ont toutes deux affiché une faible reproductibilité : seuls 8,3 % et 9,3 % de leurs détections non concordantes figuraient dans les cinq exécutions. Claude Opus 4.7 Max a également obtenu de mauvais résultats, avec une stabilité de seulement 16,7 %. À l’inverse, Opus 4.6 Medium et High ont affiché une stabilité nettement supérieure de leurs détections non concordantes (60,0 % et 50,0 %, respectivement), soulignant le caractère moins prévisible et plus bruyant des détections non concordantes de Sonnet et de la configuration Claude Opus 4.7 Max, plus récente.

Figure 3 : Part des signatures de détection uniques non concordantes présentes dans les cinq exécutions répétées pour chaque configuration de modèle.

Les détections concordantes racontent une autre histoire. Lorsqu’un modèle détectait une vulnérabilité de référence Snyk Code, il la détectait généralement de façon répétée. Claude Opus 4.6 Medium a détecté 25 vulnérabilités de référence uniques et a retrouvé les 25 dans les cinq exécutions. Claude Opus 4.6 High en a retrouvé 25 sur 26. Même les configurations Sonnet plus bruyantes ont retrouvé 29 des 36 détections concordant avec la référence.

Figure 4 : Part des détections de référence uniques de Snyk Code retrouvées dans les cinq exécutions répétées pour chaque configuration de modèle.

La figure 4 illustre la reproductibilité des détections concordantes. Toutes configurations de modèles confondues, 134 des 158 détections de référence uniques concordantes apparaissaient dans les cinq répétitions (84,8 %). Autrement dit, lorsqu’un modèle repérait une détection de référence Snyk Code connue, il le faisait généralement de manière fiable. Le contraste avec la figure 5 constitue le principal résultat : les vrais positifs étaient généralement stables, tandis que les signalements supplémentaires absents de la référence étaient beaucoup plus fluctuants.

Figure 5 : Répartition des détections uniques non concordantes des modèles selon la fréquence d’apparition de la même signature de détection au cours de cinq répétitions d’une même tâche et configuration de modèle. Signature = tâche + configuration + type de vulnérabilité + fichier + ligne.

Près de la moitié des détections uniques non concordantes des modèles n’apparaissaient que dans une seule des cinq répétitions identiques. C’est un problème concret de fiabilité : selon l’exécution lancée, un développeur pourrait obtenir une file de revue sensiblement différente.

Voici la répartition exacte illustrée par ce graphique :

Résultat 2 : les agents LLM et SAST ont détecté différentes lacunes de sécurité

L’interprétation la plus utile n’est pas « LLM contre SAST », mais « LLM et SAST détectent différents types de défaillances ».

La meilleure façon de le voir est d’examiner les catégories de vulnérabilités. La carte thermique ci-dessous présente le rappel moyen par rapport à l’ensemble de référence Snyk Code, selon le type de vulnérabilité et la configuration. Snyk Code affiche 100 %, puisqu’il définit et reproduit l’ensemble de référence. Les lignes des modèles montrent dans quels cas les revues agentiques concordent avec cette référence et dans quels cas elles sont moins performantes.

Figure 6 : Rappel moyen par rapport à l’ensemble de référence Snyk Code, selon le type de vulnérabilité et la configuration. Snyk Code représente une reproduction déterministe de la référence ; les lignes des modèles montrent, par catégorie, les points de concordance et les lacunes des revues agentiques.

Les configurations de modèles ont été les plus performantes sur les formes d’exploitation familières et fortement signalées : l’injection de commandes, l’injection de code, les identifiants codés en dur, l’injection SQL, les SSRF, les redirections ouvertes, la pollution de prototypes et les ReDoS ont souvent été détectés correctement. Elles ont été moins performantes pour détecter les limites de ressources, les erreurs de sanitisation, les problèmes de validation des types, les transports non sécurisés, l’exposition d’informations par les frameworks et les flux répétés de traversée de chemin.

Cette tendance est visible dans js-project-tigerteam, où toutes les configurations de modèles ont détecté de façon constante le mot de passe de base de données codé en dur, le XSS réfléchi, la traversée de chemin et l’injection de commandes lors des 25 répétitions de chaque modèle.

1app.get("/greet", (req, res) => {
2  const name = req.query.name;
3  res.send(`<html><body><h1>Hello, ${name}!</h1></body></html>`);
4});
5
6app.get("/file", (req, res) => {
7  const filename = req.query.filename;
8  const basePath = "/var/app/public/";
9  fs.readFile(basePath + filename, "utf8", (err, data) => {
10    if (err) return res.status(404).send("Not found");
11    res.send(data);
12  });
13});
14
15app.get("/ping", (req, res) => {
16  const host = req.query.host;
17  exec("ping -c 1 " + host, (err, stdout, stderr) => {
18    if (err) return res.status(500).send("Error");
19    res.send(`<pre>${stdout}</pre>`);
20  });
21});

Mais le même exemple comprenait une fonction auxiliaire fictive présentant les caractéristiques d’une requête SQL :

1function dbQuery(sql) {
2  console.log("Query:", sql);
3  return [];
4}
5
6app.get("/users", (req, res) => {
7  const username = req.query.username;
8  const sql = "SELECT * FROM users WHERE username = '" + username + "'";
9  const results = dbQuery(sql);
10  res.json(results);
11});

Les modèles ont signalé une injection SQL lors de 25 exécutions sur 25 de js-project-tigerteam. Dans cet exemple, Snyk Code a eu raison de ne pas la signaler : dbQuery() consigne la chaîne et renvoie un tableau vide. Il n’y a pas de point d’entrée SQL exécutable. C’est le genre de cas où un LLM peut confondre du code qui ressemble à une vulnérabilité avec une vulnérabilité exploitable.

js-project-nightowl a montré la leçon inverse. Les 25 exécutions du modèle ont toutes signalé une injection SQL absente du jeu de référence de Snyk Code ; cette fois, le signal du modèle est probablement utile :

1deleteTodo: (id) => db.prepare("DELETE FROM todos WHERE id = " + id).all(),

Ce résultat a été comptabilisé comme non concordant, car il ne figurait pas dans le jeu de référence de Snyk Code. Il ne faut pas le rejeter comme une hallucination. Il s’agit probablement d’une lacune réelle du produit à examiner. Le benchmark est plus solide, et non moins, parce qu’il a mis ce cas en évidence ; nous intégrons ces enseignements en interne afin d’améliorer les capacités de détection de Snyk.

Figure 7 : nombre moyen de signalements non concordants par exécution de modèle, selon le type de vulnérabilité et la configuration du modèle. Cela inclut les faux positifs des modèles, les commentaires de revue connexes et les candidats susceptibles de révéler des lacunes du produit en dehors du jeu de référence de Snyk Code.

Cette deuxième carte thermique montre l’autre aspect de la complémentarité : les signalements supplémentaires des modèles ne constituent pas une catégorie homogène. Certains sont probablement des faux positifs, comme la fonction auxiliaire fictive présentant les caractéristiques d’une requête SQL mais non exécutable dans js-project-tigerteam. D’autres sont des commentaires connexes de revue de sécurité, hors du périmètre du jeu de référence. Certains, comme le signalement d’injection SQL dans js-project-nightowl, sont probablement des résultats valides qui devraient contribuer à améliorer la couverture de Snyk Code.

La complémentarité joue également dans l’autre sens. js-project-nightowl est l’exemple le plus proche d’une véritable application dans JS 1.0 : server.js compte 198 lignes, auxquelles db.js et public/app.js ajoutent 183 lignes de JavaScript. Il comprend du routage, des téléversements, la suppression de pièces jointes, des téléchargements et un état de base de données. Claude Opus 4.6 High a été parfaitement stable sur cet exemple, mais n’a obtenu qu’un score F1 de 40,0 % par rapport aux références de Snyk. Sur cinq répétitions, il a manqué toutes les vulnérabilités de traversée de chemin du jeu de référence et deux des trois cas de vulnérabilité liés aux limites de ressources.

Figure 8 : score moyen du benchmark pour l’exemple plus volumineux réparti sur plusieurs fichiers. Les barres d’erreur indiquent l’écart-type entre les exécutions répétées.

Les cas manqués concernaient des flux répétés de traitement des pièces jointes :

1if (req.file) {
2  if (existing.attachment_stored_name) {
3    fs.unlink(path.join(UPLOADS_DIR, existing.attachment_stored_name), () => {});
4  }
5  updates.push("attachment_original_name = ?", "attachment_stored_name = ?");
6  values.push(req.file.originalname, req.file.filename);
7} else if (req.body.removeAttachment === true || req.body.removeAttachment === "true") {
8  if (existing.attachment_stored_name) {
9    fs.unlink(path.join(UPLOADS_DIR, existing.attachment_stored_name), () => {});
10  }
11}

Le modèle a détecté quelques problèmes représentatifs, puis n’a pas réussi à répertorier tous les points d’entrée vulnérables répétés. C’est précisément là que l’analyse déterministe des flux de données est utile. La couverture SAST et l’analyse par modèle ne font pas double emploi : ce sont des instruments différents, avec des angles morts différents.

Résultat 3 : des exécutions de LLM plus coûteuses n’ont pas amélioré la couverture

Claude Opus 4.7 Max était la configuration de modèle la plus coûteuse de cette série, mais pas la plus performante. Elle a consommé en moyenne 95 969 jetons et coûté 0,3559 $ par session de modèle. Claude Opus 4.6 Medium a consommé en moyenne 51 574 jetons et coûté 0,0628 $ par session. Opus 4.7 Max coûte donc 5,67 fois plus cher et utilise 1,86 fois plus de jetons, tout en obtenant un score inférieur : 68,8 % de F1 par rapport aux références de Snyk, contre 75,4 % pour Opus 4.6 Medium.

Figure 9 : compromis coût/qualité pour les modèles uniquement. Les meilleurs résultats se situent en haut à gauche : un score F1 plus élevé par rapport aux références de Snyk, pour un coût estimé par session de modèle inférieur.

Les montants absolus sont faibles, car les exemples sont de petite taille. Mais la question du passage à l’échelle est bien réelle. Dans les dépôts, les contrôles de sécurité s’exécutent pendant les sessions d’agents de codage, à chaque commit et demande de tirage, ainsi que dans les tâches CI, sur des bases de code bien plus volumineuses que ces extraits. Une inférence plus coûteuse n’offre pas automatiquement une meilleure couverture de sécurité.

Scores de concordance avec le jeu de référence de Snyk Code

Le score F1 par rapport aux références de Snyk reste utile, à condition de le décrire avec précision : il mesure la concordance avec le jeu de référence de Snyk Code. Selon cette métrique, Snyk Code SAST a reproduit son jeu de référence avec un score F1 de 100,0 % et un écart-type de 0,0 point de pourcentage. La meilleure configuration de modèle était Claude Opus 4.6 Medium, avec un score F1 de 75,4 % par rapport aux références de Snyk, un rappel de 68,0 % et une précision de 91,5 %.

Il ne faut pas lire ce tableau comme la preuve que « Snyk a démontré que Snyk est fiable à 100 % ». Il faut plutôt le comprendre ainsi : Snyk Code a produit un jeu de référence déterministe ; les modèles y ont partiellement concordé ; et les écarts mettent en évidence des compromis entre reproductibilité, coût et couverture qu’il est utile de mesurer.

Ce que ce benchmark révèle sur l’analyse de sécurité par LLM

Le jeu de référence provient de Snyk Code. Cette approche est transparente et reproductible, mais devient circulaire si on la considère comme une vérité universelle. Ce rapport ne prétend pas cela. Le benchmark mesure la concordance des modèles avec les résultats de Snyk Code et analyse les écarts pour étudier la reproductibilité et la complémentarité.

Le système de notation est indulgent. Il établit des correspondances par type de vulnérabilité, et non par fichier, ligne, gravité ou identité de la source et du point d’entrée. Un système plus strict réduirait probablement les scores de concordance des modèles et révélerait davantage d’erreurs liées aux flux en double.

Les exemples sont de petites applications JavaScript et Express. Ils sont utiles pour des mesures contrôlées, mais ne couvrent pas les grands monorepos, les applications TypeScript fortement dépendantes de frameworks, les architectures mult services ni les vulnérabilités liées à la logique métier. js-project-nightowl montre déjà que la structure d’une application influence le comportement des modèles.

L’analyse de récurrence utilise des signatures de résultats normalisées. Pour les graphiques des résultats non concordants par modèle, la signature correspond à tâche + type de vulnérabilité + fichier + ligne, avec un regroupement distinct pour chaque configuration de modèle. Les pourcentages exacts varient selon les choix de normalisation ; c’est pourquoi la signature figure dans les consignes de création des graphiques et les notes de reproductibilité.

À suivre : des exemples plus complets et des workflows combinant LLM et SAST

La prochaine version de Snyk VulnBench devrait dépasser les petits extraits autonomes. Nous prévoyons d’ajouter des structures d’applications plus complètes, des vulnérabilités issues de LLM, des cas de logique métier et des catégories BOLA, ainsi qu’une source indépendante de vérité terrain, comme les données de référence de type BaxBench.

Nous devrions également distinguer plusieurs volets de benchmark. L’un peut continuer à mesurer la concordance avec Snyk Code afin de comparer le comportement des modèles à une référence SAST déterministe. Un autre devrait s’appuyer sur une vérité terrain indépendante et vérifiable par des tiers, afin que les résultats principaux ne dépendent pas des propres détections de Snyk.

Enfin, les prochains rapports devraient évaluer des workflows combinés : analyse par modèle seul, analyse SAST seule et analyse par LLM enrichie du contexte SAST. Les données de JS 1.0 vont déjà dans ce sens. Les modèles et le SAST ne commettent pas les mêmes erreurs. C’est pourquoi il faut les combiner.