En bref
- Entre mai et septembre 2026, FORGE a contribué à la découverte de vulnérabilités Windows associées à 140 CVE, dont 52 traitées dans la publication de sécurité de septembre.
- Dans l’open source, l’équipe a transmis 155 rapports validés en interne à 23 projets, mais seuls 93 rapports concernant 14 projets ou familles avaient reçu un accusé de réception ou une acceptation documentée.
- L’expérience présentée par Microsoft indique que le volume de détection n’est plus une mesure suffisante : la preuve reproductible, la capacité de revue et le passage effectif à un correctif deviennent les ressources critiques.
- Les coûts annoncés pour la validation automatisée du noyau Linux ne couvrent que des cas réussis et excluent notamment le filtrage initial, les échecs, l’enquête humaine et la préparation des correctifs.
Le goulet d’étranglement change de place
L’observation centrale de Microsoft ne porte pas seulement sur les performances d’un modèle. Entre mai et septembre 2026, son laboratoire Frontier Offensive Research & Generative Exploitation, ou FORGE, dit avoir contribué à la découverte de vulnérabilités Windows auxquelles 140 identifiants CVE ont été attribués. Cinquante-deux ont été traitées dans la publication de sécurité de septembre. En parallèle, ses chercheurs ont envoyé 155 rapports validés en interne à 23 projets open source, dont le noyau Linux. Ces chiffres décrivent une capacité à produire des pistes à une échelle déjà significative.
L’interprétation proposée par l’équipe est toutefois moins triomphale que ne le suggèrent ces volumes. Une découverte ne crée une valeur défensive que si elle peut être confirmée, comprise, corrigée puis intégrée à une publication. Lorsque les signalements arrivent plus vite que le Microsoft Security Response Center ou les mainteneurs ne peuvent les examiner, la file d’attente s’allonge. Davantage d’agents et de calcul peuvent alors dégrader le rendement utile en multipliant les doublons ou les dossiers insuffisamment étayés, au détriment des cas les plus solides.
De la piste plausible à la preuve exploitable
La méthode repose sur MDASH, un dispositif agentique qui combine plusieurs modèles, des auditeurs spécialisés et des outils d’analyse de code. FORGE ne cherche pas uniquement à repérer des fragments suspects. Des générateurs de preuves de vulnérabilité ou de concepts, des constructeurs de harnais de test et des outils de recherche d’entrées déclenchantes doivent établir qu’un chemin d’exécution est accessible et produire un cas reproductible dans l’environnement de compilation et de test du projet. La sortie recherchée n’est donc pas un rapport supplémentaire, mais un élément que l’étape suivante peut réellement utiliser.
Cette préparation comprend aussi la déduplication. Microsoft indique qu’un projet interne fondé notamment sur des algorithmes déterministes appliqués aux arbres syntaxiques abstraits a éliminé environ 45 % de résultats redondants issus de plusieurs analyses du même code. Cette réduction allège ensuite le travail des générateurs de preuves et celui des analystes humains. Le mécanisme illustre le changement d’unité de mesure défendu par FORGE : optimiser la progression d’un défaut reproductible dans la chaîne de traitement plutôt que le nombre brut d’analyses lancées ou de signalements produits.
Dépenser du raisonnement là où subsiste l’incertitude
La seconde dimension de l’étude concerne l’économie du raisonnement. Réduire mécaniquement le nombre de jetons n’est pas présenté comme un bon objectif : un rapport bref mais ambigu peut coûter peu à générer et beaucoup à vérifier. À l’inverse, une analyse plus longue qui démontre un chemin d’exécution manquant peut diminuer le coût global. MDASH répartit donc les tâches entre modèles avancés, modèles distillés et outils spécialisés. Un index peut retrouver des appelants, un test exécutable peut confirmer un plantage, tandis qu’un raisonnement plus puissant peut être réservé à l’interaction complexe de plusieurs conditions.
Microsoft présente néanmoins ce routage comme une hypothèse à mesurer, non comme un gain acquis. L’étape suivante doit combler un manque d’élément précis, par exemple une configuration de compilation, un cas reproductible ou une explication causale. Refaire une revue sans nouvelle preuve consomme des ressources sans réduire l’incertitude. À l’opposé, un filtrage précoce trop agressif peut éliminer de vraies vulnérabilités. L’interprétation économique doit donc intégrer simultanément le coût des modèles, le temps humain, la couverture obtenue et les défauts qui pourraient avoir été manqués.
Une boucle qui relie détection, correction et apprentissage
Dans l’approche décrite, validation et remédiation ne sont pas des opérations de nettoyage reléguées après la découverte. Chaque candidat traverse une vérification automatisée, une revue humaine, le développement d’un correctif et un test de non-régression. Un échec devient lui aussi une donnée s’il précise la cause : chemin inaccessible, précondition absente, mauvaise configuration, contrôle insuffisant par un attaquant, doublon ou raisonnement causal incomplet. Associés au contexte du code, ces verdicts, retours de revue et résultats de correctifs peuvent alimenter l’entraînement ou l’ajustement de futurs modèles spécialisés.
L’organisation des responsabilités reste humaine et explicite. La recherche fournit l’hypothèse, le chemin causal et les incertitudes ; les systèmes de preuve apportent des éléments d’exécution sur les bons artefacts ; les équipes de composants évaluent l’invariant violé, la stratégie de réparation et les risques de compatibilité ; enfin, le processus de maintenance rattache le changement approuvé à la validation de publication. FORGE vise à automatiser les tâches répétables autour de ces décisions, pas à supprimer la revue de code, l’évaluation de l’impact ou le contrôle final d’une mise à jour.
Des résultats mesurés, mais un périmètre à ne pas dépasser
Sur le noyau Linux, MDASH a relevé des milliers d’emplacements suspects et ses agents de validation ont produit des éléments à l’appui de 627 résultats. Pour 182 plantages confirmés, la génération réussie d’une preuve de concept a coûté en moyenne 3,61 dollars en modèle et 21,5 minutes. Sur six cas sélectionnés, un test automatisé du potentiel d’élévation locale de privilèges a atteint 8,56 dollars et 25,4 minutes en moyenne. Ces évaluations utilisaient GPT-5.5 sans adaptation poussée du modèle ni du harnais à la tâche.
Ces moyennes ont une limite méthodologique précise : elles incluent toutes les tentatives liées aux cas réussis présentés, mais pas le tri initial, les candidats écartés ou infructueux, l’enquête humaine ni la préparation des correctifs. Elles ne mesurent donc pas le coût complet d’une vulnérabilité corrigée. Dans l’open source, 93 des 155 rapports avaient reçu une reconnaissance ou une acceptation documentée au moment de la publication. Un rapport Linux transmis par FORGE est devenu la première soumission du dispositif Akrites à aboutir à un correctif intégré au noyau, résultat concret mais insuffisant pour généraliser le taux de conversion de l’ensemble.
Ce qui reste à confirmer
Les chiffres proviennent de l’étude de Microsoft sur son propre laboratoire et ne fournissent ni audit indépendant ni taux complet reliant chaque candidat à un correctif publié. Les cohortes mensuelles Windows correspondent aux annonces et aux opérations de maintenance, pas aux dates de découverte ni au débit des analyses. Les coûts Linux ne concernent que des validations réussies et omettent le filtrage, les échecs, le travail humain et la préparation des correctifs ; le statut final des rapports open source encore en traitement n’est pas donné.