GitHub Security Lab publica un pipeline de fuzzing autónomo para C y C++
El Fuzzing Taskflow apunta a un repositorio, escribe sus propios harness, lanza AFL++, lee la cobertura y triajea los fallos sin intervención humana. Corre comandos en el host, así que pide una máquina desechable.
GitHub Security Lab ha publicado un pipeline de fuzzing autónomo para proyectos en C y C++. Se apunta a un repositorio y el agente hace el resto: localiza los puntos de entrada, analiza el sistema de compilación, escribe los harness, lanza AFL++, lee los informes de cobertura, mejora esos harness, triajea cada crash y redacta un informe de vulnerabilidad por cada bug único. Todo sin nadie detrás. Se llama Fuzzing Taskflow y va montado sobre el Taskflow Agent del propio laboratorio, su framework para escribir automatizaciones de seguridad movidas por LLM.
El punto de partida es poco glamuroso: ni los proyectos que llevan años dentro de OSS-Fuzz están limpios. La razón casi siempre es la misma, alguien tiene que vigilar la cobertura, escribir harness para el código al que no llega nadie y triajear lo que sale por el otro extremo. El autor se preguntó cuánto de ese trabajo humano se puede soltar a un agente, y de ahí salió el pipeline.
Cómo se ejecuta
Lo más simple es abrir el repositorio, arrancar un Codespace y lanzar ./scripts/fuzzing/run_fuzzing.sh con un slug owner/repo como argumento. Por ejemplo, tukaani-project/xz. El agente instala entonces lo que necesita, como AFL, clona el repositorio, identifica las funciones relevantes y crea los fuzz targets. Para una prueba rápida antes de comprometerse con una campaña larga, el autor sugiere apuntarlo a algo pequeño tipo DaveGamble/cJSON.
Aviso que da el propio laboratorio: el taskflow ejecuta afl-fuzz, clang y comandos de compilación elegidos por el LLM directamente sobre el host, sin contenedor de por medio. Un agente víctima de una inyección de prompt podría, en principio, hacer cualquier cosa que pueda hacer el usuario. De ahí la recomendación de correrlo solo en un entorno desechable, un Codespace o una máquina virtual que se tire después, y sin privilegios elevados.
Por defecto usa Claude Sonnet 5 porque pasó las pruebas internas sin problemas; se cambia editando src/seclab_taskflows_fuzzing/configs/model_config.yaml.
Tres capas y una regla
La arquitectura separa un driver de shell que encadena las etapas, un conjunto de YAML de taskflow que hacen de prompts para cada paso, y un conjunto de herramientas MCP que el agente invoca para ejecutar de verdad. La regla de diseño que el autor destaca: el agente toma las decisiones, las herramientas ejecutan. El agente nunca llama a AFL o a clang por su cuenta, compone el pipeline con esas piezas. Todo el estado vive en una base de datos SQLite, fuzz_context.db, así que las etapas no se pasan datos en memoria.
Cada harness se compila dos veces. Una con afl-clang-lto -fsanitize=address,undefined, que da el binario para fuzzear, y otra con clang -fprofile-instr-generate -fcoverage-mapping, que reproduce después la cola de AFL para sacar cobertura real por línea y rama.
El bucle de cobertura es el corazón del invento. En cada iteración, el agente ejecuta AFL durante un presupuesto de tiempo, reproduce la cola contra el binario de cobertura y lee la lista de ramas sin cubrir. Según lo que ve, añade una semilla para alcanzar esa rama, edita el harness para llamar a otra API, enriquece el diccionario de AFL con las constantes que compara un guard, o directamente pasa de largo si es una ruta de error fría o código de terceros. Los presupuestos se duplican en cada vuelta: 30s, 60s, 120s, 240s, 480s y 960s, unos 32 minutos por objetivo.
La propuesta no resuelve el fuzzing, lo que hace es quitar de en medio la parte repetitiva. Para quien mantiene una biblioteca en C o C++ y nunca encuentra tiempo para escribir harness, la pregunta interesante es cuánto aguanta esto antes de que el agente empiece a dar vueltas sobre el mismo hueco. El repositorio está abierto, así que la respuesta se puede medir en casa.
