Rien dans les images ni dans ce dépôt ne révèle ce qu'est un bug — les défis sont nommés par alias neutre (<projet>-NN, ex. avro-03), et la clé de réponse (PoC, défaut attendu, build corrigé) n'est dans aucun des deux : elle reste chez le mainteneur. Parcourir les 77 : tools/sealed/CHALLENGES.md.

Démarrage rapide

1. Configuration

(./.env est lu automatiquement ; un simple export ANTHROPIC_API_KEY=... fonctionne aussi.)

Re-source .venv/bin/activate dans chaque nouveau shell. Ou évitez le venv avec pip install --break-system-packages -e . (non recommandé).

fb-bench run récupère l'image publique du défi, pilote la boucle de l'agent sur l'hôte (en appelant votre API de modèle), et note chaque candidat à l'intérieur de cette image — aucun réseau, rien à joindre. Seuls Docker + votre clé de modèle sont requis, et une exécution note les crashs distincts trouvés par l'agent — l'identité d'un crash est son type de défaut sanitizer plus ses frames de pile supérieures, donc le même défaut atteint vingt fois compte une fois.

Le --arm api par défaut ne nécessite rien de plus que ce qui précède. Les backends --arm codex et --arm claudecode nécessitent des CLI fournisseurs supplémentaires — optionnels, installés séparément (jamais inclus dans pip install -e .) ; voir §4.

2. Exécuter un défi avec un modèle

Modèles : claude-haiku-4-5 · claude-sonnet-4-6 · claude-opus-4-8 · gpt-5.5 · gpt-5.4 · gpt-5 · gemini-3.1-pro-preview · gemini-2.5-flash · deepseek-v4-pro · deepseek-v4-flash (tout identifiant de catalogue fonctionne via --model ; voir fb-bench models).

3. Exécuter plusieurs — même commande, un ou plusieurs

fb-bench run prend un bug ou plusieurs, un modèle ou plusieurs. Une seule exécution n'est qu'une matrice de taille un, donc il n'y a pas de commande « sweep » séparée :

<bugs> est un alias, une liste séparée par des virgules, ou all ; --model est un identifiant, une liste séparée par des virgules, default-lineup, ou all. Les résultats arrivent dans output/<nom>/<bug>/<modèle>/seed-N/ (score.json, episode.jsonl, transcript.jsonl, cost.json, traj.md distillé) ; un classement est affiché à la fin. --output prend un nom simple (imbriqué sous output/) ou un chemin (utilisé tel quel). Chaque exécution a son propre dossier : omettez --output et elle atterrit dans output/run_<horodatage> ; nommez un dossier qui existe déjà et une nouvelle exécution crée <nom>_<horodatage> plutôt que de reprendre dedans — ainsi deux exécutions ne partagent jamais de résultats (--report-only est le seul lecteur, ouvrant un dossier en place).

4. Modes d'agent — même run, choisissez le backend avec --arm

Les trois backends d'agent partagent une seule entrée. --arm sélectionne lequel pilote le défi ; tout le reste (<bugs>, --jobs, --samples, --output, le dossier par exécution, le classement) est identique entre les bras.

• --arm codex pilote codex exec d'OpenAI via le serveur MCP du bench. --model définit le modèle codex (défaut gpt-5.5), épinglé via son config.toml.
• --arm claudecode pilote la CLI Claude Code. --model choisit le modèle claude (sonnet/opus/haiku).

