Resumen Técnico: SEC-bench Pro

Enunciado del Problema

Los Modelos de Lenguaje Grande (LLM) se despliegan cada vez más para tareas automatizadas de seguridad de software, incluyendo el descubrimiento de vulnerabilidades y la generación de pruebas de concepto (PoC). Sin embargo, las evaluaciones existentes no logran evaluar fielmente a los LLM en escenarios reales de caza de errores. Los métodos de evaluación actuales adolecen de tres brechas principales:

1. Dependencia de Entornos de Fuzzing: Muchas evaluaciones (por ejemplo, ARVO, CyberGym) dependen de entornos de fuzzing, lo que reduce el punto de entrada ejecutable a interfaces internas específicas. Esto mide la mutación de entradas guiada por el entorno en lugar de la capacidad de auditar código a través de interfaces públicas.
2. Calificación Específica del Objetivo o Basada en Patrones: Las métricas existentes a menudo comparan la evidencia generada contra parches conocidos, códigos de salida o firmas de fallos. Esto confunde la reproducción del error intencionado con fallos no relacionados en la misma revisión histórica o rechaza PoC válidos que producen trazas diferentes.
3. Exposición Excesiva de Información: Las entradas de las tareas en las evaluaciones actuales suelen incluir informes de sanitizadores, nombres de funciones, números de línea o rutas de activación. Esto elimina la incertidumbre que enfrentan los ingenieros de seguridad al auditar código, proporcionando a los agentes información que no poseerían en un escenario real.

En consecuencia, existe la necesidad de una evaluación que mida la caza de errores por parte de agentes en sistemas de software críticos y de alta complejidad bajo condiciones realistas, requiriendo razonamiento a través de niveles de ejecución sin depender de infraestructura de fuzzing o metadatos excesivamente expuestos.

Metodología

Los autores presentan SEC-bench Pro, una evaluación y una tubería de construcción diseñadas para medir la caza de errores por parte de agentes en motores de JavaScript (específicamente V8 y SpiderMonkey). El sistema emplea una tubería de tres fases y autoevolutiva para convertir informes de seguridad divulgados en tareas reproducibles y validadas.

1. Recopilación de Informes

La tubería ingiere informes de seguridad estructurados desde rastreadores específicos del proyecto (Rastreador de Problemas de Chromium, Bugzilla de Mozilla) y fuentes de asesoramiento curadas (MFSA, Pwn2Own, KEV de CISA). Filtra los informes etiquetados como sec-high o sec-critical (o calificados para recompensas) que incluyen tanto un artefacto PoC concreto como un commit de corrección vinculado.

2. Reconstrucción del Entorno Impulsada por Agentes

Para abordar la intensidad laboral de reconstruir entornos vulnerables históricos, la tubería delega esta tarea a agentes de codificación autónomos.

• Entrada: Los agentes reciben el informe de error crudo, el artefacto PoC y un prompt estructurado que especifica el binario objetivo, los标志 permitidos y los tipos de error esperados.
• Proceso: Los agentes impulsan el sistema de compilación del proyecto para producir binarios instrumentados en la revisión específica reportada, configurados con sanitizadores apropiados (por ejemplo, ASan) o comprobaciones de depuración.
• Salida: El agente genera un paquete de artefactos Docker que contiene los Dockerfiles vulnerables y corregidos, metadatos estructurados, el PoC canónico y las firmas de fallos capturadas. El prompt prohíbe explícitamente las salidas fabricadas.

3. Oráculos de Validación Automatizada

Antes de que una instancia ingrese al conjunto de datos, debe superar dos oráculos automatizados:

• Oráculo de Imagen Vulnerable: Ejecuta el PoC múltiples veces en el contenedor reconstruido. Clasifica los fallos según una taxonomía específica del proyecto (por ejemplo, ASAN_CRASH, SANDBOX_VIOLATION, DCHECK). Una instancia solo pasa si la ejecución produce un fallo que coincide con el tipo de error esperado.
• Oráculo de Imagen Corregida: Aplica el parche vinculado, recompila el binario y ejecuta el mismo PoC. Verifica que el parche suprima el PoC recopilado (clasificando los resultados como BLOCKED_DEFENSIVE, BLOCKED_HARMLESS o BLOCKED_NO_REPRO). Una instancia solo pasa si el PoC ya no se reproduce después de la corrección.

Evaluación y Calificación

La evaluación utiliza una tubería de calificación de tres imágenes (imágenes vulnerable, corregida y más reciente de la rama principal) y un LLM como Juez para determinar el éxito.

