SEC-bench Pro: ¿realmente saben los agentes de IA cazar bugs en V8 y SpiderMonkey?

¿Qué es esto?

“SEC-bench Pro: Can Language Models Solve Long-Horizon Software Security Tasks?” (arXiv:2605.26548, 26 de mayo de 2026) es un benchmark que plantea la pregunta que todo equipo de seguridad debe responder ahora: cuando se apunta un agente de código a una base de código grande y real y se le pide encontrar una vulnerabilidad, ¿con qué frecuencia lo logra de verdad? La respuesta, sobre los dos objetivos elegidos por los autores —los motores JavaScript V8 de Google y SpiderMonkey de Mozilla— es «menos veces de lo que sugiere el marketing».

El trabajo extiende el SEC-bench original (NeurIPS 2025), limitado a tareas cortas y bien acotadas, hacia tareas de largo horizonte: caza de bugs en varios pasos sobre software de calidad navegador, donde el agente debe recorrer una base de código de un millón de líneas, formular una hipótesis, construir una prueba de concepto y confirmar el fallo —sin un arnés de fuzzing entregado y sin una descripción que señale el bug. Ese realismo es justamente el punto. Los autores sostienen que los benchmarks anteriores sobreestiman a los modelos porque se apoyan en pistas específicas del objetivo o en simples tareas de reproducción.

Cómo funciona

SEC-bench Pro se instancia con 183 vulnerabilidades validadas que abarcan bugs de seguridad de memoria, escape de sandbox, JIT y condiciones de carrera —categorías que corresponden a cómo se rompen realmente los motores de navegador. Solo el subconjunto de V8 representa más de 1,5 millones de dólares en recompensas acumuladas del Vulnerability Reward Program de Google: no son bugs de juguete, sino fallos por los que investigadores reales cobraron sumas considerables.

Cada tarea se ejecuta bajo condiciones de calidad navegador o de runtime, y el agente se evalúa según si logra descubrir y reproducir el fallo de extremo a extremo. Es clave que el arnés mide el flujo de trabajo de largo horizonte en lugar de un único paso de recuperación o parche, que es donde los agentes actuales tienden a desmoronarse.

Los resultados principales, tal como los reporta el artículo:

# Reported pass rates (higher = better), per the SEC-bench Pro paper
Open-weight baseline (Kimi-K2.6)      V8: 11.7%
Strongest single frontier config      V8: 32.0%   SpiderMonkey: 38.8%
ClaudeCode + Codex (two-agent union)  V8: 37.9%   SpiderMonkey: 48.8%

Destacan dos hallazgos. Primero, toda configuración se queda por debajo del 40 % en cada motor por separado: los agentes de código de vanguardia están lejos de ser cazadores de bugs autónomos y fiables en objetivos difíciles. Segundo, ClaudeCode y Codex resuelven conjuntos de instancias complementarios: su unión supera a cada uno por separado (una mejora de en torno al 18 % en V8 y ~26 % en SpiderMonkey frente al mejor scaffold individual, según los autores). Scaffolds distintos encuentran bugs distintos.

Por qué importa

Es un artículo de medición de capacidad, no un ataque, pero las cifras cortan en ambos sentidos y ambos públicos deben leerlas con atención.

Para los atacantes, el resultado es más aleccionador que alarmante: un agente listo para usar no va a minar de forma autónoma bugs de V8 de 1,5 M$ hoy. El ruido en torno a una «IA que encuentra zero-days a escala» va, sobre esta evidencia, por delante de la realidad en los objetivos más duros —coherente con lo visto en las huellas de zero-days escritos por IA y la escalera de capacidad de explotación.

Para los defensores, el hallazgo de complementariedad es la parte accionable. Si usa agentes de código para el descubrimiento proactivo de vulnerabilidades, un modelo único deja bugs sobre la mesa; un conjunto de agentes con scaffolds variados eleva notablemente la cobertura. Y el techo por debajo del 40 % recuerda que la caza de bugs por IA aumenta la revisión humana —no la sustituye. La trayectoria también importa: el techo de hoy no es el de mañana, y la misma competencia de largo horizonte que ayuda a los equipos defensivos ayudará a la ofensiva —de ahí el valor de seguir benchmarks honestos y sin arnés como este. La dificultad más amplia de evaluar con justicia a estos agentes es exactamente el problema señalado en evaluar agentes de seguridad es difícil.

Defensas

Conclusiones concretas para los equipos que adoptan la IA en seguridad:

• Trate la caza de bugs por IA como aumento, no como autonomía. Una tasa de éxito por debajo del 40 % en objetivos difíciles significa que los humanos deben triar, confirmar y asumir los hallazgos. Conecte la salida del agente a su proceso de revisión existente, no por fuera de él.
• Ejecute conjuntos, no un solo modelo. Como ClaudeCode y Codex encuentran bugs complementarios, desplegar varios agentes con scaffolds distintos eleva la cobertura más que mejorar uno solo. La diversidad de scaffold gana al maximalismo de un único modelo.
• Haga benchmark sobre su propio código, sin arnés. La lección de SEC-bench Pro es que las pistas y los arneses inflan las puntuaciones. Evalúe proveedores y herramientas internas con tareas realistas y sin pistas antes de creer una promesa de «detección automática de vulnerabilidades».
• Planifique para la curva, no para la instantánea. Diseñe su detección, divulgación y priorización de parches asumiendo que la capacidad de los agentes seguirá subiendo —el valor defensivo del red-teaming agéntico que comprime semanas en horas se aplica de forma simétrica a los atacantes.

Estado

Elemento	Valor
Publicación	arXiv:2605.26548, 26 de mayo de 2026
Objetivos	V8 y SpiderMonkey (183 vulnerabilidades validadas)
Clases de bugs	seguridad de memoria, sandbox, JIT, condiciones de carrera
Mejor config individual	32,0 % (V8) / 38,8 % (SpiderMonkey)
Unión de dos agentes	37,9 % (V8) / 48,8 % (SpiderMonkey)
Naturaleza	Benchmark de capacidad — sin exploit publicado

Es investigación publicada y revisable, con una página de proyecto pública; documenta un techo de capacidad, no un fallo de producto sin parchear. La cifra útil para llevarse: en objetivos genuinamente difíciles y sin arnés, los mejores agentes de IA de hoy resuelven bastante menos de la mitad de los bugs —y la manera de mejorar pasa por más agentes diversos y revisión humana, no por confianza ciega en un solo modelo.