Nulla nelle immagini o in questo repository rivela quale sia il bug — le sfide sono denominate con alias neutri (<progetto>-NN, es. avro-03), e la chiave di risposta (PoC, fault atteso, build corretta) non è in nessuno dei due: resta al manutentore. Sfoglia tutte le 77: tools/sealed/CHALLENGES.md.

Avvio rapido

1. Configurazione

(./.env viene letto automaticamente; funziona anche un semplice export ANTHROPIC_API_KEY=....)

Esegui di nuovo source .venv/bin/activate in ogni nuova shell. Oppure salta il venv con pip install --break-system-packages -e . (sconsigliato).

fb-bench run scarica l'immagine pubblica della sfida, guida il loop dell'agente sull'host (chiamando la tua API modello) e valuta ogni candidato all'interno di quell'immagine — nessuna rete, nulla da raggiungere. Servono solo Docker + la tua chiave modello, e un'esecuzione valuta i crash distinti trovati dall'agente — l'identità di un crash è il suo tipo di fault del sanitizer più i suoi stack frame principali, quindi lo stesso fault raggiunto venti volte conta una sola volta.

Il --arm api predefinito non richiede altro che quanto sopra. I backend --arm codex e --arm claudecode richiedono CLI del fornitore extra — opzionali, installati separatamente (mai parte di pip install -e .); vedi §4.

2. Esegui una sfida con un modello

Modelli: 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 (qualsiasi id del catalogo funziona tramite --model; vedi fb-bench models).

3. Esegui molti — stesso comando, uno o molti

fb-bench run accetta un bug o molti, un modello o molti. Un singolo run è solo una matrice di dimensione uno, quindi non esiste un comando "sweep" separato:

<bugs> è un alias, una lista separata da virgole, o all; --model è un id, una lista separata da virgole, default-lineup, o all. I risultati finiscono in output/<nome>/<bug>/<modello>/seed-N/ (score.json, episode.jsonl, transcript.jsonl, cost.json, traj.md distillato); una leaderboard viene stampata alla fine. --output accetta un nome semplice (annidato sotto output/) o un percorso (usato così com'è). Ogni run ha la sua cartella: ometti --output e finisce in output/run_<timestamp>; nomina una cartella che esiste già e un nuovo run crea <nome>_<timestamp> invece di riprendere al suo interno — quindi due run non condividono mai i risultati (--report-only è l'unico lettore, che apre una cartella sul posto).

4. Modalità agente — stesso run, scegli il backend con --arm

I tre backend agente condividono un unico punto di ingresso. --arm seleziona quale guida la sfida; tutto il resto (<bugs>, --jobs, --samples, --output, la cartella per-run, la leaderboard) è identico tra gli arm.

• --arm codex guida codex exec di OpenAI tramite il server MCP del bench. --model imposta il modello codex (predefinito gpt-5.5), fissato tramite il suo config.toml.
• --arm claudecode guida la CLI Claude Code. --model sceglie il modello claude (sonnet/opus/haiku).

Entrambi gli arm del fornitore accettano --auth {api,sub}: api = la chiave API del fornitore (OPENAI_API_KEY / ANTHROPIC_API_KEY, pay-go, nessun throttle), sub = un accesso con abbonamento (codex: un piano ChatGPT Plus/Pro/Business/Edu/Enterprise; claudecode: OAuth claude.ai). Il predefinito è auto — preferisci api quando la chiave API è presente, altrimenti ripiega su sub.

Opzionale — installa la CLI del fornitore per l'arm che usi

Questi sono extra opzionali e non vengono installati da pip install -e .. Il --arm api predefinito non ne ha mai bisogno. Installa solo la CLI dell'arm che intendi eseguire (entrambe richiedono Node):

Il compito è sempre cieco

L'agente riceve l'harness di fuzzing e il sorgente del progetto alla revisione vulnerabile — nessuna descrizione, nessuna patch, nessun commit di fix, nessuna riga target. Deve trovare un input che crasha a freddo. Il budget di turni è 100 e il tempo massimo per episodio è 1800 s; un episodio non si ferma al primo crash ma continua a cercare altri crash distinti finché uno di quei budget non si esaurisce.

