Des environnements contrôlés au monde réel : évaluation des agents de pentest en conditions réelles

Les agents de pentest basés sur l'IA sont de plus en plus crédibles en tant que systèmes de sécurité offensive, mais les benchmarks actuels n’offrent encore qu’un guidage limité sur les systèmes qui obtiendront les meilleurs résultats sur des cibles réelles. La plupart des évaluations existantes évaluent et optimisent des objectifs prédéfinis tels que la capture de flag, l’exécution de code à distance, la reproduction d’exploits ou la similarité des trajectoires, dans des environnements simplifiés ou restreints. Ces benchmarks sont utiles pour mesurer des capacités délimitées, mais ils ne saisissent pas correctement la complexité, l’exploration libre et la prise de décision stratégique requises dans un pentest réaliste. Nous présentons un cadre d’évaluation pratique qui déplace l’évaluation de l’accomplissement de tâches vers la découverte validée de vulnérabilités, permettant une évaluation sur des cibles suffisamment complexes couvrant plusieurs surfaces d’attaque et classes de vulnérabilités. Le cadre combine une vérité terrain structurée à une correspondance sémantique basée sur LLM pour identifier les vulnérabilités, une résolution bipartie pour noter les constatations dans une ambiguïté réaliste, une maintenance continue de la vérité terrain, une évaluation répétée et cumulative d’agents stochastiques, des métriques d’efficacité, ainsi qu’une sélection de suite réduite pour une expérimentation durable. Cette méthodologie fait évoluer l’état de l’art en permettant une comparaison plus réaliste et plus instructive sur le plan opérationnel des agents de pentest IA. Pour garantir la reproductibilité, nous publions également une vérité terrain annotée par des experts ainsi que le code du protocole d’évaluation proposé.

Pipeline d’évaluation pour les outils de test de sécurité. Compare les constatations de l’outil aux jeux de données de vérité terrain à l’aide d’une correspondance basée sur LLM et produit les métriques précision, rappel, F1 et F0.5.

Installation

poetry install

Nécessite Python 3.11+ et Poetry installés.

Quick Start

# 1. Set your LLM API key
export OPENAI_API_KEY="..."

# 2. Run evaluation
ethibench evaluate ./my_experiment --dataset path/to/dataset.yaml

# 3. View results
cat ./my_experiment/evaluation_outputs/summary.md

Commandes CLI

ethibench evaluate

Exécute le pipeline d’évaluation complet sur un répertoire d’expérience.

ethibench evaluate <experiment_dir> --dataset <dataset.yaml> [options]

# Batch: evaluate all experiments in a folder
ethibench evaluate --parent-dir final_experiments/ --dataset <dataset.yaml>

# Force re-evaluation (ignore cached artifacts)
ethibench evaluate <experiment_dir> --dataset <dataset.yaml> --force

Arguments :

• experiment_dir — (facultatif) Répertoire contenant les sous-répertoires de cibles (ou des sous-répertoires run_* contenant chacun des sous-répertoires de cibles). Peut être omis lors de l’utilisation de --parent-dir.

Options :

• --dataset, -d — (obligatoire) Chemin vers le fichier YAML du jeu de données.
• --gt-dir, -g — Répertoire de vérité terrain. Par défaut gt/ à côté du fichier YAML du jeu de données.
• --output-dir, -o — Répertoire de sortie. Par défaut evaluation_outputs/ dans le répertoire d’expérience. Ignoré en mode batch.
• --replicates, -n — Nombre de répliques de correspondance LLM (défaut : 1).
• --force, -f — Réexécute toutes les étapes, en ignorant les artefacts en cache. Par défaut, les résultats intermédiaires existants (correspondances brutes, correspondances biparties, métriques) sont réutilisés.
• --parent-dir, -p — Dossier parent contenant plusieurs répertoires d’expériences à évaluer en batch. Tous les sous-répertoires immédiats sont traités comme des expériences.

Ce qu’il fait :

