Hemos quemado 11.7 mil millones de tokens para evaluar las capacidades cibernéticas de 10 modelos de IA, con tres intentos por cada uno, a partir de 32 vulnerabilidades recientes y ya disponibles en el mercado que debían volver a descubrirse.
Esta prueba comparativa es una evolución de nuestra anterior prueba comparativa basada en CVE conocidos, con un conjunto de datos nuevo y más complejo, más modelos y un análisis más detallado de lo que detectan, la fiabilidad con la que lo hacen, así como sus peculiaridades y compensaciones.
Con esto, incorporamos a la gama los modelos GLM-5.3, DeepSeek V4 Pro 0813, DeepSeek V4 Flash 0731, Qwen3.8-Max, Kimi K3 y Grok 4.6.
En resumen:
- DeepSeek V4 Pro 0813 es el que detecta más vulnerabilidades. Al combinar los resultados de tres ejecuciones, se detectan 28 de las 32 vulnerabilidades.
- No es necesario el modelo más caro. Tres ejecuciones de DeepSeek Pro cuestan unos 295 dólares y superan en rendimiento a Opus 5, Grok 4.6 o Sol. Tres ejecuciones de Flash cuestan 108 dólares y alcanzan 24 coincidencias, igualando la mejor pasada individual de Grok por menos de una cuarta parte del coste.
- Los modelos presentan inconsistencias en cuanto a la recuperación; la repetición subsana este problema. Las ejecuciones individuales no captan la amplitud de los resultados, pero la combinación de los resultados de varias ejecuciones subsana esta carencia. DeepSeek Pro detecta 17 vulnerabilidades en su primera pasada, pero 28 en las tres.
- Los modelos de código abierto superan ahora a la frontera pública. DeepSeek V4 Pro superó a todos los modelos cerrados públicos que probamos en cuanto a la recuperación de vulnerabilidades agrupadas. Qwen, Kimi y GLM-5.3 le siguieron con una gran consistencia en los resultados sin perder recuperación. Si se utilizan correctamente, los modelos abiertos pueden ahora competir directamente con la frontera de los modelos cerrados.
- El precio de una cobertura barata es el ruido. Los modelos abiertos alcanzaron la frontera a un coste mucho menor, pero también generaron la mayor cantidad de pistas falsas que el proceso de selección tuvo que descartar.
Cómo funciona el análisis comparativo
Seleccionamos 32 vulnerabilidades en repositorios reales y pedimos a cada modelo que las volviera a detectar a partir del código fuente.
Cada modelo ejecutó el conjunto completo de 32 casos tres veces, lo que suma un total de 96 ejecuciones. Esto nos permite medir cuántas vulnerabilidades es capaz de detectar un modelo y cuántas de ellas puede detectar de forma fiable.
La configuración era una versión limitada del «harness» que se describe en nuestro artículo « análisis de código con IA ». Sustituimos el modelo de la etapa primaria, encargado de la exploración del código y el razonamiento con cada uno de nuestros contendientes, y asignamos al agente un máximo de 30 turnos. Además, los modelos no tienen acceso a Internet.
Prestamos especial atención a la actualidad de los conjuntos de datos. Las 32 vulnerabilidades se seleccionaron de entre los CVE publicados recientemente para reducir la probabilidad de que los modelos ya hubieran visto la vulnerabilidad, el informe o el parche durante el entrenamiento. El objetivo era poner a prueba el razonamiento sobre las vulnerabilidades, en lugar de la memorización de errores ya conocidos. Los casos, las indicaciones, las herramientas y la política de evaluación se mantuvieron fijos en todas las ejecuciones.
En primer lugar, conviene establecer algunas definiciones que utilizaremos a lo largo de este artículo:
- Recuerdo: ¿Cuántas vulnerabilidades detectó realmente el modelo?
- Precisión: ¿Cuántos de los resultados comunicados fueron aceptados?
- Pase: una ejecución completa de un modelo en nuestro conjunto de datos de 32 vulnerabilidades
Cómo sacar partido a la varianza de los resultados de los modelos
El rendimiento de los modelos de lenguaje grande (LLM) depende en gran medida del problema en cuestión. Por lo general, los problemas penalizan la variabilidad de los resultados del modelo cuando se requiere que estos sean reproducibles o fiables.
Si se le asigna a un agente la misma tarea en tres sesiones distintas, es posible que la resuelva de tres formas diferentes. Ninguna de estas formas tiene por qué ser «incorrecta», pero la variación hace que el sistema sea impredecible, lo cual no suele ser bueno, ya que, con la misma entrada y el mismo sistema, se obtienen resultados diferentes.
Sin embargo, la detección de vulnerabilidades es uno de esos problemas en los que, de hecho, se puede hacer que esta propiedad de los modelos de lenguaje grande (LLM) juegue a nuestro favor en lugar de en nuestra contra. Fundamentalmente, se trata de un problema de espacio de búsqueda, y los problemas de búsqueda pueden beneficiarse de esta varianza. En las auditorías de seguridad, la combinación de los resultados de múltiples ejecuciones puede —y, como verás, ha— dado lugar a mejores resultados.
La inconsistencia entre modelos genera diversidad, lo que a su vez puede mejorar la capacidad de recuperación. Si en una ejecución se detectan errores que en otra se pasan por alto, puedes quedarte con ambas.
DeepSeek Pro detectó 17 vulnerabilidades en su primera pasada. Si esa fuera la única pasada, ese sería el resultado final.
Sin embargo, en su segunda y tercera ejecución detectó vulnerabilidades que las ejecuciones anteriores habían pasado por alto. Si sumamos los resultados de las tres, DeepSeek alcanzó un 28/32, lo que le valió el primer puesto en nuestra prueba de rendimiento.
Lo mismo ocurrió en otros casos. Qwen pasó de 19 en su primera ronda a 26 en el recuento global. Kimi pasó de 17 a 25. Grok pasó de 24 a 26.
Los modelos exploratorios se beneficiaron enormemente de la repetición, ya que cada ejecución exploraba diferentes vías útiles. Grok se benefició mucho menos, ya que cada vez encontraba más o menos las mismas vulnerabilidades.
Todos los modelos detectaron 17 casos al menos una vez. Uno de ellos superó a los diez. Los 14 restantes son aquellos en los que los modelos dejaron de parecer intercambiables.
DeepSeek obtuvo el mayor índice de recuperación combinado. Grok fue el más consistente.
DeepSeek fue el que más detectó, aunque no de forma muy constante de una ejecución a otra. En tres ejecuciones, V4 Pro 0813 llegó a detectar finalmente 28 de los 32 CVE, lo que le valió el mejor resultado global en la prueba comparativa. Sin embargo, solo 10 de ellos se detectaron en todas las ejecuciones.
Grok se mostró más conservador. Encontró un número ligeramente inferior de vulnerabilidades en total (26 de 32), pero cuando detectaba algo, era mucho más probable que lo volviera a encontrar. Detectó 21 CVE en las tres ejecuciones, lo que lo convierte en el modelo más consistente de los que probamos, superando a todos los demás.
Opus 5 también encontró 26 de 32 y registró la mejor pasada individual, con 25, además de mantener una consistencia de 19 casos en las tres pasadas. Sol encontró 25 de 32 con la misma consistencia de 19 casos y generó algunos de los informes más claros.
Los modelos DeepSeek también generaron un número mucho mayor de resultados candidatos que los demás modelos. Esa exploración agresiva mejoró su recuperación, pero también supuso un mayor número de pistas falsas que el resto del proceso tuvo que filtrar.
Se observa una tendencia clara: el mayor coste de las técnicas de «frontier» se compensa con una reducción de los costes de la clasificación posterior y una mayor consistencia.
Las pistas de la investigación
DeepSeek Pro fue el modelo que más recursos consumió en la prueba comparativa. Fue el que más presupuesto de investigación utilizó, con una mediana de 24 turnos del límite máximo de 30 turnos que asignamos a nuestros agentes.
Opus era la más implacable de todas las fronteras cerradas. Las investigaciones que no dieron lugar a ningún candidato duraron una mediana de 29 turnos, mientras que las que sí dieron lugar a un candidato duraron 19.
Sol registró una media de aproximadamente 2,74 problemas potenciales por investigación y presentó algunos de los resultados de razonamiento más claros que hemos visto, haciendo que, por lo general, la ruta desde la entrada controlada por el atacante hasta el impacto en la seguridad resultara fácil de seguir.
Qwen, ¡uf! Este modelo me ha dado una sensación de déjà vu con el CVE.
En 95 de las 96 ejecuciones, tras reconocer el código fuente, dedicó varios turnos a analizar las vulnerabilidades (CVE) más antiguas y ya reveladas que se encontraban en el código fuente, basándose en sus conocimientos de entrenamiento.
Esas vulnerabilidades ya se habían corregido en la versión del código fuente con la que realizamos las pruebas de rendimiento, por lo que la mayor parte de este presupuesto destinado a la investigación se malgastó antes de que, finalmente, se volviera a centrar en el análisis del código.
A veces es un «déjà vu» que sirve de pista. Otras veces, simplemente se trata de curiosear, pero, en cualquier caso, Qwen estaba haciendo algo mucho más parecido a un análisis autónomo de variantes que a una simple búsqueda de coincidencias, sin que nadie se lo hubiera pedido.
A pesar de esta peculiaridad, subió mucho en la clasificación, igualando a Opus y Grok en la categoría «pass@3 pooled recall», situándose justo detrás del líder, DeepSeek.
De todos ellos, Kimi fue el que presentó el perfil de exploración más breve, con una mediana de 12 giros. Sus trazas solían converger de forma explícita, descartaban las teorías menos sólidas y se decidían mucho antes en la investigación que las de sus compañeros.
Además, presentó una precisión combinada del 92,3 %, superior a la de cualquier otro modelo de peso abierto que probamos. Menos resultados falsos y menos falsos positivos.
GLM acorta la brecha de las zonas fronterizas
No, no nos hemos olvidado del GLM-5.3. De hecho, nos hemos quedado despiertos toda la noche por él (¡literalmente!).
Gracias a Z.AI, tuvimos la oportunidad de colaborar estrechamente con su equipo como socio de evaluación inicial de GLM-5.3, sometiéndolo a nuestras pruebas de referencia de ciberseguridad y compartiendo nuestros comentarios a lo largo de todo el proceso previo al lanzamiento.
Durante la evaluación, probamos dos versiones de GLM-5.3: una versión preliminar previa al lanzamiento y la versión final lanzada.
GLM-5.3-preview superó a GPT 5.6 Terra en la relación coste-rendimiento en pass@3. Volvió a detectar el 75 % de los CVE con un coste un 40 % menor y fue, además, el más consistente de los modelos de peso abierto, con 14 de 32 detectados en las tres ejecuciones.
La versión final de GLM mejoró esta base y ganó varios puntos en cuanto a recuperación y consistencia, al tiempo que mantuvo más o menos la misma precisión.
Era notablemente más persistente que la última versión, lo que provocó un aumento de la mediana de uso por turno, que pasó de 18 a 23.
En general, los resultados muestran una exploración más amplia y profunda. La precisión en la recuperación mejoró de 24/32 a 25/32, situándose a la altura de GPT Sol y siendo un 65,5 % más barato. También superó a GPT-5.6 Terra, GPT-5.6 Luna y DeepSeek Flash 0731, y quedó a solo 1 CVE de Opus 5, siendo al mismo tiempo un 69,8 % más barato.
Su consistencia también aumentó de 14/32 a 18/32, un resultado constante en todas las ejecuciones. Estas mejoras se lograron a costa de un aumento del coste por CVE detectado, que pasó de 14,77 $ a 19,65 $. Sigue siendo considerablemente más barato que Sol, Opus y Grok, al tiempo que ofrece un rendimiento competitivo. Además, presentó el mayor valor de «pass@1 recall» de todos los modelos de código abierto.
Las apuestas sin límite acaban de superar la «frontera pública»
En nuestra última comparativa, se observó que las estrategias de ponderación abierta estaban ganando terreno rápidamente. Esta vez han hecho mucho más que ponerse al nivel: cuando se han aplicado correctamente, han obtenido resultados equiparables e incluso han superado a la cartera de referencia.
DeepSeek ofreció la mejor cobertura global de todos los modelos, por delante de Opus, Sol y Grok. GLM 5.3 se equiparó en cuanto a consistencia entre ejecuciones, y Qwen se mantuvo firme en precisión y recuperación globales.
Los modelos cerrados seguían teniendo sus propias ventajas, pero la antigua jerarquía —con un modelo de frontera cerrada en la cima y todo lo demás por debajo— no superó esta prueba comparativa.
Esta prueba de rendimiento evalúa únicamente el rendimiento de las versiones de los modelos «closed frontier» disponibles públicamente. No hemos utilizado los modelos Mythos ni los de la clase GPT 5.6 Daybreak en nuestras pruebas.
¿Significa esto que puedes quitar el Sol/Opus de tus sistemas e instalar cualquiera de los modelos «open-weight»?
No es así.
Hablamos de «utilizarse correctamente», y lo hacemos con énfasis. Los modelos de peso abierto son formidables, pero aún no tienen el nivel necesario para sustituir a un «frontier» sin un sistema de sujeción cuidadosamente diseñado.
A medida que los modelos de vanguardia mejoran, observamos la tendencia de que un uso mínimo de los parámetros equivale a un mejor rendimiento. El grupo de «open-weights» aún está a unos pasos de alcanzar este mínimo.
Entonces, ¿a qué modelo contrataríamos?
Tras unos 11 700 millones de tokens, «¿Qué modelo es el mejor?» ya no es la pregunta adecuada.
Es mejor preguntarse dónde debería encajar un modelo en tu sistema. ¿A qué investigador envías primero, a cuál envías en segundo lugar y quién revisa el trabajo de quién?
No es necesario que te decantes directamente por el modelo más caro. Tres ejecuciones de DeepSeek V4 Pro 0813 costaron unos 295 dólares y detectaron 28 de las 32 vulnerabilidades, más que cualquier ejecución individual de Opus 5, Grok 4.6 o Sol, a pesar de que cada una de esas ejecuciones costó entre 450 y 590 dólares aproximadamente.
Incluso tres ejecuciones de Flash cuestan solo 108 dólares y alcanzan 24 coincidencias, igualando el mejor resultado de Grok en una sola pasada por menos de una cuarta parte del precio. Repetir un modelo eficiente puede ofrecer más cobertura que una única y costosa apuesta arriesgada, pero conlleva sus propias desventajas. El coste se traslada a las fases posteriores del proceso.
El diseño de los arneses entra en juego precisamente a la hora de encontrar el equilibrio entre la capacidad de recuperación y la precisión.
¡Estamos encantados con las novedades! Merece la pena perder horas de sueño. ¡Hasta la próxima!
.png)
Este benchmark evalúa modelos sin procesar. Aikido los convierte en hallazgos de vulnerabilidades fiables. Code Security Audit aplica ese razonamiento a todo tu código fuente. Piensa en ello como una IA con capacidad de acción SAST . Aikido Attack envía agentes autónomos a tu aplicación en ejecución, agrupando los resultados y descartando las pistas falsas del mismo modo que el proceso de aquí las rechazó. Aprovecha el poder de los modelos más recientes y protege tus sistemas. Échale un vistazo en aikido.dev.
P.D.: También estamos contratando. Ven a crear con nosotros.
