GitHub Security Lab presentó una explicación de un proyecto de código abierto llamado Fuzzing Taskflow, diseñado para automatizar grandes partes de las pruebas de proyectos C/C++ mediante fuzzing y agentes de modelos lingüísticos. Cuando se dirige a un repositorio de GitHub, el flujo puede analizar el sistema de compilación, identificar puntos de entrada adecuados, crear herramientas fuzz harnesses, ejecutar AFL++, leer informes de cobertura, mejorar las herramientas, clasificar los fallos y preparar un informe separado para cada posible problema.
El proyecto está construido sobre el marco GitHub Security Lab Taskflow Agent, que expresa el flujo de trabajo como un conjunto de recorridos ejecutados por el agente de principio a fin. El autor del artículo, Antonio Morales, señala que el objetivo no es eliminar el papel del investigador, sino trasladar al agente las tareas repetitivas que consumen mucho tiempo, manteniendo las decisiones y la ejecución en dos capas separadas.
¿Cómo funciona el flujo?
El uso comienza en el repositorio del proyecto, ejecutando, por ejemplo, el comando ./scripts/fuzzing/run_fuzzing.sh PROJECT dentro de Codespace. El flujo se encarga de instalar las herramientas, clonar el repositorio y analizar las funciones importantes; después crea objetivos de fuzzing y ejecuta campañas contra ellos. Su estructura consta de un ejecutor de shell, archivos YAML que describen las etapas de trabajo y las instrucciones dirigidas al modelo, y herramientas MCP que realizan operaciones como ejecutar AFL, compilar las herramientas, leer la cobertura y almacenar los fallos.
El agente no invoca AFL ni clang directamente; decide qué debe probarse y qué brecha de cobertura merece seguimiento, mientras las herramientas MCP ejecutan las operaciones de bajo nivel. El estado se almacena en una base de datos SQLite llamada fuzz_context.db, lo que permite transferir los resultados entre las etapas sin depender de la memoria compartida.
Bucle de mejora de la cobertura
Cada harness se compila dos veces: una versión .afl para dirigir AFL utilizando las herramientas de instrumentación adecuadas, y una versión .cov para volver a ejecutar la lista de entradas y medir la cobertura de líneas y ramas. Después de cada ronda, el agente revisa las ramas no cubiertas y elige una acción, como añadir un nuevo seed, modificar el código fuente del harness para invocar otra interfaz, enriquecer el diccionario de AFL con los valores que comprueba el código o ignorar una ruta fría cuyo coste no lo justifica.
El presupuesto de tiempo se duplica de 30 a 60, 120, 240, 480 y 960 segundos, es decir, aproximadamente 32 minutos por objetivo en el máximo mencionado. El flujo se detiene al detectar una disminución del rendimiento: si dos rondas consecutivas logran menos de un punto porcentual de cobertura de líneas, según el valor predeterminado configurable, pasa a otro objetivo.
Gestión de entradas y fallos
El flujo admite mecanismos personalizados para formatos JSON y XML, expresiones regulares, PNG y TLV binario con longitudes incorporadas, y también puede generar un diccionario a partir de las constantes de cadenas y números presentes en archivos C y H. Asimismo, enriquece este diccionario después de cada paso de cobertura basándose en las comprobaciones cercanas a las líneas no cubiertas. Además, cada harness conserva una carpeta corpus fija y utiliza afl-cmin para limitar su tamaño, manteniendo las entradas útiles entre rondas y campañas.
Después de finalizar la campaña, los fallos se minimizan mediante afl-tmin, se vuelven a ejecutar con AddressSanitizer y, posteriormente, se eliminan los duplicados basándose en la huella de la parte superior de la pila. El flujo también vuelve a probar los fallos conocidos para verificar el efecto de las correcciones y clasifica los resultados en categorías que incluyen: vulnerabilidad, endurecimiento de la biblioteca, error en el harness, agotamiento de memoria, tiempo de espera, fallo de assertion o duplicado.
¿Por qué importa esta noticia?
El valor práctico reside en que el flujo intenta automatizar el bucle que suele limitar la eficacia del fuzzing continuo: escribir harnesses, leer la cobertura, elegir la siguiente brecha y clasificar los fallos. Esto podría reducir el coste inicial de probar un proyecto que no se haya sometido anteriormente a fuzzing o ayudar a ampliar la cobertura de un proyecto existente.
Sin embargo, GitHub Security Lab establece una restricción fundamental: el flujo ejecuta afl-fuzz, clang y comandos de compilación elegidos directamente por el modelo en el sistema anfitrión, sin un contenedor intermedio. Por ello, un agente afectado por una inyección de instrucciones podría ejecutar aquello que el usuario tenga permitido ejecutar. El proyecto recomienda ejecutarlo dentro de un entorno desechable, como Codespace o una máquina virtual temporal, y sin privilegios elevados.
Además, los informes de vulnerabilidades y los parches propuestos no son resultados finales. El artículo confirma que el análisis del modelo puede equivocarse y que el parche propuesto está marcado como pendiente de revisión. De este modo, Fuzzing Taskflow representa un punto de partida bien preparado para el investigador, no un sustituto de la verificación humana de la accesibilidad, la explotabilidad y la causa raíz.