La integración de Large Language Models (LLMs) en pipelines de seguridad para el descubrimiento de vulnerabilidades representa una evolución significativa en la automatización de la ciberseguridad. Sin embargo, la aplicación directa de LLMs genéricos a repositorios de código extensos resulta ineficiente debido a limitaciones inherentes como la ventana de contexto y la tendencia a generar ruido. Este problema fundamental de la computación, la gestión de la complejidad y el escalado de tareas cognitivas, se aborda mediante la orquestación de múltiples agentes especializados dentro de un 'harness' o marco de trabajo. Este enfoque permite descomponer el problema de la búsqueda de vulnerabilidades en tareas más pequeñas y manejables, mejorando la precisión y la cobertura.
La relevancia de este enfoque se acentúa con la aparición de LLMs de 'frontera' como Mythos Preview, que demuestran capacidades avanzadas en la construcción de cadenas de explotación y la generación de pruebas de concepto (PoC) funcionales. Estas capacidades transforman la detección de vulnerabilidades de una tarea de identificación aislada a una de validación activa, cerrando la brecha entre una 'sospecha' y una 'vulnerabilidad confirmada'. La necesidad de un 'harness' surge para capitalizar estas nuevas capacidades, superando las limitaciones de los modelos individuales y permitiendo su uso a escala en entornos de producción.
Históricamente, la seguridad del software ha dependido de herramientas estáticas (SAST) y dinámicas (DAST), así como de la revisión manual por expertos. Los LLMs ofrecen una nueva dimensión al poder razonar sobre el código y su contexto de una manera más holística, similar a un investigador humano. Sin embargo, sin una arquitectura de orquestación adecuada, su potencial se ve limitado por los mismos desafíos de escalabilidad y gestión de la información que enfrentan otros sistemas distribuidos complejos.
Arquitectura del Sistema
La arquitectura central para el descubrimiento de vulnerabilidades con LLMs se basa en un 'harness' que orquesta múltiples agentes especializados en un pipeline secuencial. Este harness está diseñado para superar las limitaciones de contexto y throughput de los LLMs individuales, permitiendo un análisis profundo y escalable. Los componentes clave y su interacción son:
1. Recon Agent: Inicia el proceso leyendo el repositorio de código, identificando subsistemas, límites de confianza, puntos de entrada y superficies de ataque. Genera un documento de arquitectura y una cola inicial de tareas para la siguiente etapa. Este componente es crucial para establecer un contexto compartido y evitar la 'deriva' del modelo.
2. Hunt Agents: Son los agentes principales que buscan vulnerabilidades. Operan concurrentemente (ej. cincuenta a la vez), cada uno asignado a una clase de ataque específica y un alcance definido. Utilizan subagentes de exploración y tienen acceso a un entorno 'scratch' por tarea para compilar y ejecutar código de prueba de concepto (PoC). Este diseño de 'muchas tareas estrechas en paralelo' es fundamental para la cobertura y el throughput.
3. Validate Agent: Un agente independiente que re-lee el código y el hallazgo del 'Hunt Agent' para intentar refutarlo. Utiliza un 'prompt' diferente y no puede generar nuevos hallazgos, actuando como un revisor adversarial para reducir el ruido y los falsos positivos.
4. Gapfill Agent: Identifica áreas que los 'Hunt Agents' tocaron pero no cubrieron exhaustivamente y las re-encola para una nueva pasada. Esto contrarresta la tendencia del modelo a enfocarse en clases de ataque donde ya ha tenido éxito.
5. Dedupe Component: Consolida hallazgos que comparten la misma causa raíz en un único registro, evitando la inflación de la cola con duplicados.
6. Trace Agent: Para hallazgos confirmados en bibliotecas compartidas, este agente se expande (una instancia por repositorio consumidor) utilizando un índice de símbolos inter-repositorio para determinar si la entrada controlada por el atacante realmente alcanza la vulnerabilidad desde fuera del sistema. Este es un paso crítico para transformar un 'defecto' en una 'vulnerabilidad alcanzable'.
7. Feedback Loop: Las trazas alcanzables se convierten en nuevas tareas de 'hunt' en los repositorios consumidores, cerrando el ciclo y mejorando el pipeline con cada ejecución.
8. Report Agent: Genera un informe estructurado de los hallazgos confirmados, validando contra un esquema predefinido y enviando el informe a una API de ingesta. Esto asegura que la salida sea datos consultables, no prosa de formato libre.
La interacción entre estos componentes se basa en la descomposición de problemas complejos en tareas más pequeñas y la aplicación de principios de sistemas distribuidos como la concurrencia, la validación cruzada y la retroalimentación. La capacidad de los 'Hunt Agents' para generar y ejecutar PoCs en un entorno aislado es una característica clave que eleva la calidad de los hallazgos, pasando de la especulación a la prueba empírica.
Flujo de Descubrimiento de Vulnerabilidades con Harness
- 1 Recon Agente lee repo, mapea arquitectura, genera tareas iniciales.
- 2 Hunt Múltiples agentes concurrentes buscan vulnerabilidades por clase/alcance, gen...
- 3 Validate Agente independiente intenta refutar hallazgos para reducir ruido.
- 4 Gapfill Re-encola áreas no cubiertas exhaustivamente por 'Hunt Agents'.
- 5 Dedupe Consolida hallazgos con la misma causa raíz.
- 6 Trace Determina si la vulnerabilidad es alcanzable desde fuera del sistema.
- 7 Feedback Vulnerabilidades alcanzables generan nuevas tareas en repositorios consumidores.
- 8 Report Genera informe estructurado y lo envía a API de ingesta.
| Capa | Tecnología | Justificación |
|---|---|---|
| compute | Anthropic Mythos Preview (LLM) | Motor principal para la identificación de vulnerabilidades, construcción de cadenas de explotación y generación de PoCs. vs Otros modelos de frontera (ej. GPT-5.5, Opus 4.7) Modelo sin salvaguardas adicionales para investigación controlada (Project Glasswing). |
| orchestration | Custom Harness (Agentes y Pipeline) | Coordina la ejecución de múltiples agentes LLM, gestiona el flujo de trabajo, el contexto y la validación de hallazgos. vs Uso directo de LLMs genéricos como agentes de codificación Diseñado para tareas estrechas y paralelas, con validación adversarial y bucles de retroalimentación. |
| security | Entorno 'scratch' por tarea | Proporciona un sandbox aislado para compilar y ejecutar PoCs generados por los LLMs, verificando la explotabilidad de las vulnerabilidades. |
| data-processing | Cross-repo symbol index | Utilizado por el 'Trace Agent' para mapear el flujo de datos y determinar la alcanzabilidad de las vulnerabilidades a través de múltiples repositorios. |
Trade-offs
Ganancias
- ▲ Calidad de los hallazgos (menos ruido, PoCs funcionales)
- ▲ Cobertura de análisis en grandes bases de código
- ▲▲ Automatización de la construcción de cadenas de explotación
Costes
- ▲ Complejidad de la arquitectura del sistema (harness)
- ▲ Costos computacionales (tokens, infraestructura para múltiples agentes)
- △ Gestión de la inconsistencia en las respuestas del LLM
Fundamentos Teóricos
El problema de la detección de vulnerabilidades y la verificación de software tiene profundas raíces en la ciencia de la computación. Conceptos como la verificación formal, el análisis estático de programas y el análisis dinámico han sido objeto de investigación durante décadas. El trabajo de Tony Hoare en la lógica de Hoare (1969) sentó las bases para la verificación de la corrección de programas, mientras que los avances en el análisis de flujo de datos y el análisis de puntos-a-puntos (pointer analysis) han sido fundamentales para las herramientas SAST modernas.
La capacidad de los LLMs para construir cadenas de explotación y generar PoCs se relaciona con el campo de la síntesis de programas y la programación por ejemplo, donde el sistema infiere un programa a partir de especificaciones o ejemplos. Aunque los LLMs no realizan una síntesis formal en el sentido tradicional, su capacidad de 'razonamiento' y 'generación de código' para explotar vulnerabilidades se alinea con la búsqueda de automatizar tareas que históricamente requerían inteligencia humana. La inconsistencia en las 'negaciones' del modelo y la necesidad de un 'harness' para guiarlo resuenan con los desafíos de la 'alineación de IA' y el control de sistemas autónomos, un área activa de investigación en IA y seguridad.