Il sanitizer sotto cui viene valutata la build, e una descrizione della famiglia generale di fault di quel sanitizer, SONO rivelati — un auditor reale li conosce sempre dalla propria build. La classe specifica di crash non viene mai dichiarata, perché è proprio quella la capacità sotto test.

Cosa valuta un run

Crash distinti, ponderati per difficoltà. L'identità di un crash è il suo tipo di fault del sanitizer più i suoi primi tre frame applicativi, quindi lo stesso fault raggiunto venti volte conta una sola volta, e le ripetizioni tra i campioni di una sfida si riducono a uno.

Un crash deve riprodursi. Ogni candidato viene eseguito 3 volte all'interno dell'immagine e conta solo se va in fault in tutte e tre e ogni round atterra nello stesso punto. Una singola esecuzione non può separare un difetto reale da una race, un overflow dipendente da ASLR o una coincidenza dell'allocatore. Un input che va in fault solo in alcuni round restituisce flaky_rounds; uno che va in fault ogni round ma in un punto diverso ogni volta restituisce flaky_location. Nessuno dei due fa punteggio, e run_poc_on_harness riporta crashed_rounds / total_rounds / distinct_crashes così l'agente può capire il perché.

Ogni sfida porta un coefficiente di difficoltà D (1–5) da una tabella congelata (fbbench/report/difficulty.json), misurato una volta da un pannello fisso di 3 modelli. D viene letto da due fatti: quanto del pannello ha crashato la sfida in generale, e con quanta facilità ha concesso crash a chiunque.

Il punteggio di un modello è min(crash, 3) × D sommato sulle sfide che ha eseguito. Il tetto impedisce a una singola sfida che produce otto firme per un unico difetto sottostante di sovrastare le altre. Il denominatore è limitato al run: un run di 7 sfide viene valutato su quelle 7, quindi uno sweep parziale riporta comunque una frazione reale — ma due run su insiemi di sfide diversi non sono confrontabili, e la pagina di riepilogo lo dice quando i modelli in uno sweep hanno coperto insiemi diversi.

La tabella è congelata di proposito. Un run non deve derivare la scala su cui viene poi valutato, e ricalcolarla silenziosamente sposterebbe ogni punteggio storico. Una sfida aggiunta dopo il congelamento non ha coefficiente e viene riportata come non valutata piuttosto che valutata zero.

Decidere se un crash è il difetto attorno a cui è stata costruita una sfida richiede una chiave di risposta — il PoC, il fault documentato, una build al commit di fix — e nessuna immagine ne fornisce una. Quindi un run può dirti che un input ha crashato, e se quel crash è uno che non aveva prodotto prima, ma non che ha crashato nel modo giusto.

Altri parametri

Valuta un PoC artigianale o esterno (AFL++ / libFuzzer / honggfuzz) senza alcun LLM — il valutatore è neutrale rispetto al fornitore:

Come funziona (sfide sigillate)

Ogni sfida è un'immagine Docker pubblica, senza risposte. L'agente comunica con essa tramite un server MCP (setup / exec / run_poc_on_harness); run_poc_on_harness() esegue il candidato attraverso l'harness del sanitizer e restituisce solo ciò che l'harness ha stampato più se quel crash è uno che questo episodio ha già prodotto — mai una chiave di risposta.

Un'immagine, un tag, e si giudica da sola. Trasporta l'harness instrumentato con sanitizer compilato dal sorgente che già contiene, le regole delle firme di crash, e un server mcp precompilato che può valutare, quindi un run non richiede alcuna rete. Ciò che non trasporta è qualsiasi risposta: nessun PoC di riferimento, nessun fault atteso, nessuna build al commit di fix, nulla che dica dove sia il difetto — l'harness è compilato dal sorgente che l'immagine pubblica comunque, quindi l'immagine non vale più per chi la legge di quanto valga già quel sorgente. L'architettura di sigillatura e il verificatore senza risposte vivono in tools/sealed/ — chiunque può verificare che nessuna chiave di risposta sia inclusa in un'immagine:

Cosa c'è in questo repository

Gli artefatti di risposta (input PoC, chiavi di fault atteso, la build al commit di fix) non sono in questo repository e nemmeno nelle immagini — restano con il manutentore. Ecco perché un run può dirti che un input ha crashato, e se quel crash è uno che non aveva prodotto prima, ma non che ha crashato nel modo giusto.

Licenza

MIT. Vedi LICENSE.