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 l'AI Security Engineers Community 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

Remediation Agents Demystified a associé une conversation au coin du feu à une démonstration en direct. Gérald Crescione, responsable de la communauté mondiale AI Security Engineers, animait l'événement, avec Ryan McMorrow, qui dirige les produits de correction chez Snyk, et Brendan Hann, responsable principal du marketing produit pour l'expérience développeur et la solution Agentic AppSec de Snyk.

Remediation Agent, actuellement disponible en préversion publique, est la réponse de Snyk au problème du volume de problèmes que nous constatons. Alors que l'équipe continue de développer et d'itérer au grand jour, Snyk propose Remediation Agent à tous ses clients actuels sans frais supplémentaires, 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, effectuez donc la mise à niveau. C'est valable jusqu'à un certain point, sauf qu'il faut toujours que quelqu'un prouve que la mise à niveau n'a rien cassé, et aucun outil ne le faisait à la place du développeur. Lorsque l'écart couvrait trois ou quatre versions majeures, la plupart des équipes ne trouvaient jamais la confiance nécessaire pour fusionner la modification.

Hann a replacé ce goulot 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 atteint la production, souvent sans gouvernance. La correction a toujours été un goulot d'étranglement, a-t-il expliqué, 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 problèmes de faible gravité jusque-là négligeables pour créer de nouveaux zero-days. Le retard 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 frontier 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 le backlog ne fonctionne pas

Les chercheurs de Snyk ont commencé par l'approche évidente : lancer un LLM sur le backlog de sécurité et observer le résultat.

Le modèle s'est révélé extrêmement enthousiaste et n'avait raison qu'occasionnellement. 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 du même résultat.

Le tournant est arrivé lorsque l'équipe a posé une question différente : que se passerait-il si le LLM recevait tout ce que Snyk sait ? Dix ans de bonnes pratiques en sécurité des applications, des connaissances spécifiques aux écosystèmes en matière de mises à niveau, et une expérience durement acquise sur les corrections qui sont fusionnées et celles qui ne le sont pas.

Cela a donné naissance à 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 interrogeable couvrant chaque problème et chaque CVE suivis par Snyk. À la demande, l'agent peut récupérer :

• Évaluations de cassabilité pour les mises à niveau open source, avec une évaluation de la probabilité qu'une mise à niveau casse votre build, à partir d'une base de données de chaque version de package et de chaque modification rétro-incompatible qu'elle contient

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

• Génération de corrections SAST grâce à 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 problèmes SAST

L'analogie de McMorrow était que le LLM passe un examen avec documentation, et que Snyk fournit le livre. Snyk évalue ensuite le travail 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 indiquaient 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 cas d'utilisation avec lesquels les partenaires de conception de Snyk ont obtenu le plus de succès :

1. Campagnes de réduction du backlog, en éliminant les problèmes de faible gravité et les problèmes 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) pour 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. Le parcours IDE

Le parcours IDE nécessite deux éléments : un /snyk-fix skill et le serveur MCP Snyk Studio, tous deux installables avec une seule commande curl depuis le dépôt de recettes de Snyk. Vous disposez ainsi de la boucle complète dans Cursor, Windsurf, Antigravity ou VS Code avec un plugin Claude, depuis les analyses SAST et SCA jusqu'à la consultation des 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 rétro-incompatible n'affectait l'utilisation du stockage sur disque par l'application, et mis à jour le fichier de verrouillage.

2. Le parcours CLI

Dans la CLI, snyk fix --agentic --experimental --sca est plus participatif. Elle répertorie chaque package qu'elle 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 cassabilité. Les développeurs peuvent :

• Tout corriger

• Corriger uniquement les éléments à faible risque de casse

• Sélectionner des problèmes spécifiques

• Dialoguer avec l'agent

McMorrow a démontré cette dernière option en demandant pourquoi un saut de version majeure de 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 callback obsolète, séparateurs de chemin devenant des caractères exclusivement d'échappement, et la classe Glob n'étant plus un émetteur d'événements. Il a également répertorié les vulnérabilités transitives que la mise à niveau corrigerait. La version la plus récente utilise ensuite cette même intelligence de cassabilité pour effectuer les modifications de code compensatoires, transformant une mise à niveau à haut risque en mise à niveau à faible risque.

Interrogé sur l'origine de la justification, McMorrow a expliqué que le raisonnement sur la cassabilité provenait de l'analyse des notes de version et des modifications rétro-incompatibles dans l'écosystème open source. Les partenaires de conception ont signalé peu de faux positifs. Ceux-ci 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 parcours de la démonstration se terminait par une pull request. « Nous ne faisons pas de modifications de code complètement folles », comme l'a dit Hann, et le développeur conserve la validation finale jusqu'à ce qu'un agent ait gagné suffisamment de confiance pour que quiconque fusionne son travail les yeux fermés.

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, y importe le code de l'application et renvoie une PR terminée. Le pipeline CI de Snyk s'arrêtait auparavant en cas de nouvelles vulnérabilités et renvoyait le problème au développeur ; désormais, il génère directement les corrections, et vous fusionnez le travail de l'agent avec votre propre commit. Les ingénieurs, a rapporté McMorrow, apprécient de ne pas avoir à y revenir.

Hann a évoqué le « backlog zéro » comme 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 expliqué que l'objectif à long terme était le contrôle, la gouvernance et la confiance : passer de l'humain dans la boucle à l'humain au-dessus de la boucle. La distinction porte sur la personne qui décide : dans la boucle, il s'agit de programmer en binôme avec un agent ; au-dessus de la boucle, il s'agit d'un agent qui décide seul et sait quand vous solliciter. Crescione a ajouté que c'était la description émergente du poste : des AI Security Engineers orchestrant une multitude d'agents à leur place.

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 bring-your-own-LLM est la configuration par défaut de la préversion ouverte. Les responsables de projets open source peuvent obtenir gratuitement l'ensemble de la plateforme grâce au Secure Developer Program, qui inclut une licence enterprise complète.

Vous avez trouvé une correction qui ne convient pas ? Dites-le-nous sur r/AISecEng. Vos retours contribueront à orienter l'évolution de Remediation Agent, tandis que Snyk continue de développer et d'itérer au grand jour.