TL;DR
- GPT-5.6 obtiene la puntuación más alta en recuperación, con un máximo de 23/26, por delante de grok-4.5 (20), los modelos Claude Opus (entre 15 y 18) y el resto de modelos que hemos probado. Esto significa que es capaz de volver a detectar el 88,5 % de las CVE.
- No es necesario optar por la opción más cara. Las variantes más económicas del GPT-5 .6 ofrecen resultados que difieren en uno o dos hallazgos respecto a su modelo insignia, a una fracción del coste, y la combinación de varias ejecuciones de un modelo de gama media rivaliza con una sola ejecución del modelo insignia.
- Las ejecuciones del modelo son inconsistentes, pero al agrupar los resultados se obtienen mejores resultados. Cada ejecución individual pasa por alto errores que detectaría en otra; ejecutar un modelo varias veces y agrupar los resultados (pass@3) supera de forma fiable a una sola ejecución de un modelo más potente y costoso.
- El «open weight» está ganando terreno rápidamente. El GLM-5 .2 ya ha redescubierto el 59 % del conjunto (16/26), lo que lo sitúa en la mitad de la tabla entre los modelos propios.
Cada vez que se lanza un nuevo modelo de frontier, viene acompañado de la misma afirmación sobre ciberseguridad: detecta vulnerabilidades. Pero, ¿funciona con un error real en un repositorio real, o solo con un ejemplo seleccionado? De la docena de modelos entre los que se puede elegir, ¿en cuál merece la pena confiar para la revisión del código? Y dado que los modelos más potentes cuestan diez veces más —o incluso más— por ejecución que los más baratos, ¿qué te aporta realmente ese gasto adicional en cuanto a errores detectados?
Es fácil clasificar los modelos según su capacidad bruta y declarar ganador al más caro, pero la pregunta más importante es si el precio merece la pena. Por eso, hemos sometido a prueba 13 de los modelos entre los que los equipos eligen actualmente frente a 26 vulnerabilidades conocidas de la base de datos de avisos de GitHub. Abarcan una amplia variedad de lenguajes y tipos de proyectos. Hemos medido dos aspectos: cuántos errores ha detectado cada modelo y cuánto ha costado detectarlos.
Cómo funciona el índice de referencia
Seleccionamos 26 vulnerabilidades de la base de datos de alertas de GitHub —una muestra aleatoria que abarcaba distintos lenguajes y tipos de proyectos, desde una inyección SQL en un marco de trabajo web hasta una ejecución remota de código (RCE) por deserialización en un kit de herramientas de aprendizaje automático— y pedimos a cada modelo que las volviera a detectar, repositorio por repositorio, dentro del mismo análisis de código con IA que utilizamos en producción. En lugar de una ventana de chat, se trata de un modelo con herramientas reales que navega por el repositorio y analiza el código tal y como lo haría un auditor.
El «harness» es lo que convierte a un modelo de lenguaje en un auditor. Un asistente de programación de uso general está diseñado para una tarea diferente: tomar una tarea y generar código que funcione. Si se le indica un repositorio y se le pregunta si es seguro, se comporta como un desarrollador que revisa rápidamente en busca de algo que esté claramente mal, y se detiene en cuanto encuentra algo plausible. análisis de código con IA está diseñado de forma diferente. Explora el código en busca de posibles puntos de entrada, investiga en profundidad cada flujo sospechoso y, a continuación, clasifica los resultados para que solo queden las vulnerabilidades reales.
Como sabíamos dónde se encontraba cada vulnerabilidad, dirigimos a cada agente investigador directamente al fragmento de código vulnerable. De ese modo, un fallo se debe a un error de razonamiento y no a un desperdicio de presupuesto por buscar en la parte equivocada del código. El modelo aún tiene que comprender el flujo, evaluar la posibilidad de explotación e informar de ello correctamente. Las indicaciones se mantuvieron breves y independientes del modelo, para que ningún proveedor se viera favorecido por la redacción.
Ejecutamos cada modelo tres veces y agrupamos los resultados. Se considera que se ha «encontrado» un CVE si el modelo lo detecta en cualquiera de las ejecuciones (pass@3).
Hemos seleccionado una variedad de los últimos modelos de distintos fabricantes:
- OpenAI: gpt-5.4-nano, gpt-5.4-mini, gpt-5.5 y la serie gpt-5.6 (luna / terra / sol)
- Anthropic: claude-haiku-4-5, claude-opus-4-7, claude-opus-4-8
- xAI: grok-4.5
- Google: gemini-3.1-pro, gemini-3.5-flash
- Peso en abierto: glm-5.2
Resultados según la gravedad y la vulnerabilidad
Todos los modelos volvieron a detectar ambas vulnerabilidades CVE críticas (una RCE por deserialización y un XSS almacenado). La diferencia real se aprecia en los hallazgos de gravedad alta y media.
Las CVE más difíciles y las más fáciles
Todos los modelos detectaron los dos errores críticos y varias vulnerabilidades evidentes relacionadas con la inyección y el control de acceso. Un puñado de cadenas específicas logró burlar casi todas ellas.
Las vulnerabilidades CVE que detecta cada modelo siguen el mismo patrón: entradas controladas por el atacante que llegan a una operación peligrosa ya conocida a través de un flujo corto y local, como una llamada de deserialización, la ejecución de un shell, un sink HTML o una comprobación de firma defectuosa. Se trata de reconocimiento de patrones, y se resuelve de forma eficaz. Tanto los modelos económicos como los de gama alta obtienen una puntuación de 13/13, sin que haya ninguna diferencia en cuanto a capacidad.
La verdadera frontera, y donde realmente se marca la diferencia en la capacidad de los modelos, es el razonamiento sobre las comprobaciones que no existen y el seguimiento de cadenas complejas que ninguna línea por sí sola revela. El caso más claro es la «Inyección SQL-1» de nuestro conjunto de datos, una inyección indirecta a través de un alias de columna que el ORM nunca escapa. Solo GPT-5.5 y los modelos más potentes de GPT-5.6 (sol y terra) la detectaron.
Qué nos indica la diferencia entre la media y la unión
La cifra más útil de esta prueba comparativa es la distancia entre la ejecución media de un modelo y la unión de todas sus ejecuciones. Dado que cada pasada detecta un subconjunto diferente de errores, al agruparlas (pass@3) se recupera una cantidad sorprendente:
Fíjate en gpt-5.4-nano: ninguna ejecución por sí sola supera el 14, pero tres ejecuciones combinadas alcanzan el 18, lo que supone un salto de cuatro CVE, ya que cada pasada detecta errores diferentes. claude-haiku-4-5 es el caso más llamativo de variabilidad, con una puntuación de 7 en una ejecución y de 13 en otra, ambas del mismo modelo y en la misma tarea.
La conclusión es que no hace falta optar directamente por el modelo más caro. Tres ejecuciones de gpt-5.4-nano cuestan unos 170 dólares y alcanzan 18/26, el mismo resultado medio que obtiene una sola ejecución de un modelo insignia como el gpt-5.6-terra, pero por una fracción del precio. Tres ejecuciones del GPT-5.4-mini (unos 460 dólares) alcanzan un 20. Repetir un modelo sólido de gama media supera a una sola ejecución de un modelo insignia con mucha más frecuencia de lo que sugiere la diferencia de precio.
¿Merece la pena el razonamiento superior?
Ejecutamos los modelos correspondientes en dos niveles de razonamiento: el predeterminado «alto» y el más alto disponible («xhigh» para los modelos GPT-5.4/5.5 y Claude, y «max» para GPT-5.6, grok-4.5 y glm-5.2). Todas las cifras corresponden a uniones de «pass@3», por lo que son directamente comparables.
Las victorias claras son las de GPT-5.5 (+3 a un coste 1,5 veces mayor) y GLM-5.2 (+3 a un coste 1,3 veces mayor). Claude-Opus-4-8 gana +2, pero cuesta el doble. En el resto de casos, el nivel superior aporta un resultado o ninguno, y en el caso de GPT-5.6-Luna y GPT-5.4-Nano se situó un punto por debajo, dentro del margen de variación entre ejecuciones. GPT-5.6-Terra es el caso más claro de rendimientos decrecientes: 2,2 veces el coste por los mismos 23.
Los modelos Gemini no tienen ningún ajuste superior a «alto», por lo que se han omitido de esta comparación.
Conclusión
Si se aplica un modelo de Frontier a un código fuente, dentro de un entorno de pruebas diseñado para ello, este vuelve a detectar la mayoría de las vulnerabilidades conocidas. Los errores con un «sink» peligroso evidente se resuelven. Los que siguen separando los modelos no tienen ningún «sink» al que apuntar. Una comprobación de autorización que falta, o una inyección a la que solo se puede llegar siguiendo una cadena larga y oscura a través de varios archivos.
El nivel más caro rara vez justifica su precio. Ejecutar un modelo más barato varias veces y combinar los resultados permite obtener más información, por menos dinero, que con una sola pasada de un modelo insignia, y esa ventaja no hace más que aumentar a medida que los modelos se vuelven más baratos y potentes. El arnés sigue siendo lo que determina, en primer lugar, si ese razonamiento se aplica a la parte correcta del código fuente.
