Une équipe de l'Université du Maryland remet en cause une partie des bons résultats obtenus par les agents d'IA chargés de corriger des vulnérabilités. Son nouveau benchmark, PatchBench, ne se contente pas de vérifier que l'entrée ayant provoqué un plantage ne déclenche plus le même incident. Il cherche à déterminer si la vulnérabilité a réellement été supprimée et si le programme continue à fonctionner correctement sur des entrées légitimes.
Le préprint, déposé sur arXiv le 3 septembre, évalue 11 agents sur des réparations de vulnérabilités en C et C++. Selon les auteurs, une validation limitée à une seule preuve de concept augmente le taux apparent de réussite d'un facteur moyen de 1,83. Les trois meilleurs agents dépassent 97 % sur cette vérification initiale, mais tombent à environ la moitié des tâches lorsque des contrôles de sécurité et de comportement sont ajoutés. Pour une équipe sécurité, cet écart est plus instructif que le classement lui-même : empêcher un plantage précis ne suffit pas à démontrer que la faille est corrigée.
PatchBench durcit la définition d'un correctif valide
Le benchmark réunit 213 tâches couvrant 16 catégories CWE et 32 projets réels. Sa construction vise deux raccourcis susceptibles de gonfler les performances des agents.
Le premier concerne la mémorisation. Les chercheurs transplantent des vulnérabilités historiques dans des versions plus récentes des dépôts et modifient le code autour de la zone corrigée. Ils cherchent ainsi à réduire la possibilité qu'un modèle reproduise simplement un correctif de développeur présent dans ses données d'entraînement. Dans une étude séparée sur SEC-bench, ils estiment qu'environ 25 % des correctifs produits par des agents travaillant à l'échelle du dépôt ressemblent fortement aux correctifs historiques. Les auteurs précisent qu'une telle similarité ne prouve pas à elle seule une contamination des données d'entraînement, mais elle fragilise la valeur d'une évaluation fondée sur des vulnérabilités publiques déjà connues.
Le second raccourci consiste à intervenir uniquement à l'endroit où le programme plante. PatchBench privilégie des cas dont le correctif historique se situe en dehors de la pile d'appels du plantage. Un agent doit donc remonter jusqu'à la cause du défaut au lieu d'ajouter une protection superficielle à l'endroit signalé par l'outil de diagnostic.
La validation se fait ensuite en plusieurs niveaux. Des entrées supplémentaires issues du fuzzing vérifient que la vulnérabilité n'est plus exploitable par d'autres chemins. Des entrées légitimes, des contrôles de régression, l'état de sortie du programme et les tests unitaires servent à vérifier que le correctif ne casse pas le comportement attendu.
Faire disparaître un plantage ne signifie pas réparer la faille
Le résultat le plus utile n'est pas la victoire d'un agent particulier, mais la chute des scores lorsque le critère d'acceptation devient plus proche d'une vraie exigence de sécurité.
D'après l'article, les trois meilleurs agents réussissent plus de 97 % des cas avec la seule preuve de concept initiale. Avec plusieurs entrées de sécurité, leur taux descend entre 75 % et 82 %. Lorsque la validation sémantique est ajoutée, les meilleurs résultats se situent autour de la moitié des tâches. Le benchmark contient aussi 67 cas qu'aucun des 11 agents testés ne résout.
L'exemple détaillé par les chercheurs montre pourquoi. Une erreur peut être introduite dans une partie du programme et ne provoquer un plantage que plus tard, dans un autre composant. Un agent peut ajouter une vérification au point de plantage et neutraliser l'entrée fournie sans corriger l'état invalide créé plus tôt. Le test initial passe alors au vert, alors que d'autres chemins d'exploitation ou des comportements erronés subsistent.
La validation doit rester indépendante de l'agent qui écrit le correctif
La principale conclusion d'Aipolix est opérationnelle : dans un processus de remédiation automatisé, la génération du correctif et son acceptation ne devraient pas être confiées à la même boucle.
L'agent peut proposer une modification, mais la mise en production devrait dépendre d'un contrôle indépendant répondant au moins à trois questions. Le correctif élimine-t-il d'autres chemins vers la même vulnérabilité que l'entrée initiale ? Préserve-t-il le comportement normal et les tests existants ? Corrige-t-il la cause du problème plutôt que son seul symptôme visible ?
Cette séparation déplace la frontière de confiance. Un système dans lequel l'agent produit un correctif, rejoue une seule preuve de concept puis s'auto-déclare victorieux reste fragile, même avec un modèle performant. Le fuzzing indépendant, les tests de régression et la comparaison du comportement doivent devenir des conditions d'acceptation.
PatchBench rappelle également qu'un benchmark construit à partir de vulnérabilités publiques peut mesurer à la fois le raisonnement et la restitution de motifs déjà vus. Transplanter les vulnérabilités et modifier leur contexte ne supprime pas toute possibilité de mémorisation, mais rend plus difficile la reproduction quasi directe d'un correctif historique.
Un résultat important avec une limite de reproductibilité
Il s'agit encore d'une première version déposée sur arXiv, sans réplication indépendante. Les expériences portent sur des vulnérabilités C et C++, ce qui ne permet pas de généraliser automatiquement les conclusions à tous les langages, à toutes les catégories de défauts ou aux dépôts d'entreprise.
Une incohérence de publication mérite aussi d'être signalée. L'article affirme que le code et le benchmark sont disponibles à l'adresse github.com/ai-sec-lab/PatchBench. Lors de la vérification d'Aipolix le 4 septembre, cette URL renvoyait une erreur 404 et le dépôt ne pouvait pas être inspecté. Cela n'annule pas les résultats rapportés dans le papier, mais empêche pour l'instant un praticien de reproduire le benchmark à partir de l'artefact annoncé.
La conclusion doit donc rester précise. PatchBench ne montre pas que les agents sont incapables de corriger des vulnérabilités. Il montre qu'une validation trop étroite peut donner une image très optimiste de la qualité réelle d'un correctif. Pour les équipes qui automatisent déjà la remédiation, la règle pratique est simple : un correctif produit par un agent reste une proposition tant qu'il n'a pas passé une validation de sécurité et de comportement indépendante.