VulnBump : les agents IA peuvent-ils corriger les dépendances vulnérables sans casser le build ?

Les agents IA peuvent-ils corriger les dépendances vulnérables sans casser le build ? La correction en elle-même est rarement mystérieuse. Au cours des six premiers mois de 2026, Snyk Open Source a enregistré 459 millions de détections de vulnérabilités dans quelque 300 000 organisations. 94 % de ces vulnérabilités avaient une version corrigée connue, mais seulement environ 10 % avaient été corrigées.

C’est parce que la difficulté consiste à effectuer la mise à niveau en toute sécurité : la plupart des packages vulnérables sont importés de façon transitive, environ un quart des corrections nécessite une mise à niveau majeure et même les versions mineures et correctives, censées assurer la rétrocompatibilité, comportent souvent des changements cassants.

VulnBump, une nouvelle étude publiée par Snyk, met à l’épreuve des agents IA sur 307 mises à niveau réelles de dépendances vulnérables. Une mise à niveau est considérée comme RÉUSSIE uniquement si les vulnérabilités ont disparu et que le projet s’installe toujours, se compile et réussit ses tests.

Quoi de neuf : à notre connaissance, VulnBump est le premier benchmark pour agents IA consacré aux mises à niveau motivées par la sécurité : chaque tâche part de vulnérabilités réelles détectées par Snyk dans un vrai projet, sur six gestionnaires de packages. Les benchmarks précédents vérifient uniquement l’absence de régressions, pas la disparition des vulnérabilités.

Alors, les agents IA peuvent-ils corriger les dépendances vulnérables sans casser le build ? Dans la plupart des cas, oui, mais le modèle à lui seul ne fait pas la différence. Avec le même modèle, Claude Sonnet 5.5, l’Evo Remediation Agent de Snyk a réussi 90,2 % des mises à niveau. Claude Code d’Anthropic en a réussi 77,5 % lorsqu’il recevait la mise à niveau recommandée et le scan de Snyk (Claude Code + scan Snyk), et 59,6 % sans données Snyk (Claude Code sans assistance). L’écart dépasse 30 points de pourcentage. À titre de comparaison, la mise à niveau par le gestionnaire de packages, une référence sans IA qui applique uniquement la version recommandée par Snyk, a déjà réussi dans 46,9 % des cas.

Principaux résultats de VulnBump

Maintenir un build fonctionnel n’était pas le plus difficile : les trois agents y sont parvenus environ 93 % du temps. Le vrai défi était de supprimer la vulnérabilité. Dans 70 de ses 124 échecs, Claude Code, sans assistance, a affirmé avoir corrigé des vulnérabilités toujours détectées par un nouveau scan.

Nos résultats font écho à VulnBench, notre benchmark de juin sur l’analyse de sécurité par l’IA, qui a révélé que Claude et Snyk Code ne détectent pas les mêmes vulnérabilités et conclu que leur combinaison donne les meilleurs résultats. VulnBump porte sur une autre tâche — la mise à niveau de dépendances open source vulnérables — et va dans le même sens : avec la version recommandée et le scan de Snyk, le taux de réussite de Claude Code a augmenté de 17,9 points. L’Evo Remediation Agent montre jusqu’où peut aller un agent conçu spécialement pour cette tâche : 12,7 points de plus que Claude Code avec le même scan Snyk. VulnBump prolonge également les résultats de remédiation que nous avons publiés en mai, cette fois avec un modèle plus récent et six gestionnaires de packages.

Comment nous avons créé VulnBump

Nous sommes partis de projets réels représentatifs de la production. Nous avons recueilli 767 projets candidats sur GitHub, dont des projets open source populaires et des dépôts qui utilisent des packages dont les vulnérabilités sont connues. Avant tout changement, chacun devait s’installer et se compiler, et réussir plus de 85 % de ses tests. Snyk devait également y détecter au moins une vulnérabilité. Parmi les 99 projets admissibles, nous en avons sélectionné 43 représentatifs des données de production de Snyk en matière d’écosystème, de gravité des vulnérabilités, de dépendances directes vs transitives et d’ampleur du saut de version.

