Les agents de remédiation démystifiés : pourquoi corriger vaut mieux que détecter

Six nouveaux problèmes de sécurité pour chaque problème corrigé. C’est le ratio constaté par les recherches de Snyk, et c’est pourquoi la communauté AI Security Engineers a consacré une heure de livestream à la correction plutôt qu’à la détection.

Play Video: Remediation Agents Demystified: Your AI Teammate for Fixing Security Bugs

La démystification des agents de correction associait une discussion au coin du feu à une démonstration en direct. Gérald Crescione, responsable de la communauté mondiale AI Security Engineers, animait la session avec Ryan McMorrow, qui dirige les produits de correction chez Snyk, et Brendan Hann, responsable senior du marketing produit pour l’expérience développeur et la solution AppSec agentique de Snyk.

Remediation Agent, désormais disponible en préversion publique, est la réponse de Snyk au volume de problèmes que nous constatons. Alors que l'équipe continue de concevoir et d'améliorer le produit au vu de tous, Snyk propose Remediation Agent à tous ses clients actuels sans coût supplémentaire, en échange de retours exploitables de la communauté. Ces retours peuvent être partagés sur le subreddit de la communauté.

Pourquoi le taux de correction est resté stable

Les agents de codage que les développeurs utilisent désormais partout optimisent le code fonctionnel, et non le code fonctionnel sécurisé. Le volume de problèmes augmente donc tandis que le taux de correction reste stable. Les outils AppSec répondaient à cela par des recommandations déterministes : vous êtes en version 1.0, la vulnérabilité est corrigée en version 1.1, mettez donc à niveau. C'est valable jusqu'à un certain point, sauf que quelqu'un doit encore prouver que la mise à niveau n'a rien cassé, et aucun outil ne le faisait à la place du développeur. Lorsque le saut couvrait trois ou quatre versions majeures, la plupart des équipes ne trouvaient jamais la confiance nécessaire pour fusionner le changement.

Hann a replacé ce goulet d'étranglement dans le contexte d'une évolution plus large. L'IA a créé trois pressions distinctes mais liées : les attaques sont désormais automatisées par l'IA ; les agents écrivent des logiciels plus rapidement que jamais et introduisent des vulnérabilités au même rythme ; et l'IA arrive en production, souvent sans gouvernance. Selon lui, la correction a toujours été un goulet d'étranglement, mais elle est désormais plus importante, car les outils des attaquants ont eux aussi changé de forme. Les modèles de pointe sortent des bacs à sable et enchaînent des vulnérabilités de faible gravité auparavant négligeables pour créer de nouveaux zero-days. L'arriéré des risques acceptés est devenu une surface d'attaque à part entière.

Agentic AppSec couvre cette combinaison : contrôles préventifs, détection de niveau avancé et correction autonome ; pour reprendre les mots de Hann, il s'agit de fournir aux équipes une équipe d'agents capable d'exécuter réellement leur programme AppSec à leur place.

Pourquoi lancer un LLM sur l'arriéré ne fonctionne pas

Les chercheurs de Snyk ont commencé par l'évidence : diriger un LLM vers l'arriéré de sécurité et voir ce qui se passe.

Le modèle s'est révélé extrêmement enthousiaste et seulement occasionnellement pertinent. Les développeurs devaient toujours examiner chaque modification et en rejeter la plupart, ce qui demandait à peu près autant de temps que de corriger les problèmes manuellement. Un modèle plus grand aurait produit davantage de résultats similaires.

Le tournant est survenu lorsque l'équipe a posé une question différente : et si le LLM disposait de tout ce que Snyk sait ? Dix ans de bonnes pratiques en sécurité des applications, des connaissances sur les mises à niveau propres à chaque écosystème et une expérience durement acquise des corrections qui sont fusionnées ou non.

C'est ainsi qu'est né Remediation Agent, décrit par McMorrow comme un harnais ou une couche d'orchestration située entre le modèle choisi par le développeur et une couche d'intelligence appelable couvrant tous les problèmes et CVE suivis par Snyk. À la demande, l'agent peut récupérer :

• Évaluations de la risque de casse pour les mises à niveau open source, avec une note indiquant la probabilité qu'une mise à niveau casse votre build, à partir d'une base de données contenant chaque version de package et chaque changement cassant qui lui est associé

• État des packages et scores d'atteignabilité, notamment pour déterminer si le code vulnérable est exploitable en production

• Génération de corrections SAST via la fonctionnalité Agent Fix de Snyk

• Guides pratiques par écosystème rédigés par les propres ingénieurs sécurité de Snyk, expliquant comment un praticien senior mettrait à niveau une dépendance transitive ou traiterait une catégorie donnée de résultats SAST

L'analogie de McMorrow était la suivante : on donne au LLM un examen à livre ouvert, et Snyk lui fournit le livre. Snyk évalue ensuite les devoirs de l'agent, relance les analyses pour confirmer que le problème a réellement disparu et exécute les tests unitaires du projet afin de vérifier que les modifications n'ont pas cassé le build.

Les résultats internes qu'il a partagés faisaient état d'une amélioration de 94 % des corrections SCA fusionnables et de 13 % des corrections SAST fusionnables. La majorité des corrections SAST générées en interne sont désormais fusionnées telles quelles, pour un coût en tokens nettement inférieur à celui de l'approche naïve.

