Los modelos de frontera encontraron las vulnerabilidades. Solo el atacante encontró las cadenas.

Los atacantes no leen tu repositorio: acceden a tu URL y encadenan todo lo que encuentran. En una era en la que la IA ofensiva ataca aplicaciones en vivo a velocidad de máquina, tus herramientas de seguridad deben ir más allá de encontrar vulnerabilidades y demostrar que son explotables, incluso si pueden combinarse para provocar una brecha.

Así que hicimos una prueba. Apuntamos Evo Continuous Offensive Security (COS) y Claude Security con Mythos a la misma aplicación: TaintedPort. Es una aplicación web deliberadamente vulnerable que pone a prueba clases de errores del mundo real y un conjunto de cadenas de explotación registradas. Son herramientas de distinto tipo: COS ataca la aplicación en ejecución, mientras que los dos productos de Claude leen el código fuente. Las ejecutamos contra el mismo objetivo para ver qué demuestra cada enfoque.

Evo COS confirmó 10 de 15 cadenas de explotación.

Esto no es una crítica a los modelos: los usamos

Claude Security con Mythos representa un verdadero avance en el descubrimiento de vulnerabilidades impulsado por IA. Analiza el código fuente como lo haría un buen revisor humano y detecta tipos de fallas que las herramientas de búsqueda de patrones no encuentran. Pero encontrar una falla en el código y demostrar que un atacante puede explotar esas vulnerabilidades son tareas distintas.

La ruta de ataque que demostró COS

Todas las herramientas de esta prueba encontraron la vulnerabilidad de falsificación de solicitudes del lado del servidor (SSRF) y que el secreto de firma JWT de la aplicación estaba codificado. Evo COS fue más allá: usó la SSRF para acceder al secreto de firma y recuperarlo de la aplicación en ejecución; luego, usó ese secreto para crear un token de administrador válido y tomar el control de la interfaz de administración. Las dos vulnerabilidades se conectaron en una ruta completa para tomar el control de una cuenta, demostrada en la aplicación en vivo con una prueba de concepto ejecutable.

Arriba: CHAIN-004 según la evaluación de COS. Todas las herramientas de esta prueba reportaron por separado las dos vulnerabilidades que la componen: la SSRF y el secreto codificado. Evo COS confirmó que se combinan para falsificar un token de administrador.

Así es como se ve un ataque autónomo en la práctica: obtener un punto de apoyo y luego encadenar ataques desde ahí. Evo COS te muestra la ruta y adjunta una prueba de concepto ejecutable para cada cadena confirmada.

Los resultados

TaintedPort v1.35 se evaluó frente a una clave de respuestas fija con 57 vulnerabilidades conocidas y 15 cadenas de explotación conocidas, en una escala ponderada por gravedad (Baja 1, Media 3, Alta 9, Crítica 27; cada cadena confirmada recibió una puntuación según su propia gravedad, además de la de sus vulnerabilidades componentes). La detección ponderada se calcula así: puntos encontrados ÷ 938 puntos disponibles: 587 de las 57 vulnerabilidades y 351 de las 15 cadenas.

Claude Security encontró una vulnerabilidad crítica más (10 frente a 9). Evo COS encontró más vulnerabilidades, obtuvo la mayor precisión (96.2% frente a 90.2%) con menos falsos positivos y pudo identificar y demostrar cadenas de explotación.

¿Por qué atacar la aplicación implementada?

Evo COS es un sistema dinámico: su objetivo siempre es una URL en vivo, y el código fuente es un dato de entrada opcional que convierte una ejecución de caja negra en una de caja gris. Nunca trabaja solo con el código. Claude Security se ejecutó en modo de caja blanca (solo código).

Esto hace que sea una comparación entre disciplinas: Evo COS realiza una prueba de penetración ofensiva que sondea y explota la aplicación en ejecución, un proceso mucho más intensivo que una sola revisión del código. Es la misma división complementaria que siempre ha existido en el sector entre DAST y SAST. Aquí mostramos lo que demuestra probar la aplicación en vivo y lo que no se puede demostrar leyendo solo el código: que estas vulnerabilidades son reales y que pueden encadenarse.

