OpenAnt: descubrimiento de vulnerabilidades con LLM en ciclo cerrado

¿Qué es esto?

OpenAnt es un sistema de código abierto para el descubrimiento de vulnerabilidades creado por Knostic (Nahum Korda y Gadi Evron). Combina el análisis estático de programas con el razonamiento de un gran modelo de lenguaje (LLM) y luego valida cada hallazgo mediante un paso adversarial automatizado y la ejecución de un exploit en un entorno aislado. El artículo asociado, «OpenAnt: LLM-Powered Vulnerability Discovery Through Code Decomposition, Adversarial Verification, and Dynamic Testing» (arXiv:2606.19149), se prepublicó por primera vez el 11 de marzo de 2026 y se hizo público el 17 de junio de 2026. La herramienta se distribuye bajo licencia Apache 2.0.

El punto no es un ataque nuevo. Es una demostración medida: el coste de encontrar fallos realmente explotables a escala de un repositorio completo está cayendo rápido, y es la verificación rigurosa —no la salida en bruto del modelo— lo que hace fiables los resultados.

Cómo funciona

OpenAnt ejecuta una cadena de seis etapas que reduce el espacio de búsqueda antes de gastar un solo token y luego aumenta el escrutinio sobre lo que queda.

1. Análisis del código. Las funciones se extraen mediante AST específicos de cada lenguaje y se enlazan en un grafo de llamadas bidireccional (Python, JavaScript/TypeScript, Go, C/C++, Ruby, PHP). Sin coste de LLM.
2. Filtrado por alcanzabilidad. Solo se conservan las funciones alcanzables desde un punto de entrada externo (manejadores HTTP, parsers de CLI, manejadores WebSocket, lectores de archivos). Esta etapa por sí sola eliminó cerca del 97 % del código en los proyectos grandes. Sin coste de LLM.
3. Clasificación de exposición. Un agente Claude Sonnet 4 rastrea llamadores y flujos de datos para etiquetar cada unidad como explotable, vulnerable-interna, control de seguridad o neutral.
4. Detección de vulnerabilidades. Claude Opus 4 razona sobre cada unidad expuesta: qué hace el código, de dónde procede la entrada y qué riesgo conlleva.
5. Verificación adversarial. Este es el elemento diferenciador. En lugar de preguntar al modelo «¿puedes explotar esto?» —pregunta a la que un modelo complaciente casi siempre responde que sí—, OpenAnt impone un persona de atacante restringido: acceso solo por navegador, sin privilegios del lado servidor, sin credenciales de administrador, sin acceso a archivos locales. Cada paso de explotación debe trazarse de forma explícita, y un hallazgo válido debe dañar a un tercero, no al propio atacante. Aproximadamente la mitad de los hallazgos señalados se eliminaron aquí por ser impracticables.
6. Verificación dinámica. Para los supervivientes, el sistema genera un Dockerfile y un script de prueba, ejecuta el exploit en un contenedor aislado (sistema de archivos de solo lectura, límites de memoria y CPU, tiempo máximo de 120 segundos) y después descarta cada artefacto. El contenedor debe informar CONFIRMED, NOT_REPRODUCED, BLOCKED, INCONCLUSIVE o ERROR.

En ocho proyectos reales (OpenSSL, Flowise, n8n, WordPress, Rails, paperless-ngx, eShopOnWeb, object-browser) que suman 64.132 funciones, el filtrado redujo el conjunto a 2.281 unidades alcanzables y luego a 586 unidades explotables desde el exterior. La detección señaló 376, la verificación adversarial confirmó 190 y la prueba dinámica reprodujo 144 de forma independiente —una tasa de reproducción del 75,8 %— abarcando más de 30 clases de vulnerabilidades, entre ellas IDOR/falta de autorización, mass assignment, SSRF, path traversal e inyecciones.

Por qué importa

Dos cifras resumen el caso. Primero, la ejecución completa costó unos 1.461 $; sin el filtrado por alcanzabilidad, el mismo análisis habría costado cerca de 23.700 $, así que un encuadre disciplinado hizo viable económicamente el análisis con LLM a escala de repositorio. Segundo, tres cuartas partes de los hallazgos confirmados venían con una prueba de concepto funcional generada automáticamente, no con una mera advertencia de «esto parece arriesgado».

Esa combinación importa porque el análisis estático clásico (SAST) ahoga a los equipos en falsos positivos: los estudios empíricos reportan tasas que van de unos pocos puntos porcentuales a más del 40 %, y por ello solo alrededor del 20 % de los desarrolladores usa SAST de forma activa. El ciclo cerrado de OpenAnt ataca justo ese problema: el persona adversarial y la ejecución dinámica descartan hallazgos teóricos que ningún atacante remoto puede alcanzar. La herramienta se suma a esfuerzos del sector como Big Sleep (Google), Aardvark (OpenAI) y Claude Code Security (Anthropic).

El reverso defensivo es inevitable: la misma economía que permite a un mantenedor escanear su propio código permite a un atacante escanearlo también. Cuando los fallos verificados y explotables se producen por el precio de unas pocas llamadas a una API, la ventana entre la divulgación pública y la explotación real sigue estrechándose.

Defensas

Para mantenedores y equipos de seguridad, las conclusiones prácticas son concretas:

• Use primero las herramientas de ciclo cerrado en sus propios repositorios. OpenAnt es gratuito y defensivo por diseño; Knostic también ofrece análisis sin coste para proyectos de código abierto. Ejecutarlo sobre código de su propiedad —y solo ese— vuelve la asimetría a favor de los defensores.
• Nunca confíe en un veredicto «vulnerable» en bruto de un LLM. Los modelos complacientes confirman casi cualquier cosa. Exija una traza de atacante restringido y, idealmente, un exploit reproducido antes de tratar un hallazgo como real.
• Priorice los puntos de entrada alcanzables desde el exterior. El filtrado por alcanzabilidad refleja cómo razonan los atacantes; fortalezca los manejadores HTTP, los parsers de CLI y los lectores de archivos antes que las utilidades internas.
• Acorte su cadencia de parches. Asuma que los fallos verificados contra bugs divulgados pueden aparecer en horas. Combine esto con divulgación coordinada cuando encuentre problemas en código ajeno.
• Conserve métodos complementarios. OpenAnt apunta a fallos de entrada-a-sink (inyección, SSRF, path traversal, evasión de autorización, XSS). Es más débil con bugs de lógica, condiciones de carrera, clases de seguridad de memoria y violaciones de protocolo: mantenga el fuzzing y, para componentes críticos, los métodos formales.

Estado

Elemento	Detalle
Artículo	arXiv:2606.19149, público el 17 de junio de 2026 (primera prepublicación el 11 de marzo de 2026)
Código	github.com/knostic/OpenAnt, Apache 2.0
Modelos de evaluación	Claude Sonnet 4 (etapas 3, 6) y Claude Opus 4 (etapas 4, 5)
Alcance	Fallos impulsados por la entrada, 6 lenguajes; no bugs de lógica/carrera/memoria
Madurez	Publicado como investigación, varias funciones en beta

Los autores señalan que OpenAnt aporta evidencia empírica de explotabilidad, no una prueba formal, y que la ausencia de un exploit reproducido no demuestra que una vulnerabilidad sea imposible.