Hann a ajouté les trois méthodes avec lesquelles les partenaires de conception de Snyk ont obtenu le plus de succès :

1. Campagnes de réduction de l'arriéré, en éliminant les résultats de faible gravité et les résultats informatifs que les attaquants enchaînent désormais

2. Déploiements à l'échelle de l'organisation, en fournissant à chaque développeur un agent de correction à ses côtés

3. Utilisation de l'agent de correction dans les environnements de développement agentiques (ADE) afin d'empêcher l'introduction de nouveaux problèmes dans la base de code

La démonstration : IDE et CLI

McMorrow a exécuté l'agent en direct sur OWASP Juice Shop et présenté les deux points d'entrée.

1. La voie IDE

La voie IDE nécessite deux éléments : une compétence /snyk-fix et le serveur MCP Snyk Studio, tous deux installables avec une seule commande curl depuis le dépôt de recettes de Snyk. Cela offre la boucle complète dans Cursor, Windsurf, Antigravity ou VS Code avec un plug-in Claude, des analyses SAST et SCA jusqu'à la recherche d'informations, aux modifications du code, à la nouvelle analyse, à l'exécution des tests, au rapport et à la pull request. Sur scène, l'agent a mis à niveau une dépendance vulnérable multer sur une version majeure, confirmé qu'aucune modification d'API cassante n'affectait l'utilisation du stockage sur disque par l'application et mis à jour le fichier de verrouillage.

2. La voie CLI

Dans la CLI, snyk fix --agentic --experimental --sca est plus participatif. Il répertorie chaque package qu'il pense pouvoir mettre à niveau, avec la version actuelle, la version cible recommandée par Snyk parce qu'elle élimine le plus de problèmes critiques et élevés, ainsi qu'un score de risque de casse. Les développeurs peuvent :

• Tout corriger

• Corriger uniquement les éléments présentant un faible risque de casse

• Sélectionner des résultats spécifiques

• Dialoguer avec l'agent

McMorrow a illustré cette dernière option en demandant pourquoi un saut de version majeure Glob était considéré comme présentant un risque élevé. L'agent a fourni son raisonnement : passage à une API basée sur les promesses, style de rappel obsolète, séparateurs de chemin devenant des caractères réservés aux séquences d'échappement, et classe Glob qui n'est plus un émetteur d'événements. Il a également répertorié les vulnérabilités transitives que la mise à niveau corrigerait. La dernière version utilise ensuite cette même intelligence sur le risque de casse pour effectuer les modifications de code compensatoires, transformant une mise à niveau à haut risque en une mise à niveau à faible risque.

Interrogé sur l'origine de cette justification, McMorrow a expliqué que le raisonnement relatif au risque de casse provenait de l'analyse des notes de version et des changements cassants dans l'ensemble de l'écosystème open source. Les partenaires de conception ont signalé peu de faux positifs. Ils concernent principalement SAST, et l'agent utilise les moteurs existants de Snyk Code pour les filtrer.

L'humain dans la boucle, puis l'humain au-dessus de la boucle

Chaque voie de la démonstration aboutissait à une pull request. « Nous ne faisons pas de modifications de code insensées », a déclaré Hann, et le développeur conserve la validation finale jusqu'à ce qu'un agent ait gagné suffisamment de confiance pour que quelqu'un fusionne son travail sans vérification.

Les propres équipes de Snyk exécutent aujourd'hui l'agent depuis la CLI, et une variante autonome est en cours de développement actif : Snyk crée un bac à sable, installe l'agent, récupère le code de l'application et renvoie une pull request terminée. Auparavant, le pipeline CI de Snyk s'arrêtait en cas de nouvelles vulnérabilités et renvoyait le problème au développeur ; désormais, il génère les corrections à la place, et vous fusionnez le travail de l'agent avec votre propre commit. Selon McMorrow, les ingénieurs apprécient de ne pas avoir à y revenir.

Hann a présenté « backlog zéro » comme un objectif réaliste, ainsi que le blocage des packages malveillants et du slopsquatting au niveau de la machine du développeur et de l’organisation. McMorrow a estimé que l’objectif à long terme était le contrôle, la gouvernance et la confiance : passer d’un humain dans la boucle à un humain en supervision. La distinction tient à la personne qui décide : dans la boucle, il s’agit de programmer en binôme avec un agent ; en supervision, l’agent décide de lui-même et sait quand vous solliciter. Crescione a ajouté que c’était le profil de poste qui se dessine : des professionnels AI Security Engineers orchestrant une multitude d’agents pour leur compte.

Passer à la pratique

Pour commencer, il vous faut un compte Snyk et soit la CLI, soit un ADE pris en charge, ainsi que votre propre clé API de modèle, puisque le principe « apportez votre propre LLM » est la configuration par défaut de la préversion ouverte. Les mainteneurs open source peuvent bénéficier gratuitement de l'ensemble de la plateforme via le Secure Developer Program, qui inclut une licence entreprise complète.

Vous avez trouvé une correction qui tombe à côté ? Dites-le-nous sur r/AISecEng. Vos retours contribueront à orienter l'évolution de Remediation Agent, tandis que Snyk continue de le concevoir et de l'améliorer au vu de tous.