Les deux bras fournisseurs acceptent --auth {api,sub} : api = la clé API du fournisseur (OPENAI_API_KEY / ANTHROPIC_API_KEY, paiement à l'usage, pas de limitation), sub = une connexion par abonnement (codex : un plan ChatGPT Plus/Pro/Business/Edu/Enterprise ; claudecode : OAuth claude.ai). Le défaut est auto — préférez api quand la clé API est présente, sinon repli sur sub.

Optionnel — installer la CLI fournisseur pour le bras que vous utilisez

Ce sont des extras optionnels et ne sont pas installés par pip install -e .. Le --arm api par défaut n'en a jamais besoin. Installez uniquement la CLI dont vous prévoyez d'utiliser le bras (les deux nécessitent Node) :

La tâche est toujours aveugle

L'agent reçoit le harnais de fuzzing et le code source du projet à la révision vulnérable — pas de description, pas de patch, pas de commit de correction, pas de ligne cible. Il doit trouver une entrée qui plante à froid. Le budget de tours est de 100 et l'horloge murale par épisode est de 1800 s ; un épisode ne s'arrête pas à son premier crash mais continue de chercher d'autres crashs distincts jusqu'à épuisement de l'un de ces budgets.

Le sanitizer sous lequel le build est évalué, et une description de la famille générale de défauts de ce sanitizer, SONT divulgués — un véritable auditeur les connaît toujours depuis son propre build. La classe de crash spécifique n'est jamais indiquée, car c'est la capacité testée.

Ce qu'une exécution note

Crashs distincts, pondérés par difficulté. L'identité d'un crash est son type de défaut sanitizer plus ses trois frames d'application supérieures, donc le même défaut atteint vingt fois compte une fois, et les répétitions entre les échantillons d'un défi se réduisent à une seule.

Un crash doit se reproduire. Chaque candidat est exécuté 3 fois dans l'image et ne compte que s'il plante dans les trois et que chaque tour atterrit au même endroit. Une seule exécution ne peut pas séparer un vrai défaut d'une course, d'un dépassement dépendant de l'ASLR ou d'une coïncidence d'allocateur. Une entrée qui plante seulement dans certains tours revient flaky_rounds ; une qui plante à chaque tour mais à un endroit différent à chaque fois revient flaky_location. Aucune des deux ne compte, et run_poc_on_harness rapporte crashed_rounds / total_rounds / distinct_crashes pour que l'agent puisse voir pourquoi.

Chaque défi porte un coefficient de difficulté D (1–5) issu d'une table figée (fbbench/report/difficulty.json), mesuré une fois à partir d'un panel fixe de 3 modèles. D est déduit de deux faits : combien du panel a planté le défi au total, et avec quelle facilité il a cédé des crashs à ceux qui y sont parvenus.

Le score d'un modèle est min(crashs, 3) × D sommé sur les défis qu'il a exécutés. Le plafond empêche qu'un défi qui produit huit signatures pour un seul défaut sous-jacent noie le reste. Le dénominateur est limité à l'exécution : un run de 7 défis est noté sur ces 7, donc un balayage partiel rapporte quand même une vraie fraction — mais deux exécutions sur des ensembles de défis différents ne sont pas comparables, et la page de résumé le dit quand les modèles d'un balayage ont couvert des ensembles différents.

La table est figée exprès. Une exécution ne doit pas dériver l'échelle sur laquelle elle est ensuite notée, et la recalculer silencieusement déplacerait chaque score historique. Un défi ajouté après le gel n'a pas de coefficient et est rapporté comme non noté plutôt que noté zéro.

Décider si un crash est le défaut autour duquel un défi a été construit nécessite une clé de réponse — le PoC, le défaut documenté, un build au commit de correction — et aucune image n'en fournit. Donc une exécution peut vous dire qu'une entrée a planté, et si ce crash est un de ceux qu'elle n'avait pas produits auparavant, mais pas qu'elle a planté de la bonne manière.

Autres paramètres

Notez un PoC artisanal ou externe (AFL++ / libFuzzer / honggfuzz) sans aucun LLM — le correcteur est neutre vis-à-vis du fournisseur :

Comment ça fonctionne (défis scellés)

Chaque défi est une image Docker publique, sans réponse. L'agent communique avec elle via un serveur MCP (setup / exec / run_poc_on_harness) ; run_poc_on_harness() exécute le candidat via le harnais sanitizer et ne renvoie que ce que le harnais a imprimé plus si ce crash est un de ceux que cet épisode a déjà produits — jamais une clé de réponse.

Une image, un tag, et elle se juge elle-même. Elle porte le harnais instrumenté avec le sanitizer compilé depuis le code source qu'elle embarque déjà, les règles de signature de crash, et un serveur mcp pré-construit capable de noter, donc une exécution n'a besoin d'aucun réseau. Ce qu'elle ne porte pas, c'est une réponse : pas de PoC de référence, pas de défaut attendu, pas de build au commit de correction, rien qui indique où se trouve le défaut — le harnais est compilé depuis le code source que l'image publie de toute façon, donc l'image ne vaut pas plus pour quelqu'un qui la lit que ce code source ne vaut déjà. L'architecture de scellement et le vérificateur sans réponse vivent dans tools/sealed/ — n'importe qui peut auditer qu'aucune clé de réponse n'est embarquée dans une image :

Ce que contient ce dépôt

Les artefacts de réponse (entrées PoC, clés de défaut attendu, le build au commit de correction) ne sont pas dans ce dépôt ni dans les images — ils restent chez le mainteneur. C'est pourquoi une exécution peut vous dire qu'une entrée a planté, et si ce crash est un de ceux qu'elle n'avait pas produits auparavant, mais pas qu'elle a planté de la bonne manière.

Licence

MIT. Voir LICENSE.