Comparaison du jeu de données VulnBump avec les données de production de Snyk Open Source

Nous avons transformé chaque mise à niveau recommandée en une tâche. Chaque tâche demande à l’agent d’appliquer une mise à niveau recommandée par Snyk : faire passer un package à une version qui corrige ses vulnérabilités. Chaque tâche part d’une copie vierge du projet et est évaluée séparément. Les 43 dépôts fournissent 307 tâches couvrant 2 066 vulnérabilités corrigibles, sur Maven, Gradle, npm, Yarn, pip et Poetry, les six gestionnaires de packages à l’origine d’environ 92 % des détections en production.

Nous avons ajouté un vérificateur qui ne faisait pas confiance à l’agent. Une fois le travail de l’agent terminé, nous avons copié ses changements dans un conteneur vierge et les avons vérifiés depuis le début. La tentative n’était considérée comme RÉUSSIE que si elle franchissait les quatre contrôles suivants :

1. Les dépendances s’installent à l’aide de la commande que la CI exécuterait.

2. Un nouveau scan Snyk confirme la disparition des vulnérabilités.

3. Le projet se compile.

4. Tous les tests qui réussissaient avant continuent de réussir.

Le pipeline VulnBump

Les environnements d’exécution testés. Les trois agents ont utilisé Claude Sonnet 5.5, avec une limite de 110 tours par mise à niveau, dans le même conteneur pour chaque langage de programmation :

• Evo Remediation Agent est le moteur de remédiation agentique de Snyk. Il exploite les informations de Snyk et peut effectuer ses propres scans, builds et tests, puis corriger les erreurs avant de terminer. Nous l’avons exécuté en mode d’approbation automatique : il a donc appliqué chaque correction, y compris les mises à niveau que Snyk juge susceptibles de casser le build.

• Claude Code avec scan Snyk est l’agent de programmation généraliste d’Anthropic, auquel nous avons fourni la recommandation de mise à niveau de Snyk : le package à mettre à niveau, la version cible et les vulnérabilités corrigées. Il peut également exécuter lui-même un scan Snyk Open Source pour vérifier son travail.

• Claude Code sans assistance reçoit la même tâche, mais sans version cible ni accès à Snyk. Il doit déterminer seul quelle version corrige les vulnérabilités, par exemple en consultant des bases de données de vulnérabilités sur le Web.

• La mise à niveau par le gestionnaire de packages est la référence non agentique : elle applique la version recommandée par Snyk avec le gestionnaire de packages du projet et ne change rien d’autre.

Le choix des dépôts, les prompts exacts et les outils dont disposait chaque agent, ainsi que les mesures de contrôle des fuites de données, sont détaillés dans l’article de recherche : VulnBump: A Benchmark for Fixing Vulnerable Dependencies in Real Projects While Keeping the Build and Tests Green, avec les limites de l’étude : nous avons testé un seul modèle, exécuté chaque mise à niveau une seule fois et utilisé Snyk Open Source comme arbitre, ce qui ne peut désavantager que Claude Code sans assistance, puisque les deux autres agents s’appuient sur les mêmes détections Snyk. Nous n’avons pas non plus pénalisé les nouvelles vulnérabilités introduites par une mise à niveau.

Résultat 1 : un même modèle, trois résultats différents

Evo Remediation Agent a franchi tous les contrôles dans 90,2 % des mises à niveau (et corrigé 95,9 % des 2 066 cas de vulnérabilité). C’est 12,7 points de plus que Claude Code + scan Snyk — soit environ une correction fonctionnelle de plus toutes les huit mises à niveau — et 30,6 points de plus que Claude Code sans assistance.

Et le classement ne dépend pas seulement de quelques grands dépôts : en calculant la moyenne par dépôt, les taux de réussite étaient de 93,1 % pour Evo Remediation Agent, de 80,1 % pour Claude Code + scan Snyk, de 68,0 % pour Claude Code sans assistance et de 51,3 % pour la mise à niveau par le gestionnaire de packages.

