Pipeline LLM OpenAnt Identifica 28 Vulnerabilidades Explotables en OpenSSL

Knostic lanzó OpenAnt esta semana — un pipeline LLM de código abierto de seis etapas que escanea bases de código a escala de repositorio en busca de vulnerabilidades explotables y valida cada hallazgo con un exploit en vivo en un contenedor aislado antes de presentarlo. En OpenSSL, el sistema redujo 15.232 funciones analizadas en 1.769 archivos a 49 candidatos para análisis LLM, luego marcó 28 de esos 49 como potencialmente vulnerables. El artículo y las herramientas se lanzaron juntos el 17 de junio bajo la licencia Apache 2.0.

Las dos primeras etapas no cuestan nada. La Etapa 1 analiza cada función y construye un gráfico de llamadas. La Etapa 2 ejecuta el recorrido de gráficos desde puntos de entrada externos — controladores CLI, callbacks, funciones main — y descarta cualquier código inaccesible desde entrada controlada por el atacante. En OpenSSL, ese filtro por sí solo reduce la superficie de análisis en 97%, de 15.232 unidades a 390. Ningún LLM se invoca hasta la Etapa 3.

La Etapa 3 es donde comienzan los costos. Un agente Sonnet 4 itera sobre cada unidad alcanzable, clasificándola por nivel de exposición: expuesta externamente, expuesta internamente, control de seguridad o neutral. El bucle se ejecuta hasta que la clasificación es confiable o alcanza un límite de 20 iteraciones. El costo se escala con la complejidad de la función. Una utilidad simple termina en aproximadamente una iteración a $0,13; una cadena de llamadas profunda puede alcanzar el límite a $10,92 por unidad. En OpenSSL, la mediana fue de 9 iteraciones por unidad. Después de la Etapa 3, las 390 unidades alcanzables se colapsan a 49 expuestas externamente — una reducción del 99,6% del recuento de funciones original.

La Etapa 4 entrega esas 49 unidades a Claude Opus 4.6, que analiza cada una en busca de patrones de vulnerabilidad. Marcó 28. La Etapa 5 es el verificador adversarial, donde la arquitectura diverge de la mayoría de las herramientas de seguridad basadas en LLM. Una persona atacante restringida evalúa si cada candidato marcado es realmente explotable bajo condiciones realistas: sin acceso asumido al servidor, sin credenciales de base de datos, sin lecturas de archivos locales, sin comandos CLI. El modelo debe rastrear una ruta de explotación paso a paso. Si la única ruta de ataque viable requiere acceso al shell local, el hallazgo se clasifica como NO EXPLOTABLE y se descarta. Los prompts sin restricciones "actúa como un atacante" son la causa raíz de altas tasas de falsos positivos en escáneres basados en LLM — los modelos son complacientes por defecto y construyen ataques plausibles que asumen capacidades de atacante que no existen en producción.

La Etapa 6 convierte candidatos sobrevivientes en entornos de explotación reales, los ejecuta en contenedores aislados de corta duración y desmonta el entorno después. Solo los hallazgos que sobreviven a la ejecución llegan al informe final. Knostic está actualmente en el proceso de divulgación de vulnerabilidad para hallazgos que el sistema produjo contra OpenSSL, WordPress y Flowise.

La configuración de modelo predeterminada utiliza Claude Opus 4.6 para revisión de accesibilidad, análisis y verificación adversarial, y Sonnet 4 para contexto más ligero, mejora y fases de informe. La configuración es un archivo JSON con todas las fases del pipeline asignables independientemente a cualquier par proveedor-modelo. Los adaptadores de Anthropic, OpenAI y Google se envían listos para usar. Cualquier endpoint proxy compatible con OpenAI o Anthropic — OpenRouter, vLLM, Bedrock, puertas de enlace internas — funciona a través de base_url personalizada. Agregar un nuevo adaptador requiere un archivo Python que implemente el protocolo LLMAdapter más algunos puntos de contacto Go para el asistente CLI; 12 pruebas de contrato se ejecutan automáticamente. La compatibilidad de idiomas es estable para Go, Python y JavaScript/TypeScript; C/C++, PHP y Ruby están en beta.

La restricción práctica para adoptar esto es la curva de costo de la Etapa 3. Con 9 iteraciones medianas y $0,13 por iteración, un proyecto que produce 390 unidades alcanzables gasta aproximadamente $450 solo en clasificación de exposición antes de que se ejecute ningún análisis de vulnerabilidad. Los monorepos más grandes o los idiomas sin analizadores estáticos maduros empujarán esto más alto. El filtro de accesibilidad es la optimización crítica — sin él, el costo por proyecto se vuelve prohibitivo a cualquier escala. Para equipos de seguridad que ya realizan revisión de código manual o pagan por SAST comercial, la economía probablemente se cierre. Para equipos que ejecutan esto ad hoc, el costo por escaneo necesita modelado contra el tamaño del repositorio antes de la implementación.

La apuesta central de la arquitectura: cerrar el bucle entre razonamiento semántico y ejecución de explotación, y definir "vulnerable" como "demostrablemente explotable bajo restricciones realistas de atacante." El número que importa no es cuántos hallazgos produce el escáner — es cuántos sobreviven a la Etapa 5.