Principe de fonctionnement

Doc-foundry transforme une menace décrite (CVE, entrée CISA KEV, technique ATT&CK) en une règle de détection Sigma de première version, puis produit un bundle de preuve. Ce bundle contient la règle, un rapport de convergence et un fichier proof.json qui indique le taux de couverture réel, le nombre de faux positifs (FP) et de faux négatifs (FN), ainsi qu’un hash de reproductibilité. La preuve repose sur un adversaire fixe : le modèle rouge soumet deux attaques documentées à chaque tour, les mêmes attaques étant rejouées contre la règle renforcée jusqu’à ce que la règle survive.

Le système se compose de quatre agents LLM spécialisés : Threat Analyst, Blue Detection Engineer, Telemetry et Red‑Team Adversary. Tous les calculs de vérité (évaluation FP/FN, détection d’évasion, verdict de couverture) sont exécutés par un référé déterministe : même entrée, même verdict, même hash.

pip install -r requirements.txt
python src/run.py "CVE-2026-45659 SharePoint deserialization RCE"
python src/run.py --corpus atomic   # positives from REAL Atomic Red Team commands
python src/run.py --max-rounds 3    # limite la boucle d'auto‑réparation à 3 tours

Architecture des pipelines

Deux pipelines partagent le même cast d’agents. Le premier, décrit ci‑dessus, suit le flux ingest → extract → telemetry → profile → Blue draft → Red‑Team review → Blue revision → SOC Lead review → Blue final → package. Chaque itération du Red‑Team identifie les points d’évasion ou les faux positifs, ce qui force le Blue Detection Engineer à ajuster la règle tout en citant les identifiants de constatation. Le second pipeline, appelé Review Chain, se concentre sur la validation des parties prenantes : il passe la règle du rédacteur au Red‑Team, puis au SOC Lead, avant de produire la version finale et le journal complet des modifications.

Preuve de couverture et métriques

Le concept de real‑coverage est quantifié : la règle doit déclencher sur chaque attaque du corpus positif, rester silencieuse sur les échantillons bénins et capturer les deux attaques réelles du Red‑Team. Le fichier proof.json indique explicitement les valeurs FP, FN et le label de couverture (real‑coverage, brittle ou broken). Cette transparence permet à l’équipe de détection de savoir exactement où la règle est robuste et où elle nécessite un durcissement supplémentaire.

Exemple concret et limites

L’exemple fourni dans le dépôt porte sur la vulnérabilité CVE-2026-48939 (Joomla iCagenda upload‑to‑RCE), traitée par le modèle Claude‑opus‑4‑8. Trois versions de règle ont été générées, accompagnées de huit constats de révision. Le processus montre comment le Red‑Team a neutralisé un déclenchement basé sur un shell de reconnaissance, forçant le Blue Engineer à affiner la logique de filtrage. Cependant, la preuve reste limitée au corpus défini : aucune garantie n’est donnée contre des attaques futures non incluses dans le jeu de tests. La reproductibilité dépend du même jeu de données et du même modèle d’IA, ce qui peut poser des contraintes d’accès aux clés d’API (GEMINI ou ANTHROPIC) pour les environnements hors‑ligne.