Résultat 2 : les agents doivent connaître la version réellement sûre

Avec le même modèle, fournir à Claude Code le scan Snyk et la mise à niveau recommandée a augmenté son taux de réussite de 17,9 points, le faisant passer de 59,6 % à 77,5 %.

La différence la plus nette concerne la version choisie. Sans assistance, Claude Code a choisi une version que Snyk signale encore dans 64 cas. Avec le scan Snyk, ce nombre est tombé à 13. Les bases de données de vulnérabilités ne s’accordent pas toujours sur la version qui corrige une vulnérabilité : une version considérée comme sûre par une source peut encore être signalée par une autre. 

Les recommandations de Snyk sont particulièrement importantes pour les vulnérabilités transitives, qui touchent des packages que le projet ne déclare pas directement. En ne comptant que les mises à niveau ayant franchi tous les contrôles, la part des vulnérabilités corrigées par Claude Code a plus que doublé, passant de 28 % à 59 %.

Résultat 3 : les recommandations de Snyk suffisent à elles seules dans environ la moitié des cas ; les agents se départagent sur le reste

La mise à niveau par le gestionnaire de packages répartit les 307 mises à niveau en deux groupes : pour les 144 qui réussissent, la version recommandée par Snyk suffit, et un agent ne peut que conserver ou gâcher une correction facile. Les 163 autres nécessitent davantage qu’un simple changement de version, par exemple adapter le code à des changements cassants ou résoudre des conflits de dépendances.

Résultats des agents pour les 144 mises à niveau résolues par les recommandations de Snyk et pour les 163 autres

Avec les recommandations de Snyk, les agents compromettent rarement les corrections obtenues par la simple mise à niveau, tandis que Claude Code sans assistance a régressé dans 20 des 144 cas, en choisissant dans 15 d’entre eux une version toujours signalée par Snyk. La véritable différence apparaît sur la moitié la plus difficile : parmi les 163 autres mises à niveau, Evo Remediation Agent a réussi dans 82,2 % des cas, Claude Code + scan Snyk dans 61,3 % et Claude Code seul dans 36,2 %.

Résultat 4 : un build fonctionnel peut masquer une vulnérabilité non corrigée

Le moyen le plus simple de maintenir un build fonctionnel est de laisser la vulnérabilité en place, et c’est principalement ainsi que Claude Code a échoué. Le nouveau scan était le premier contrôle en échec dans 107 des 124 échecs de Claude Code sans assistance, 48 des 69 échecs de Claude Code + scan Snyk, contre 9 des 30 échecs d’Evo Remediation Agent.

Premier contrôle de vérification en échec pour chaque tentative échouée

Les échecs d’Evo Remediation Agent sont visibles (et ce n’est pas une mauvaise chose). 21 de ses 30 échecs ont cassé le build ou les tests, principalement lors de mises à niveau majeures que les autres agents évitaient souvent. Un échec manifeste est bien plus sûr qu’un échec silencieux : lorsqu’une mise à niveau tourne mal, le build et les tests du projet le révèlent, de façon visible pour les développeurs, qui peuvent alors agir.

Résultat 5 : connaître la version cible ne suffit pas

Le scan de Snyk permet à Claude Code d’aller loin, mais réussir la mise à niveau demande davantage : avec les mêmes détections et les mêmes versions cibles, Evo Remediation Agent a réussi 39 mises à niveau de plus que Claude Code avec scan Snyk, dont 23 impliquaient des changements de version majeurs.

Evo Remediation Agent associe les informations de Snyk à une boucle qui compile, teste et corrige le projet avant de terminer. Notre configuration ne permet pas d’isoler le composant qui fait la différence, mais elle montre à quel point le système autour d’un modèle peut influer sur le résultat, ce qui concorde avec DepBench, où la modification du seul environnement d’exécution a fait varier les résultats de 16,3 points au maximum.

