
Artefactos tipo Fix con defectos incrustados
Fix Like Artifacts with Embedded Defects
Un arnés de investigación para medir qué tan bien los agentes de IA parchean vulnerabilidades.
Inicio rápido · Conjuntos de datos · Documentación · Modelo de seguridad · Contribuir
FLAWED hace checkout de un proyecto de código abierto en un commit con una vulnerabilidad conocida, le entrega a un agente de IA una descripción del bug y le pide que escriba un parche. El agente nunca ve la corrección real del upstream.
Cada parche se valida, audita y califica en contenedores aislados, para que puedas ver no solo si el modelo corrigió el bug, sino también si introdujo nuevos en el camino.
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]
Cada etapa se ejecuta en su propio contenedor. Solo clone tiene acceso a la
red. Todas las etapas posteriores están restringidas a la API del proveedor de
LLM, para que los agentes no puedan obtener pistas ni la corrección del upstream
a mitad de la ejecución.
| Característica | Qué te aporta |
|---|---|
| Muestreo repetido | Una ejecución realiza N iteraciones de la misma entrada, por lo que los resultados son distribuciones, no anécdotas. |
| Campañas | Recorre un bug a través de variantes de parcheadores y estilos de prompt, desde un vago "arregla esto porfa" hasta un aviso completo, y compara los resultados en un panel en vivo. |
| Calificación de resultados | Cada parche cae en uno de cinco escenarios, desde S1 (corrección limpia) hasta S5 (no corrigió el bug e introdujo una nueva vulnerabilidad). |
| Validación cruzada | Los parches son reevaluados por otros modelos, y las cifras principales promedian las perspectivas de autovalidación y validación cruzada para que el sesgo de un solo juez no domine. |
| Detección de trampas | Un auditor marca las iteraciones en las que el agente encontró la corrección del upstream en lugar de resolver el bug por sí mismo. |
FLAWED enfrenta los CLI de Claude, Codex y Gemini cara a cara con las mismas entradas.
[!WARNING] FLAWED monta el socket de Docker (equivalente a root en el host) y ejecuta código de terceros no confiable dentro de sus contenedores de etapa. Ejecútalo en una máquina en la que confíes para soportar esa carga de trabajo. Consulta
docs/security-model.md.
Necesitas Docker, con el socket del daemon accesible.
# 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
Luego realiza tu primera ejecución.
bugs/. Arrastra una a la página Bug Specs de la
interfaz web, o usa el CLI.
./scripts/import-all-bugs.sh
[!NOTE] La primera ejecución contra un upstream grande (p. ej. Chromium) es lenta. La etapa de validación clona todo el repositorio una vez para compararlo con el parche real del upstream. El clon se almacena en caché y se reutiliza después.
Necesitas Docker, Node 20+, pnpm, uv y
@devcontainers/cli (npm i -g @devcontainers/cli). Los usuarios de Nix pueden
usar nix-shell para todo excepto 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
Para el ciclo de desarrollo web, ejecuta make web-dev en una segunda terminal.
Sirve la interfaz en el puerto 5173 y redirige /api a flawed serve.
Un devcontainer aislado para ejecutar agentes de codificación de IA contra este
repositorio de forma segura está documentado en
.devcontainer/README.md.
Una especificación de bug es la unidad de entrada. Contiene un repositorio, un commit vulnerable, una descripción del bug, un reproductor opcional y un conjunto de variantes de prompt que modelan cómo podría reportarse el bug de forma realista (hallazgo de SAST, informe de bug bounty, aviso embargado, PoC sin procesar, …). Las especificaciones están versionadas y son inmutables, por lo que el prompt y el veredicto de una ejecución histórica nunca cambian silenciosamente.
El contrato JSON está en bugs.schema.json y está
documentado en docs/bug-specs.md. Todas las
especificaciones incluidas describen vulnerabilidades divulgadas públicamente y
corregidas en el upstream.
Postgres es la única fuente de verdad. Los metadatos de las ejecuciones y los
bytes de los artefactos (parches, veredictos, transcripciones, registros) viven
en la base de datos, por lo que un despliegue queda completamente capturado por
su BD. El directorio data/ es un espacio de trabajo transitorio que las etapas
montan en tiempo de ejecución.
scripts/export_dataset.py y scripts/import_dataset.py (también
disponibles desde la interfaz web).scripts/export_artifacts.py.uv run alembic upgrade head se ejecuta automáticamente al iniciar).Publicamos conjuntos de datos preconstruidos para que puedas cargar campañas
completadas en lugar de ejecutar todo tú mismo. Cada conjunto de datos es un
.tar.gz de una instantánea completa, alojado en
https://flawed.s3.us-east-1.amazonaws.com.
Todas las campañas en un solo paquete.
| Paquete | Archivo |
|---|---|
| Todas las campañas | full.tar.gz |