Antonio Morales, investigador del GitHub Security Lab, publicó el 24 de septiembre un pipeline de fuzzing guiado por un modelo de lenguaje grande, orientado a proyectos C/C++. El código está en el repositorio de GitHub seclab-taskflows-fuzzing, y el modelo por defecto es Claude Sonnet 5.
El sistema está construido sobre Taskflow Agent, el framework propio de GitHub, que la documentación oficial describe como "un framework para escribir automatización de seguridad impulsada por LLM". El usuario abre un Codespace dentro del repositorio, ejecuta una línea de comando seguida del nombre del proyecto objetivo, por ejemplo tukaani-project/xz, y el resto queda a cargo del agente.
De encontrar el punto de entrada a emitir el informe
Según la descripción, el pipeline realiza estos pasos en orden: identificar los puntos de entrada del código, escribir automáticamente un harness de prueba, invocar AFL++ para ejecutar el fuzzing, leer el informe de cobertura, reescribir el harness según la cobertura alcanzada, clasificar cada fallo (crash) uno por uno y, finalmente, generar un informe de vulnerabilidad con una sugerencia de parche en formato diff unificado.
La retroalimentación de cobertura usa un esquema de presupuesto de tiempo que se duplica en cada ronda: empieza en 30 segundos y continúa con 60, 120, 240, 480 y 960 segundos, unos 32 minutos acumulados por objetivo. Tras cada ronda, el agente revisa la cobertura antes de decidir qué modificar a continuación.
Para que la mutación aleatoria entienda mejor el formato de entrada, el pipeline superpone cuatro capas "conscientes de la estructura": diccionarios y mutadores propios para cada formato de archivo, diccionarios extraídos del propio código fuente, diccionarios de AFL generados dinámicamente durante la ejecución, y la técnica de empalme de corpus (splicing).
La clasificación de fallos es bastante detallada: vulnerabilidad real (vulnerability), recomendación de refuerzo de biblioteca (library_hardening), error del propio harness (harness_bug), agotamiento de memoria, tiempo de espera agotado, fallo de assert y duplicado. Los fallos pasan primero por la minimización con afl-tmin y luego se deduplican según el stack trace. Durante la ejecución hay además un panel HTML en el puerto 8765 para seguir el progreso en tiempo real.
Morales plantea un principio de división del trabajo bastante claro para este diseño:
"the LLM agent owns the decisions, and the MCP tools own the execution"
(Las decisiones corresponden al agente LLM; la ejecución, a las herramientas MCP.)
En comparación con la línea de OSS-Fuzz
Meter LLMs dentro del fuzzing es algo que Google empezó antes. Desde 2023, OSS-Fuzz ya prueba el uso de LLMs para generar automáticamente fuzz targets, y a finales de 2024 Google afirmó públicamente que ese enfoque había ayudado a encontrar varios problemas, incluida una vulnerabilidad en OpenSSL. Aquella solución resuelve sobre todo el paso de "escribir el harness"; el propio proyecto debe estar previamente integrado en la infraestructura de OSS-Fuzz.
El enfoque de GitHub esta vez se parece más a una caja de herramientas portátil: no exige que el proyecto se integre a ninguna plataforma, basta con abrir un entorno de desarrollo en la nube para ejecutarlo, y la triaje y la redacción del informe ya vienen incluidos. Justo al principio, el artículo advierte que el fuzzing continuo no es una solución mágica: proyectos que llevan años en OSS-Fuzz todavía pueden esconder errores graves, y ese es también el trasfondo de por qué eligieron xz como demostración. xz sufrió en 2024 un incidente de puerta trasera que sacudió a toda la comunidad de código abierto, pero aquello fue un ataque de envenenamiento deliberado, una categoría distinta de los errores de memoria que el fuzzing puede detectar.
Lo que el artículo no cuenta
Algunas de las cifras que más interesan a quienes observan desde fuera no se han hecho públicas: cuántos fallos se encontraron en xz y cJSON, cuántos de ellos se consideraron vulnerabilidades reales, si se asignó algún CVE; el consumo de tokens y el costo de ejecutar un proyecto por completo; la tasa de falsos positivos. El propio autor emplea un tono bastante mesurado: escribe que las conclusiones del triaje deben verse como "un punto de partida bien preparado para entregar a una persona", no como el resultado final, y que las sugerencias de parche también están todas marcadas como pendientes de revisión humana.
En cuanto a la seguridad, hay otra advertencia. El pipeline no hace aislamiento en contenedores mientras se ejecuta; la recomendación oficial es correrlo solo en Codespaces o en máquinas virtuales temporales, es decir, entornos desechables, y no concederle privilegios elevados. Para los equipos que piensan desplegarlo directamente en la red interna de la empresa, esa barrera aparece antes incluso que la elección del modelo.
Para los mantenedores de bibliotecas de código abierto en China, la principal barrera está en el modelo: la configuración por defecto llama a un modelo de Anthropic, y la conexión directa desde China no es cómoda. El repositorio es abierto, así que en teoría se podría cambiar por otro modelo compatible, pero si el rendimiento se mantiene o no, por ahora no hay pruebas públicas al respecto.
Fuentes: blog oficial de GitHub, descripción en el repositorio de código abierto seclab-taskflows-fuzzing, CocoLoop, materiales públicos sobre OSS-Fuzz de Google; los pasos del pipeline, el presupuesto de tiempo y la clasificación de fallos siguen la descripción del blog de GitHub.