Résultat 6 : les changements de version majeurs et les dépendances transitives restent les tâches les plus difficiles

Tous les agents peinent encore avec les migrations majeures de frameworks : 23 mises à niveau, principalement des migrations de Spring, Spring Boot et Dropwizard, ont mis en échec les trois agents. 

Pour les mises à niveau majeures vs non majeures, les taux de réussite sont passés respectivement de 96 % à 81 % pour Evo Remediation Agent, de 88 % à 61 % pour Claude Code + scan Snyk, et de 70 % à 42 % pour Claude Code sans assistance. Les mises à niveau majeures sont aussi celles qui exigent des changements de code : environ la moitié des mises à niveau majeures réussies par Evo Remediation Agent ont modifié le code source de l’application, contre 5 % des mises à niveau non majeures réussies.

Mises à niveau ayant franchi tous les contrôles, selon l’ampleur du saut de version

Les vulnérabilités transitives, où le package vulnérable n’est pas déclaré dans le manifeste, représentent 70 % des cas corrigibles et sont plus difficiles à traiter pour tous les environnements d’exécution testés. En ne comptant que les corrections issues de tentatives ayant franchi tous les contrôles, Evo Remediation Agent a corrigé 73 % des cas transitifs, Claude Code + scan Snyk 59 % et Claude Code sans assistance 28 % ; pour les cas directs, les taux respectifs étaient de 91 %, 71 % et 62 %.

Taux de réussite selon le type de dépendance (directe vs transitive)

Quel est le lien entre VulnBump et VulnBench ?

VulnBench évalue la capacité des agents de programmation IA à détecter les vulnérabilités dans le code que vous écrivez : leur régularité dans la détection des mêmes problèmes lors d’exécutions répétées et la concordance de leurs résultats avec une référence SAST déterministe. VulnBump évalue leur capacité à corriger les vulnérabilités dans le code dont vous dépendez : mettre à niveau les dépendances open source vulnérables sans casser le build ni les tests.

Pris ensemble, les deux benchmarks vont dans le même sens : les modèles apportent un raisonnement dont les outils déterministes sont dépourvus. Utilisés seuls, ils signalent des problèmes différents d’une exécution à l’autre et s’arrêtent souvent avant d’apporter une correction. À l’échelle de la plateforme, nous résumons simplement cette leçon commune : le générateur ne peut pas être le validateur.

Qu’est-ce que cela signifie pour les équipes qui confient des tâches de sécurité à des agents ?

• Évaluez une correction à partir d’éléments que l’agent n’a pas produits : le compte rendu d’un agent sur sa propre correction est une affirmation, tandis qu’un nouveau scan, un build et une exécution des tests constituent des preuves. Si un agent traite votre backlog, soumettez-le aux mêmes vérifications.

• Évaluez ensemble la vulnérabilité et le build : chacun, pris séparément, peut masquer un échec. Les vérifications qui ne portent que sur les régressions ignorent les corrections qui n’ont jamais été apportées, tandis que celles qui ne vérifient que les vulnérabilités ne détectent pas les corrections qui ont cassé le projet.

• Fournissez les données de sécurité à l’agent : l’analyse de Snyk et la mise à niveau recommandée ont permis à un agent généraliste d’obtenir 17,9 points de plus, avec le même modèle.

Evo Remediation Agent est le moteur de remédiation agentique de Snyk, disponible via la CLI Snyk et en tant que service cloud. C’est l’un des agents d’Evo Agentic AppSec, lancé aujourd’hui.

Testez votre agent avec VulnBump

Le banc de test VulnBump et les 43 cas d’évaluation sont disponibles en open source sur github.com/snyk-labs/snyk-vulnbump.

La méthodologie complète, l’analyse des échecs et les limites sont détaillées dans l’article de recherche. Si vous développez vous-même un agent de remédiation, testez-le avec VulnBump et dites-nous ce que vous en pensez.

VulnBump a été conçu par Gabija Pasiunaite, Ryan McMorrow, Brian Clark, Liran Tal et Luke Tu.