• Ejecución: Los PoC candidatos se reproducen en las tres imágenes.
• Juicio: El juez LLM analiza los códigos de salida, stdout y stderr para clasificar el resultado en tres categorías:
  • Verificado: La imagen vulnerable muestra un fallo que coincide con el objetivo; la evidencia de las imágenes corregida/más reciente no contradice esta atribución.
  • Incierto: La evidencia es incompleta (por ejemplo, fallo de infraestructura en las ejecuciones de corregida/más reciente), requiriendo adjudicación manual.
  • Ilegal: El fallo no coincide con el objetivo, o las imágenes corregida/más reciente muestran que el fallo persiste debido a una causa raíz diferente.
• Métrica de Éxito: Una instancia es exitosa si al menos un PoC candidato recibe un resultado verified. Este enfoque evita la inflación de "solo fallos" donde los agentes activan fallos no relacionados.

Contribuciones Clave

• Conjunto de Datos SEC-bench Pro: Una colección de 183 vulnerabilidades validadas en V8 (103 instancias) y SpiderMonkey (80 instancias). El subconjunto de V8 incluye informes con premios acumulados del Programa de Recompensas por Vulnerabilidades de Google que superan los 1,5 millones de dólares.
• Tubería Autoevolutiva: Una tubería de construcción parametrizada que puede ingerir nuevos informes respaldados por PoC y parches sin rediseñar la evaluación, aplicable a cualquier proyecto con recetas de compilación a nivel de fuente e informes públicos.
• Oráculo de Calificación de Tres Imágenes: Un método de evaluación robusto que distingue entre la reproducción intencionada de errores y fallos no relacionados o fallos de infraestructura, abordando las limitaciones de los calificadores de solo fallos o de coincidencia de parches.
• Evaluación Integral de Agentes: Una evaluación de tres estructuras de agentes de codificación de última generación (CODEX, CLAUDECODE, OPENCODE) en tareas de seguridad de largo alcance.

Resultados

La evaluación de modelos de vanguardia y líneas base de pesos abiertos revela limitaciones significativas en las capacidades actuales para la caza de errores de largo alcance:

• Tasas de Éxito Bajas: Incluso las configuraciones más fuertes permanecen por debajo del 40% de éxito en ambos motores.
  • V8: La configuración única más fuerte (CODEX con GPT-5.4) logra un 32,0% (33/103). La línea base de pesos abiertos Kimi-K2.6 logra un 11,7%.
  • SpiderMonkey: La configuración más fuerte (CLAUDECODE con Opus 4.6) logra un 38,8% (31/80).
• Cobertura Complementaria: Los agentes resuelven conjuntos de instancias en gran medida disjuntos. La unión de CLAUDECODE y CODEX alcanza un 37,9% en V8 y un 48,8% en SpiderMonkey, lo que sugiere que ninguna estrategia de agente única domina todas las clases de vulnerabilidad.
• Diferencias de Estrategia:
  • CLAUDECODE emplea una estrategia de alto alcance, generando muchos PoC especulativos con un rendimiento bajo por PoC. A menudo falla porque los PoC nunca activan un fallo (códigos de salida limpios) o activan fallos no relacionados.
  • CODEX emplea una estrategia de alta selectividad, generando menos PoC pero de mayor confianza. A menudo falla porque se abstiene de enviar cuando no puede verificar localmente la alcanzabilidad, o sus PoC activan fallos que no están completamente mitigados por el parche (colisiones de corrección parcial).
• Costo del Fracaso: Las ejecuciones fallidas consumen consistentemente significativamente más tokens y tiempo de ejecución que las ejecuciones exitosas (por ejemplo, una brecha de 3,0 veces en tokens para CLAUDECODE en V8), lo que indica que la exploración prolongada a menudo conduce a rendimientos decrecientes en lugar de un análisis más profundo.
• Importancia de la Atribución: Un calificador de "solo fallos" inflaría las tasas de éxito en aproximadamente un 43,6% en todas las configuraciones, destacando la necesidad del juez LLM de tres imágenes para filtrar fallos mal atribuidos.

Significado

El artículo establece SEC-bench Pro como un objetivo concreto y reproducible para medir el progreso en la seguridad de software automatizada. Demuestra que, aunque los LLM pueden asistir en el descubrimiento de vulnerabilidades, los modelos de vanguardia actuales luchan con la complejidad de la caza de errores de largo alcance en motores de nivel de producción. La evaluación expone limitaciones específicas, incluida la dificultad de sintetizar condiciones de activación complejas (por ejemplo, estados específicos de JIT, elusión de sandbox) y el alto costo de la exploración fallida. Los autores concluyen que los sistemas futuros requieren una síntesis de activación más fuerte, mecanismos de atribución más robustos y estrategias de búsqueda en conjunto para cerrar la brecha entre las capacidades actuales y los requisitos de la auditoría de seguridad en el mundo real.