Microsoft affirme que le laboratoire Frontier Offensive Research & Generative Exploitation, connu sous l’acronyme FORGE, est passé de l’évaluation de la capacité de l’intelligence artificielle à trouver des vulnérabilités difficiles à l’étude de ce qui est nécessaire pour transformer ces découvertes en correctifs prêts à être déployés. Entre mai et septembre 2026, le laboratoire a contribué à découvrir des vulnérabilités dans Windows auxquelles 140 identifiants CVE ont été attribués, dont 52 ont été traitées dans les mises à jour de sécurité de septembre 2026.
Les travaux se sont également étendus aux logiciels open source : les équipes de FORGE ont soumis environ 155 rapports vérifiés en interne concernant 23 projets, dont le noyau Linux. Selon Microsoft, 93 rapports couvrant 14 projets ou familles de projets avaient reçu une reconnaissance ou une acceptation documentée de la part des mainteneurs au moment de la préparation de l’article. En outre, l’un des rapports Linux soumis par l’intermédiaire de l’initiative Akrites de la Linux Foundation est devenu le premier rapport de l’initiative à aboutir à l’intégration d’un correctif dans le noyau Linux.
De la capacité maximale à l’exploitation à grande échelle
Le premier enseignement est que la réussite d’un modèle dans la découverte d’un défaut complexe ne garantit pas la production de correctifs à un rythme comparable. Augmenter le nombre de validateurs peut accroître le nombre de candidats, mais n’augmente pas nécessairement le nombre de résultats confirmés ou de correctifs publiés. Si les rapports arrivent plus vite que le Microsoft Security Response Center ne peut les examiner, une file d’attente se forme et mobilise le temps des experts, en particulier lorsque les rapports sont répétitifs ou ne contiennent pas de preuves reproductibles.
C’est pourquoi FORGE met l’accent sur un résultat reproductible, et non sur le seul nombre d’analyses ou de rapports. Le laboratoire utilise la plateforme multi-modèles MDASH pour organiser le travail, ainsi que des générateurs de preuves d’exploitabilité ou de preuves de concept, des outils de test et des mécanismes permettant de trouver des entrées qui déclenchent le comportement défectueux. Microsoft indique qu’un projet interne reposant sur des algorithmes déterministes, tels que l’analyse de l’arbre syntaxique abstrait, a réduit les rapports en double d’environ 45 % lors de plusieurs analyses du même code.
Dépenser pour réduire l’incertitude, et non pour augmenter le nombre de textes
Microsoft estime que mesurer l’efficacité uniquement au nombre de jetons produits par le modèle conduit à un indicateur trompeur. Un rapport succinct peut être ambigu et coûteux à examiner, tandis qu’une analyse plus longue peut justifier le chemin d’exécution et réduire le coût global. La décision pratique consiste à déterminer ce qui manque à l’enquêteur — l’appelant de la fonction, la configuration de compilation, le reproducteur exécutable ou l’explication causale — puis à orienter l’étape suivante précisément pour combler cette lacune.
MDASH associe des modèles avancés à des modèles distillés, des validateurs spécialisés et des outils d’analyse du code, avec la possibilité d’orienter les tâches routinières vers des modèles moins coûteux et de transmettre les questions non résolues à des modèles plus puissants. Microsoft souligne toutefois que cette politique reste une hypothèse à mesurer, car un filtrage précoce peut écarter de véritables vulnérabilités.
La validation et la correction comme boucle d’apprentissage continue
Selon cette approche, la validation et la correction ne doivent pas être traitées comme une étape ultérieure à la découverte de la vulnérabilité. Chaque résultat doit passer par une validation automatisée, une revue humaine, l’élaboration du correctif et des tests de régression, les preuves de chaque étape étant réinjectées dans le système. Même un échec de validation peut être utile si sa cause est enregistrée, par exemple l’inaccessibilité du chemin, une configuration de compilation incorrecte, l’absence de contrôle de l’attaquant sur les entrées ou la duplication du rapport.
Lors d’une expérience sur le noyau Linux, les agents de validation ont produit des éléments probants à l’appui de 627 résultats, tandis que le coût moyen de création d’une preuve de concept pour 182 résultats confirmés par un plantage s’élevait à 3,61 dollars de coût de modèle et à 21,5 minutes par cas réussi. Dans six cas où la possibilité d’une élévation locale des privilèges a été testée au moyen de la génération automatisée d’un exploit, la moyenne s’élevait à 8,56 dollars et à 25,4 minutes. Les évaluations ont utilisé GPT-5.5 et n’incluaient pas les coûts de l’analyse initiale, des cas ayant échoué, de l’enquête humaine ni de la préparation des correctifs.
Qu’est-ce que cela signifie pour les équipes de sécurité ?
La principale conclusion de ces résultats est que la mesure du succès des systèmes agentiques de découverte des vulnérabilités ne devrait pas se limiter au nombre de résultats. Microsoft propose de suivre le nombre de défauts confirmés, les rapports en double et rejetés, l’ancienneté de la file d’attente et le délai entre la découverte et la correction, en plus du coût des modèles et du temps consacré à la revue humaine. Le travail sur des projets open source exige également de respecter les procédures propres à chaque projet en matière de divulgation, de revue et de correction, plutôt que de simplement envoyer davantage de rapports.
En pratique, la source identifie un déplacement du goulot d’étranglement : la capacité à trouver le défaut n’est plus qu’une partie du problème, tandis que l’importance de relier la recherche aux environnements de compilation, aux fichiers binaires, aux configurations, aux outils de test et aux systèmes CI/CD augmente. Les limites des résultats restent claires : les chiffres relatifs au coût de la validation excluent d’importantes étapes humaines, et la transformation des résultats de recherche en une correction acceptée dépend des mainteneurs et du contexte de chaque projet. L’article ne démontre donc pas que l’automatisation remplace la revue technique, mais la présente comme un moyen de réduire le travail répétitif tout en maintenant la responsabilité du jugement de sécurité et de la correction entre les mains des humains.