Fix Like Artifacts with Embedded Defects

Un harness di ricerca per misurare quanto bene gli agenti AI correggono le vulnerabilità.

Avvio rapido · Dataset · Documentazione · Modello di sicurezza · Contribuire

FLAWED estrae un progetto open-source a un commit noto come vulnerabile, fornisce a un agente AI una descrizione del bug e gli chiede di scrivere una patch. L'agente non vede mai la vera correzione upstream.

Ogni patch viene poi validata, verificata e valutata in container isolati, così puoi vedere non solo se il modello ha corretto il bug, ma anche se ne ha introdotti di nuovi lungo il percorso.

Come funziona

flowchart LR
    spec[bug spec] --> clone
    clone["clone<br/>(open net)"] --> generate
    generate["generate<br/>(offline)"] --> validate
    validate["validate<br/>(offline)"] --> ast["ast<br/>(offline)"]
    generate -.->|"patch.diff"| store[(Postgres)]
    validate -.->|"verdict"| store
    ast -.->|"summary"| store
    store --> ui[web UI + notebook]

Ogni fase viene eseguita nel proprio container. Solo clone ha accesso alla rete. Ogni fase successiva è limitata all'API del provider LLM, così gli agenti non possono recuperare suggerimenti o la correzione upstream durante l'esecuzione.

Funzionalità

Funzionalità	Cosa ti offre
Campionamento ripetuto	Un'esecuzione esegue N iterazioni dello stesso input, così i risultati sono distribuzioni, non aneddoti.
Campagne	Analizza un bug attraverso varianti di patcher e stili di prompt, da un vago "fix this plz" a un advisory completo, e confronta i risultati su una dashboard live.
Valutazione degli esiti	Ogni patch ricade in uno dei cinque scenari, da S1 (correzione pulita) a S5 (non ha corretto il bug e ha introdotto una nuova vulnerabilità).
Validazione incrociata	Le patch vengono rivalutate da altri modelli, e i numeri principali mediano le lenti di auto-validazione e validazione incrociata, così il bias di un singolo giudice non domina.
Rilevamento di imbrogli	Un auditor segnala le iterazioni in cui l'agente ha trovato la correzione upstream invece di risolvere il bug da solo.

FLAWED mette a confronto diretto le CLI Claude, Codex e Gemini con gli stessi input.

Avvio rapido

[!WARNING] FLAWED monta il socket Docker (equivalente a root sull'host) ed esegue codice di terze parti non attendibile all'interno dei suoi container di fase. Eseguilo su una macchina di cui ti fidi per sopportare quel carico di lavoro. Vedi docs/security-model.md.

Ti serve Docker, con il socket del daemon accessibile.

# 1. Configure. Writes .env for you (data dir + provider API keys)
./setup.sh

# 2. Bring up the stack (Postgres, API + worker, web UI, notebook)
docker compose up --build

# 3. Open http://127.0.0.1:8080

Poi fai la tua prima esecuzione.

Importa una bug spec. Le spec di esempio sono incluse in bugs/. Trascinane una nella pagina Bug Specs della web UI, oppure usa la CLI.
```
./scripts/import-all-bugs.sh
```
Avvia un'esecuzione dalla web UI. Scegli la spec, un agente + modello, una variante e un numero di iterazioni. La pagina dell'esecuzione trasmette il progresso in tempo reale.

[!NOTE] La prima esecuzione contro un upstream di grandi dimensioni (ad es. Chromium) è lenta. La fase di validate clona l'intero repo una volta per fare il diff con la vera patch upstream. Il clone viene memorizzato in cache e riutilizzato in seguito.

Configurazione di sviluppo sull'host (senza compose)

Ti servono Docker, Node 20+, pnpm, uv e @devcontainers/cli (npm i -g @devcontainers/cli). Gli utenti Nix possono usare nix-shell per tutto tranne Docker.

make dev                        # uv sync + web deps
docker compose up -d postgres   # FLAWED needs a Postgres to talk to
cp .env.example .env            # points FLAWED_DB_URL at it
uv run flawed init              # builds base images, creates the schema
uv run flawed serve             # API + worker + webapp on port 8080

Per il ciclo di sviluppo web, esegui make web-dev in un secondo terminale. Serve la UI sulla porta 5173 e fa da proxy per /api verso flawed serve.

Un devcontainer isolato per eseguire agenti di coding AI su questo repo in modo sicuro è documentato in .devcontainer/README.md.

Bug specs

Una bug spec è l'unità di input. Contiene un repo, un commit vulnerabile, una descrizione del bug, un reproducer opzionale e un insieme di varianti di prompt che modellano come il bug potrebbe essere realisticamente segnalato (riscontro SAST, report di bug bounty, advisory in embargo, PoC grezzo, …). Le spec sono versionate e immutabili, così il prompt e il verdetto di un'esecuzione storica non cambiano mai silenziosamente.

Il contratto JSON si trova in bugs.schema.json ed è documentato in docs/bug-specs.md. Tutte le spec incluse descrivono vulnerabilità divulgate pubblicamente e corrette upstream.

Archiviazione

Postgres è l'unica fonte di verità. I metadati delle esecuzioni e i byte degli artefatti (patch, verdetti, trascrizioni, log) risiedono nel database, così un deployment è completamente catturato dal suo DB. La directory data/ è scratch transitorio che le fasi montano a runtime.

Esegui il backup / ripristino di un intero deployment con scripts/export_dataset.py e scripts/import_dataset.py (disponibili anche dalla web UI).
Ricostruisci un albero di artefatti su disco per l'ispezione offline con scripts/export_artifacts.py.
Le modifiche allo schema sono gestite con Alembic (uv run alembic upgrade head viene eseguito automaticamente all'avvio).

Dataset

Pubblichiamo dataset pre-costruiti così puoi caricare campagne completate invece di eseguire tutto da solo. Ogni dataset è un .tar.gz di un singolo snapshot completo, ospitato su https://flawed.s3.us-east-1.amazonaws.com.

Tutte le campagne in un unico bundle.

Bundle	Archivio
Tutte le campagne	`full.tar.gz`

Archivi per campagna, uno per modello patcher (13)

Più Popolari

FLAWED