Los hallazgos exclusivos de Evo COS son, en su mayoría, comportamientos en tiempo de ejecución: respuestas reflejadas y mal configuradas, falta de protecciones de transporte, tokens que siguen vigentes después de cerrar sesión y una gestión débil de sesiones. Evo COS pudo confirmar varias fallas de lógica de negocio que dependen del contexto: autorización rota a nivel de objeto al actualizar perfiles, escalamiento de privilegios mediante declaraciones JWT falsificadas y una falla crítica en la que una sola lectura de un secreto TOTP almacenado anula la autenticación de dos factores (2FA). Para confirmar las cadenas, hay que llegar a cada paso a través de la aplicación en ejecución y verificar que se pueda alcanzar el siguiente. Un modelo que analiza el código fuente debe inferir que una vulnerabilidad se puede ejecutar y no detecta la cadena.

Puedes crear un entorno de prueba, pero no puedes crear el contexto

El debate sobre las evaluaciones comparativas de este año ha llegado a una conclusión acertada: el sistema que rodea a un modelo importa más que el modelo mismo. Nosotros iríamos más allá. «¿Qué entorno de prueba?» no es una pregunta neutral; ahí es donde reside la verdadera ventaja.

Evo COS coordina varios modelos, incluidos los modelos Claude de vanguardia, y asigna a cada uno el trabajo para el que mejor se adapta. Así que este resultado no es una historia sobre la calidad de los modelos. La misma clase de modelo que impulsa una revisión de código de vanguardia forma parte de Evo COS. Lo que cambia es el sistema que lo rodea: Evo COS parte de lo que la plataforma Snyk ya sabe sobre el objetivo, en lugar de analizarlo sin contexto; es un grupo de agentes, cada uno coordinado para un propósito específico, y cada hallazgo supera un paso de validación independiente antes de aparecer, porque el sistema que genera un hallazgo no debería ser el mismo que lo evalúa.

Cualquiera puede conectar un modelo de vanguardia a un agente de programación esta noche y apuntarlo a un repositorio. Lo que esa configuración no puede reproducir es el contexto acumulado y validado del que parte Evo COS, el validador independiente ni las pruebas contra la aplicación en vivo.

Las pruebas dinámicas y estáticas se complementan

Claude Security detectó varias vulnerabilidades que Evo COS no encontró, principalmente fallas de lógica visibles en el código fuente y criptográficas que no siempre se manifiestan en la aplicación en ejecución. Ningún enfoque es completo por sí solo; este es el argumento a favor de una plataforma y no de una herramienta puntual. Leer el código y atacar la aplicación en ejecución permite detectar cosas que el otro enfoque no encuentra.

Metodología

TaintedPort es una aplicación deliberadamente vulnerable creada y mantenida por nuestro equipo en Snyk, y es pública. Evo COS no se ajustó específicamente para ella.

Objetivo: TaintedPort: 57 vulnerabilidades conocidas (34 comunes y 23 de lógica de negocio) y 15 cadenas de explotación conocidas.

Herramientas y datos de entrada:

• Evo COS: caja gris (URL en vivo + código fuente), 18 de septiembre.

• Claude Security: caja blanca (código fuente), Mythos con razonamiento extendido, 18 de septiembre.

Ejecuciones: una por herramienta. Los resultados corresponden a una sola ejecución, no a medianas.

Detección por categoría

Detección por gravedad (encontradas/conocidas)

Falsos positivos y F1

Reprodúcela: TaintedPort está disponible en taintedport.com.

¿Quieres saber cuáles de los hallazgos en tus propias aplicaciones pueden encadenarse para provocar una brecha? Descubre cómo Evo Continuous Offensive Security prueba tu URL en vivo.