Remediation Agent : pourquoi corriger vaut mieux que détecter

Six nouveaux problèmes de sécurité pour chaque problème corrigé. C’est le ratio observé par les équipes de recherche de Snyk. Voilà pourquoi la communauté AI Security Engineers a consacré une heure de diffusion en direct aux corrections plutôt qu’à la détection.

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

Remediation Agent démystifiés associait une discussion informelle à une démonstration en direct. Gérald Crescione, responsable de la communauté mondiale AI Security Engineers, animait l’échange avec Ryan McMorrow, qui dirige les produits de remédiation chez Snyk, et Brendan Hann, responsable senior du marketing produit pour l’expérience développeur et la solution Agentic AppSec 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 le développer et de l’améliorer au vu et au su de tous, Snyk propose Remediation Agent à tous ses clients actuels sans frais supplémentaires, en échange de commentaires concrets de la communauté. Vous pouvez les partager dans le subreddit de la communauté.

Pourquoi le taux de correction n’a pas évolué

Les agents de codage que les développeurs utilisent désormais partout optimisent le code fonctionnel, et non le code fonctionnel sécurisé. Le nombre de problèmes augmente donc, tandis que le taux de correction stagne. Les outils AppSec répondaient par des conseils déterministes : vous utilisez la version 1.0, la vulnérabilité est corrigée dans la version 1.1, alors mettez à niveau. C’est utile jusqu’à un certain point, mais quelqu’un doit encore vérifier que la mise à niveau n’a rien cassé, et aucun outil ne le faisait pour le compte du développeur. Quand il fallait passer trois ou quatre versions majeures, la plupart des équipes ne parvenaient jamais à obtenir la confiance nécessaire pour fusionner les changements.

Hann a replacé ce goulot d’étranglement dans un contexte plus large. L’IA a créé trois pressions distinctes, mais liées : les attaques sont désormais automatisées grâce à l’IA ; les agents écrivent des logiciels plus vite que jamais et introduisent des vulnérabilités au même rythme ; et l’IA arrive en production, souvent sans gouvernance. La remédiation a toujours été un goulot d’étranglement, a-t-il expliqué, mais elle compte davantage aujourd’hui, car les outils des attaquants ont eux aussi évolué. Les modèles de pointe s’échappent des environnements sandbox et enchaînent des problèmes de faible gravité, auparavant négligés, pour créer de nouvelles vulnérabilités zero-day. L’arriéré des risques acceptés est devenu une surface d’attaque à part entière.

Agentic AppSec couvre cet ensemble : contrôles préventifs, détection de niveau avancé et remédiation autonome. Pour reprendre les mots de Hann, il s’agit de fournir aux équipes une équipe d’agents capables de gérer réellement leur programme AppSec.

Pourquoi confier l’arriéré à un LLM ne suffit pas

Les équipes de recherche de Snyk ont commencé par l’évidence : confier l’arriéré de sécurité à un LLM et voir ce qui se passe.

Le modèle s’est révélé extrêmement enthousiaste, mais n’avait raison qu’occasionnellement. Les développeurs devaient toujours examiner chaque modification et en rejeter la plupart, ce qui leur prenait à peu près autant de temps que de corriger les problèmes à la main. Un modèle plus grand aurait produit davantage du même résultat.

Le déclic est venu quand l’équipe a posé une autre question : que se passerait-il si le LLM avait accès à tout ce que sait Snyk ? Dix ans de bonnes pratiques en sécurité des applications, de connaissances sur les mises à niveau propres à chaque écosystème et d’expérience durement acquise sur les corrections qui sont fusionnées et celles qui ne le sont pas.

C’est ainsi qu’est né Remediation Agent, que McMorrow décrit comme un harnais ou une couche d’orchestration entre le modèle choisi par le développeur et une couche d’intelligence interrogeable couvrant chaque problème et CVE suivis par Snyk. À la demande, l’agent peut récupérer :

• Les évaluations du risque de rupture pour les mises à niveau open source, qui indiquent la probabilité qu’une mise à niveau casse votre build, à partir d’une base de données recensant chaque version de paquet et chacune de ses modifications incompatibles

• L’état de santé des paquets et les scores d’accessibilité, notamment pour savoir si le code vulnérable est exploitable en production

• La génération de correctifs SAST grâce à la fonctionnalité Agent Fix de Snyk

• Des guides pratiques par écosystème rédigés par les propres ingénieurs en sécurité de Snyk, qui expliquent comment un praticien chevronné mettrait à niveau une dépendance transitive ou éliminerait une catégorie donnée de résultats SAST

McMorrow a comparé la situation à un examen à livre ouvert : le LLM passe l’examen et Snyk lui fournit le livre. Snyk corrige ensuite la copie de l’agent en relançant les analyses pour vérifier que le problème a bien disparu et en exécutant les tests unitaires du projet pour s’assurer que les modifications n’ont pas cassé le build.

