Legit Security : son agent IA corrige les dépendances

Legit Security : son agent IA corrige les dépendances

Legit Security a étendu sa fonctionnalité Agentic Remediation : elle prend désormais en charge les vulnérabilités des dépendances open source, et plus seulement celles du code qu'une entreprise écrit elle-même. L'objectif est de faire passer les équipes de développement de la détection d'une vulnérabilité à un correctif vérifié, sans que personne n'ait à trier le problème à la main.

Jusqu'ici, l'agent traitait les résultats d'analyse statique sur le code propriétaire, c'est-à-dire le code écrit par les ingénieurs de l'entreprise. La nouvelle version applique le même agent aux paquets importés de l'extérieur, que l'éditeur présente comme l'autre grande source de vulnérabilités dans les logiciels modernes.

Un problème de volume

Legit Security présente cette mise à jour comme une réponse à un fossé qui se creuse dans la sécurité applicative (AppSec). Le code généré par l'IA accélère la livraison des logiciels, et la plupart des bases de code modernes sont aujourd'hui constituées en grande partie de dépendances open source. Chaque nouveau paquet peut apporter son lot de vulnérabilités connues.

Le processus AppSec classique, où des équipes humaines épluchent un à un les résultats en attente, peine à suivre ce volume. La tâche se complique encore lorsque le code défaillant ne se trouve pas dans le dépôt de l'entreprise, mais enfoui plusieurs niveaux plus bas dans un paquet tiers.

"Le vrai défi n'est plus de trouver les vulnérabilités - c'est de passer de la détection au correctif assez vite", a déclaré l'entreprise. Elle ajoute que le code généré par l'IA a démultiplié la quantité de logiciels livrés chaque jour, tandis que les attaquants s'appuient de plus en plus sur l'IA pour trouver et exploiter les failles plus vite que les défenseurs ne peuvent réagir. Cette inquiétude rejoint une tendance plus large, celle de l'IA qui accélère l'exploitation des failles, que suivent de près les équipes de sécurité.

Cinq étapes jusqu'à la pull request

Lorsqu'on lui confie une dépendance vulnérable, l'agent suit une séquence fixe :

  • Identifier le paquet concerné, sa version actuelle, et déterminer s'il s'agit d'une dépendance directe ou transitive, c'est-à-dire importée par un autre paquet.
  • Choisir la mise à niveau la plus sûre, soit le plus petit saut de version qui règle le problème. Dans la mesure du possible, l'agent reste dans la version majeure actuelle pour éviter les changements incompatibles.
  • Appliquer le correctif en mettant à jour la configuration des dépendances et en régénérant le fichier de verrouillage. Cela couvre aussi les autres occurrences de la version vulnérable ailleurs dans l'arbre des dépendances.
  • Vérifier le résultat en analysant la dépendance avant et après la modification. Ce contrôle confirme que la faille a disparu et qu'aucun nouveau problème n'est apparu.
  • Ouvrir une pull request prête à être relue, avec le correctif et le détail de la vulnérabilité.

Comme chaque correctif est de nouveau analysé avant la création de la PR, les développeurs reçoivent une modification déjà contrôlée, et non une simple suggestion de version qu'ils devraient encore tester eux-mêmes.

Quand un changement de version majeure s'impose

Certains correctifs n'existent que dans une version majeure plus récente, où les changements d'API incompatibles deviennent un risque réel. Dans ces cas-là, l'agent ajoute une étape d'analyse assistée par l'IA. Il examine la façon dont le dépôt concerné utilise le paquet et propose les modifications du code source nécessaires pour s'adapter. Ces propositions sont validées à partir des données réelles du dépôt et du paquet.

Legit Security trace une frontière nette entre les deux volets d'un tel correctif. La mise à niveau de la dépendance elle-même est vérifiée par une nouvelle analyse, comme pour toute autre correction. L'adaptation du code liée au changement de version majeure, en revanche, est évaluée par l'IA et ne fait pas l'objet d'une vérification indépendante. Selon l'entreprise, la PR le mentionne explicitement, afin que les développeurs voient ce qui a été confirmé et ce qui mérite un examen plus attentif avant la fusion.

Notre analyse

Cette annonce s'inscrit dans une tendance observée dans tout le secteur ces dernières semaines : les éditeurs font passer l'IA du repérage des problèmes à leur correction effective. Gemini 4 Argon de Google, qui trouve et corrige des failles, et Sophos, qui utilise l'IA pour prioriser les correctifs, vont dans le même sens.

Pour nos lecteurs, le détail le plus intéressant est l'aveu de Legit Security lui-même : les adaptations de code rédigées par l'IA ne sont pas vérifiées de manière indépendante. Cela laisse penser que la relecture humaine n'est pas près de disparaître, surtout pour les mises à niveau majeures. Le risque lié aux dépendances dépasse d'ailleurs la simple question des versions obsolètes, comme le montrent des incidents tels que la compromission de l'Artifactory d'OpenInfra Europe. Reste à voir si les équipes feront suffisamment confiance à ces PR automatisées pour les fusionner rapidement, et à quelle fréquence les modifications évaluées par l'IA tiendront la route en production.