L’IA peut générer un correctif qui bloque un exploit tout en se trompant dans la correction. Un nouveau benchmark publié le 1er août a révélé que certains correctifs de vulnérabilités générés par l’IA bloquaient les attaques visées, mais perturbaient le comportement légitime des logiciels, mettant sous surveillance la qualité de la validation — et pas seulement la génération des correctifs.
Ces résultats soulèvent un problème concret pour les entreprises qui évaluent des outils de sécurité basés sur l’IA. Les taux de correction peuvent sembler nettement meilleurs lorsque les tests s’arrêtent à l’exploit initial, tandis que des contrôles plus stricts peuvent révéler des régressions, des corrections erronées de la cause racine et des changements incompatibles avec le comportement attendu de l’application.
Un test d’exploit réussi peut masquer un mauvais correctif
Le benchmark Vul4Py évalue 100 vulnérabilités Python réelles issues de 60 projets open source et couvrant 60 catégories de la Common Weakness Enumeration. Chaque cas associe un test d’exploit aux tests fonctionnels du projet : le correctif doit donc bloquer l’attaque sans perturber le comportement attendu.
OpenHands a corrigé 41 vulnérabilités, contre quatre pour le grand modèle de langage le plus performant utilisé avec une instruction directe, et deux pour un outil de correction spécialisé. Les trois approches reposaient sur le même modèle Claude Sonnet 4, ce qui suggère que l’accès au dépôt, l’exécution des tests et les modifications itératives du code ont aidé le flux de travail agentique à surpasser les approches plus simples dans ce benchmark.
Les résultats de la validation étaient tout aussi significatifs. Sur les six approches testées, 119 correctifs ont bloqué les exploits visés, mais 15 ont échoué aux tests fonctionnels associés. Parmi les 104 correctifs ayant réussi les deux contrôles, 98 ont été jugés sémantiquement équivalents aux corrections des développeurs lors d’une revue manuelle.
Les plateformes de sécurité basées sur l’IA s’orientent déjà vers des flux de travail combinant détection et vérification. L’initiative de sécurité Daybreak d’OpenAI utilise des agents pour trouver les vulnérabilités, les valider dans des environnements isolés et proposer des corrections, plutôt que de s’arrêter à leur découverte.
Le volume des résultats augmente déjà. Le Patch Tuesday de juillet de Microsoft a corrigé un nombre record de 570 vulnérabilités, alors que l’entreprise étendait son recours à la détection des vulnérabilités assistée par l’IA, ce qui alourdit la charge de vérification et de remédiation incombant aux équipes de sécurité.
Des tests plus stricts changent la donne en matière d’achat
PVBench évalue les correctifs selon une norme plus exigeante. Le benchmark de validation à 209 cas ajoute des tests rédigés par les développeurs, qui couvrent des exigences allant au-delà du blocage de l’exploit et de la préservation des fonctionnalités existantes.
Plus de 40 % des correctifs acceptés par les tests de base d’exploitation et de régression ont échoué à ces contrôles supplémentaires. Les chercheurs ont principalement attribué ces problèmes à une analyse erronée de la cause racine, à des violations des spécifications et à l’incapacité de préserver l’intention des développeurs.
Cet écart fait de la méthodologie de validation un enjeu d’approvisionnement. Les fournisseurs devraient être capables d’expliquer si les correctifs générés sont uniquement testés contre un exploit de preuve de concept, exécutés dans des suites de régression, vérifiés au regard du comportement attendu de l’application et examinés avant leur déploiement.
Certains projets de sécurité basés sur l’IA conservent déjà cette intervention humaine. Le programme Patch the Planet d’OpenAI associe des modèles de sécurité basés sur l’IA à des ingénieurs qui reproduisent les résultats, examinent les corrections proposées et collaborent avec les mainteneurs avant la fusion des correctifs.
Un taux de correction élevé ne dit pas grand-chose sur l’aptitude à la production si des tests trop faibles laissent passer des corrections erronées. Les entreprises qui évaluent la remédiation automatisée ont besoin de preuves que le système peut préserver les fonctionnalités et corriger la faille sous-jacente — et pas simplement produire du code qui déjoue une attaque connue.
À lire aussi : le problème d’échelle est déjà visible ailleurs : le projet Mythos d’Anthropic a fait émerger des milliers de candidats au statut de vulnérabilité, tandis que le rythme de correction accusait un retard considérable sur celui de la découverte, ce qui montre pourquoi les capacités de vérification et de remédiation déterminent de plus en plus si les failles détectées par l’IA aboutissent réellement à des logiciels plus sûrs.