Les résultats internes qu’il a présentés indiquaient une amélioration de 94 % des correctifs SCA prêts à être fusionnés et de 13 % des correctifs SAST prêts à être fusionnés. La majorité des correctifs SAST générés en interne sont désormais fusionnés tels quels, pour un coût en tokens nettement inférieur à celui de l’approche naïve.

Hann a ajouté les trois approches qui ont le mieux fonctionné chez les partenaires de conception de Snyk :

1. Des campagnes de résorption de l’arriéré pour éliminer les résultats de faible gravité et informatifs que les attaquants enchaînent désormais

2. Des déploiements à l’échelle de l’organisation, afin que chaque développeur bénéficie d’un agent de remédiation

3. L’utilisation de l’agent de remédiation dans les environnements de développement agentique (ADE) pour empêcher l’introduction de nouveaux problèmes dans le code

La démonstration : IDE et CLI

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

1. La voie de l’IDE

La voie de l’IDE nécessite deux éléments : une compétence /snyk-fix et le serveur MCP de Snyk Studio, tous deux installables à l’aide d’une seule commande curl depuis le dépôt de recettes de Snyk. Vous obtenez ainsi le processus complet dans Cursor, Windsurf, Antigravity ou VS Code avec un plug-in Claude : des analyses SAST et SCA à la demande de renseignements, en passant par les modifications du code, une nouvelle analyse, l’exécution des tests, le rapport et la demande de fusion. Sur scène, l’agent a mis à niveau une dépendance multer vulnérable en franchissant une version majeure, confirmé qu’aucune modification incompatible de l’API n’affectait l’utilisation du stockage sur disque de l’application, puis mis à jour le fichier de verrouillage.

2. La voie de la CLI

Dans la CLI, snyk fix --agentic --experimental --sca propose une approche plus interactive. La commande répertorie chaque paquet 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 risque de rupture. Les développeurs peuvent :

• Tout corriger

• Ne corriger que les éléments présentant un faible risque de rupture

• Sélectionner des résultats précis

• Discuter avec l’agent

McMorrow a illustré la dernière option en demandant pourquoi le passage à une version majeure de Glob était considéré comme risqué. L’agent a expliqué son raisonnement : passage à une API basée sur des promesses, style de rappel obsolète, séparateurs de chemin interprétés uniquement comme des caractères d’échappement et classe Glob qui n’est plus un émetteur d’événements. Il a aussi répertorié les vulnérabilités transitives que la mise à niveau éliminerait. La version la plus récente s’appuie ensuite sur ces mêmes renseignements concernant les risques de rupture pour effectuer les modifications de code compensatoires et transformer une mise à niveau à haut risque en une mise à niveau à faible risque.

Interrogé sur la provenance de ces explications, McMorrow a précisé que l’analyse des risques de rupture s’appuie sur l’étude des notes de version et des modifications incompatibles dans l’ensemble de l’écosystème open source. Les partenaires de conception ont signalé peu de faux positifs. Ceux-ci concernent surtout le volet SAST, où l’agent utilise les moteurs existants de Snyk Code pour les filtrer.

L’humain dans la boucle, puis aux commandes

Dans la démonstration, chaque processus aboutissait à une demande de fusion. « Nous ne faisons pas de modifications de code délirantes », a dit Hann. Le développeur garde le dernier mot jusqu’à ce que l’agent ait suffisamment gagné sa confiance pour qu’on puisse fusionner son travail sans hésiter.

Les propres équipes de Snyk utilisent aujourd’hui l’agent depuis la CLI, et une variante autonome est en cours de développement actif : Snyk lance un environnement sandbox, installe l’agent, récupère le code de l’application et renvoie une demande de fusion finalisé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 ; il génère maintenant les correctifs, que vous fusionnez avec votre propre commit. D’après McMorrow, les ingénieurs adorent ne plus avoir à revenir sur le sujet.

Hann a évoqué l’objectif réaliste d’un « arriéré nul », ainsi que le blocage des paquets malveillants et du slopsquatting au niveau du poste de développement et de l’organisation. McMorrow a expliqué que l’objectif à long terme est le contrôle, la gouvernance et la confiance : passer d’un humain dans la boucle à un humain aux commandes. La différence tient à la prise de décision : dans la boucle, on programme en binôme avec un agent ; aux commandes, un agent décide par lui-même et sait quand faire appel à vous. Crescione a ajouté que cela dessine le futur métier des AI Security Engineers : orchestrer une équipe d’agents en leur nom.

Passer à la pratique

Pour commencer, il vous faut un compte Snyk et la CLI ou un ADE pris en charge, ainsi que votre propre clé API de modèle. En effet, l’approche « apportez votre propre LLM » est celle retenue par défaut dans la préversion publique. Les responsables de projets open source peuvent accéder gratuitement à la plateforme complète grâce au Secure Developer Program, qui comprend une licence d’entreprise complète.

Vous avez trouvé un correctif qui ne convient pas ? Faites-le-nous savoir sur r/AISecEng. Vos commentaires contribueront à orienter la suite du développement de Remediation Agent, tandis que Snyk continue de le développer et de l’améliorer au vu et au su de tous.