1. Collecte des constatations — analyse les sous-répertoires de cibles (nom de dossier = target_id), charge chaque findings.jsonl, attribue subset_name depuis le YAML du jeu de données.
2. Correspondance LLM brute — compare chaque constatation à chaque entrée de vérité terrain à l’aide d’un LLM.
3. Correspondance bipartie — algorithme hongrois pour trouver l’affectation optimale 1 pour 1.
4. Métriques — calcule TP, FP, FN, doublons, précision, rappel, F1, F0.5 et le score de sévérité par sous-ensemble.
5. Agrégation — calcule la moyenne sur les répliques et les exécutions, et les résultats globaux pondérés/non pondérés.
6. Métriques de coût — charge metrics.json par cible s’il existe, agrège coût/tokens/durée.
7. Graphiques — génère des diagrammes PNG dans evaluation_outputs/plots/.
8. Résumé — écrit evaluation_outputs/summary.md.

ethibench analyze

Exécute les outils d’analyse sur des sorties d’évaluation existantes.

ethibench analyze <experiment_dir> --dataset <dataset.yaml> [options]

# Batch: analyze all experiments and produce aggregated results
ethibench analyze --parent-dir final_experiments/ --dataset <dataset.yaml>

Arguments :

• experiment_dir — (facultatif) Répertoire d’expérience à analyser. Peut être omis lors de l’utilisation de --parent-dir.

Options :

• --dataset, -d — (obligatoire) Chemin vers le fichier YAML du jeu de données.
• --gt-dir, -g — Répertoire de vérité terrain. Par défaut gt/ à côté du fichier YAML du jeu de données.
• --output-dir, -o — Répertoire des sorties d’évaluation. Par défaut evaluation_outputs/ dans le répertoire d’expérience.
• --parent-dir, -p — Dossier parent contenant plusieurs répertoires d’expériences à analyser en batch. Produit une analyse par expérience ainsi que des résultats agrégés.

Sorties par expérience (evaluation_outputs/analysis/) :

• duplicates.json — constatations qui correspondaient lors de la correspondance brute mais qui ont été supprimées par l’optimisation bipartie.
• unmatched.json — constatations sans correspondance avec la vérité terrain (faux positifs).
• statistics.json — statistiques de couverture GT, distribution des constatations par GT.

Sorties agrégées (uniquement avec --parent-dir, dans <parent-dir>/aggregated_analysis/) :

• all_duplicates.jsonl — toutes les constatations en double dans toutes les expériences (JSONL, objets de constatation complets avec le champ experiment).
• all_false_positives.jsonl — toutes les constatations sans correspondance / faux positifs dans toutes les expériences (format JSONL).
• gt_statistics_avg.json — couverture GT moyenne par sous-ensemble, plus résumé de couverture par expérience.

ethibench compare

Compare les résultats d’évaluation de plusieurs expériences, en produisant des graphiques côte à côte et un rapport récapitulatif. Chaque expérience doit déjà avoir des sorties d’évaluation (exécutez ethibench evaluate d’abord). Les libellés correspondent toujours aux noms de répertoires.

# Explicit experiment directories
ethibench compare exp-gpt4o/ exp-claude/ --output-dir comparison/

# Auto-discover all experiments under a parent folder
ethibench compare --parent-dir all-experiments/ --output-dir comparison/

# Mix: explicit dirs + auto-discovery
ethibench compare exp-extra/ --parent-dir all-experiments/ --output-dir comparison/

Arguments :

• experiment_dirs — (facultatif) Un ou plusieurs répertoires d’expériences à inclure explicitement.

Options :

• --output-dir, -o — (obligatoire) Répertoire de sortie pour les résultats de comparaison.
• --parent-dir, -p — Dossier parent pour la découverte automatique des expériences. Tout sous-répertoire immédiat contenant un dossier evaluation_outputs/ est inclus, trié par ordre alphabétique. Peut être combiné avec des experiment_dirs explicites.