FORGE : un pipeline multi-agent qui transforme les CVE en exploits et en détections

De quoi s’agit-il ?

Le 2 juin 2026, Farooq Shaikh, chercheur chez Dynatrace, a publié FORGE: Multi-Agent Graduated Exploitation and Detection Engineering (arXiv:2606.03453), accepté à l’atelier AgentCy de la conférence ARES 2026. L’article traite un problème de chaîne de production plutôt qu’une vulnérabilité isolée : le volume de CVE divulguées dépasse désormais largement la capacité d’évaluation des organisations, tandis que les trois communautés censées coopérer — génération de preuves de concept, priorisation des vulnérabilités et ingénierie de règles de détection — travaillent le plus souvent en silos.

FORGE cherche à câbler ces trois étapes dans un seul pipeline d’agents LLM. L’aspect intéressant pour les défenseurs n’est pas qu’un agent sache écrire un exploit ; c’est que la même exécution produise une règle de détection ainsi qu’un verdict gradué et audité sur la profondeur réelle de l’exploitation. Le code complet, les résultats par CVE et les verdicts d’audit de l’oracle sont publiés sous licence Apache 2.0 sur github.com/dynatrace-oss/forge.

Comment ça marche

FORGE exécute cinq agents spécialisés dans un pipeline figé, chacun consommant la sortie du précédent :

1. Intel — ingère les métadonnées d’une CVE (texte d’advisory, composants affectés) et en extrait les faits structurés nécessaires à la suite.
2. Generator — construit une application vulnérable ciblée : une application minimale et autonome qui reproduit la faille, de sorte que l’exploitation s’exécute sur une cible de laboratoire dédiée, et non sur un système en production.
3. Planner — transforme le renseignement en stratégie d’exploitation.
4. Exploit — mène une tentative multi-tours encadrée contre la cible générée.
5. Detector — élabore une règle de détection à partir de ce que l’exploitation a produit.

L’élément nouveau est ce que l’article appelle l’exploitation graduée : au lieu d’un binaire « ça passe ou ça casse », un oracle à dominante LLM note chaque tentative sur une taxonomie à quatre niveaux, de L0 (aucune preuve d’exploitation) à L3 (compromission totale). Noter la profondeur du succès, et non seulement le succès ou l’échec, est ce qui permet au pipeline de prioriser : une CVE qu’un agent peut mener jusqu’à L3 sur une reproduction fidèle constitue un signal opérationnel très différent d’une CVE qui plafonne à L1. Comme l’exploitation ne s’exécute jamais que contre la cible synthétique du Generator, la boucle produit des preuves et des détections sans toucher aux logiciels en production.

Pourquoi c’est important

FORGE s’inscrit dans la même catégorie émergente que les travaux récents sur les agents qui chassent ou trient les vulnérabilités — benchmarks de chasse aux bugs sur horizon long, détection de vulnérabilités orientée spécification et le constat sobre que les agents génériques perdent encore face aux outils SAST déterministes. Ce que FORGE ajoute, c’est le pont entre une vulnérabilité et une détection déployable, assorti d’un signal de confiance gradué.

Ce pont fonctionne dans les deux sens. Pour un SOC, un chemin automatisé entre « une nouvelle CVE vient de tomber » et « une règle de détection candidate plus une reproduction sur laquelle la tester » est réellement utile, et comprimer l’évaluation d’exploitabilité de plusieurs semaines à quelques heures rejoint ce que rapportent les travaux de red teaming agentique. Mais la même architecture est un patron que les attaquants peuvent copier : un pipeline qui lit un advisory et progresse vers un exploit fonctionnel, c’est précisément l’industrialisation de l’offensive que les articles de modélisation de la menace anticipent. La publication open source abaisse la barrière pour les défenseurs comme pour les adversaires — c’est la tension standard et inévitable de tout outillage offensif publié, et c’est pourquoi la transparence de l’évaluation et de l’audit de l’oracle compte autant que les résultats d’exploitation.

Défenses

Pour les équipes qui lisent FORGE en défenseurs plutôt qu’en constructeurs d’outils :

1. Traitez la sortie de détection comme un brouillon, pas comme une règle prête à déployer. Une détection générée par LLM reflète une seule reproduction synthétique ; validez-la sur de la télémétrie réelle et réglez-la contre les faux positifs avant qu’elle ne conditionne quoi que ce soit, la même prudence que pour la sortie d’un LLM-scanner.
2. Ne faites pas une confiance aveugle à la note. Le verdict L0–L3 provient d’un oracle à dominante LLM ; l’article publie ses verdicts d’audit précisément pour qu’ils puissent être vérifiés. Servez-vous du score gradué pour prioriser la revue humaine, pas pour la remplacer.
3. Supposez que les attaquants disposent du même pipeline. Si une CVE de votre stack est du genre que des agents façon FORGE peuvent mener jusqu’à L3 sur un clone fidèle, ajustez l’urgence de patch en conséquence — le délai d’évaluation qui vous faisait gagner du temps se réduit.
4. Gardez la génération en bac à sable. La propriété de sûreté du design est que l’exploitation ne s’exécute que contre des cibles construites pour l’occasion. Toute adaptation interne de ce schéma doit préserver cette isolation et ne jamais pointer l’agent Exploit vers une infrastructure vivante ou partagée.
5. Alimentez la priorisation avec les résultats gradués, pas seulement le décompte de tickets. L’intérêt de la taxonomie à quatre niveaux est de séparer le théoriquement exploitable du démontrablement exploitable ; servez-vous-en pour classer la remédiation.

Statut

Élément	Référence	Date	Notes
Article	arXiv:2606.03453	2026-06-02	Atelier AgentCy, ARES 2026
Pipeline	Intel → Generator → Planner → Exploit → Detector	2026-06-02	Cinq agents, ordre figé
Notation	L0 (aucune preuve) → L3 (compromission totale)	2026-06-02	Oracle à dominante LLM, audité
Code	github.com/dynatrace-oss/forge	2026-06-02	Apache 2.0, avec dépôt d’artefacts

À retenir : FORGE est moins une nouvelle attaque qu’une démonstration que la boucle CVE → exploit → détection peut être automatisée de bout en bout avec les agents LLM actuels — et graduée en confiance au passage. Pour les défenseurs, la valeur pratique est une ingénierie de détection plus rapide et priorisée ; le risque symétrique est que le même plan comprime tout autant le calendrier offensif, de sorte que les hypothèses de priorisation des correctifs fondées sur un développement d’exploit lent méritent un réexamen.