En bref
- Trail of Bits publie deux modules qui séparent la fabrication d’un correctif de la recherche des défauts qu’il pourrait introduire.
- Son examen de plus de 130 contributions intégrées a confirmé 21 régressions, mais aucune n’a neutralisé une protection de sécurité.
- Lors d’une évaluation préliminaire, regression-hunt a produit 25 % de faux positifs en moins qu’un agent Codex recevant une consigne générale.
- Cette baisse du bruit a une contrepartie, puisque certaines régressions connues sont restées au stade de cas limites faute de preuves suffisantes.
Deux outils pour surveiller les effets secondaires
Trail of Bits publie patching-bugs et regression-hunt, deux modules destinés aux ingénieurs qui confient du code à des agents. Ces agents sont des systèmes d’intelligence artificielle capables d’enchaîner des tâches de programmation. Le premier module reproduit un défaut signalé, prépare un correctif et le teste. Le second cherche si la modification casse un comportement auparavant valide et toujours pris en charge. Pour un mainteneur, l’enjeu consiste à accélérer une réparation sans accepter aveuglément les autres changements produits.
Les ingénieurs restent aux commandes et examinent les résultats. Les responsables d’un projet peuvent aussi fournir leurs hypothèses de sécurité et leurs règles de correction. Les agents doivent alors travailler dans ce cadre explicite, plutôt que déduire seuls les priorités du logiciel. Cette approche provient de Patch the Planet, une initiative menée avec OpenAI. Elle a servi à produire des centaines de correctifs de sécurité pour des projets libres très utilisés. Trail of Bits s’appuie aussi sur des milliers de sessions Codex conduites par ses ingénieurs.
L’observation de 21 régressions confirmées
Le fait déclencheur vient d’un examen des correctifs déjà acceptés par les projets concernés. Une publication antérieure avait signalé des régressions dans certaines contributions de Patch the Planet. Trail of Bits a ensuite revu chaque modification rédigée par ses ingénieurs puis intégrée par les mainteneurs. Sur plus de 130 demandes d’intégration, l’équipe a confirmé 21 régressions. Seize touchaient des fonctions, une concernait les performances et quatre affectaient la construction du logiciel ou ses tests. Aucune n’a désactivé une protection de sécurité.
Dans cette recherche, une régression désigne un nouveau défaut causé par une modification. Elle doit casser un comportement auparavant correct et pris en charge, sur un chemin accessible à un utilisateur réel ou à un attaquant. Un agent a d’abord proposé des cas suspects. Il a ensuite exécuté une preuve de concept, ou PoC, avant et après le changement. Une PoC est un essai concret conçu pour démontrer le comportement observé. Un ingénieur a finalement examiné les résultats avant leur confirmation.
Une méthode conçue pour réduire le bruit
La méthode a d’abord montré sa propre fragilité. Les 21 régressions confirmées provenaient de 58 candidates relevées pendant une seule exécution, soit environ 36 % de précision. Les autres résultats imposaient donc un tri manuel. Le problème augmente lorsque plusieurs agents empruntent des chemins différents et remontent des listes divergentes. Trail of Bits en tire deux besoins. Il faut normaliser l’écriture des correctifs et appliquer une définition stable des régressions. Cette standardisation doit aussi rendre les exécutions répétables et comparables.
regression-hunt commence par suivre le code modifié jusqu’aux interfaces réellement utilisées. Il reproduit ensuite chaque défaut supposé sur une version construite et en fonctionnement. Un nouvel agent, privé du contexte du premier, rejoue la preuve. Une dernière étape juge l’ensemble des éléments. Elle doit écarter un faux positif, un défaut ancien, un problème déjà présent ou une correction incomplète. Un faux positif est une alerte qui semble valable, mais ne correspond pas à une véritable régression. Le module ne confirme le cas qu’après ces contrôles.
Des preuves exécutées plutôt que des résumés
Les deux modules découpent le travail en étapes utilisables ensemble ou séparément. Chaque étape reçoit et produit un format défini, comprenant l’affirmation testée, la révision du code, le contrôle demandé, les preuves brutes et les questions ouvertes. L’étape suivante vérifie ainsi les éléments précédents au lieu de faire confiance à leur résumé. Sans preuve exécutée sur une installation active, le résultat demeure explicitement non concluant. Cette exigence concerne la reproduction du défaut, la validation du correctif et la confirmation d’une régression.
patching-bugs applique une vérification en trois temps. Le défaut doit apparaître dans le code initial, disparaître avec le correctif, puis revenir après le retrait complet de celui-ci. Ce retour renforce le lien entre la modification et la réparation observée. Le module cherche aussi à restaurer la règle de sécurité violée, plutôt qu’à masquer le seul exemple connu. Enfin, il impose le passage par regression-hunt pour rechercher des effets indésirables. Une vérification indépendante et contradictoire complète ce processus de correction.
Un gain mesuré, avec une contrepartie
L’évaluation utilise les 21 régressions confirmées comme ensemble de comparaison. Face à un agent Codex seulement invité à examiner une modification, regression-hunt a produit 25 % de faux positifs en moins. L’intervalle de confiance à 95 % va de 14 % à 38 %. Cet intervalle représente la plage estimée autour du résultat mesuré. L’interprétation proposée reste prudente. Des critères de preuve stricts peuvent améliorer le signal transmis aux mainteneurs et réduire le temps consacré aux alertes erronées.
Les limites empêchent toutefois de confondre ce résultat avec une validation générale. Certains défauts connus sont restés classés comme cas limites, car le module n’avait pas réuni assez d’éléments. Réduire les faux positifs peut donc diminuer le nombre de régressions réellement confirmées. Trail of Bits prévoit d’étudier ces échecs, d’évaluer séparément patching-bugs et d’analyser les traces des agents. Ces traces enregistrent les étapes suivies pendant leur travail. Les prochaines versions doivent aussi permettre d’assouplir les règles lorsque davantage de candidats sont préférables.
Ce qui reste à confirmer
Les résultats disponibles viennent d’une évaluation préliminaire menée par Trail of Bits sur 21 régressions issues de ses propres contributions. La source ne fournit ni mesure complète du taux de détection, ni évaluation de patching-bugs, ni validation indépendante. Certains cas connus restent non confirmés faute de preuves suffisantes.