Resumen Técnico: De lo Ejecutable a lo Verificable

Planteamiento del Problema

La comunidad de investigación en seguridad depende cada vez más de los Modelos de Lenguaje de Gran Escala (LLMs) y de los sistemas agénticos para automatizar la validación de vulnerabilidades, incluyendo la reproducción de CVE conocidos, la generación de exploits de Prueba de Concepto (PoC) y la reparación de código. Si bien una creciente literatura afirma tener éxito en estas tareas, la calidad de los artefactos acompañantes varía significamente.

Los estudios de reproducibilidad actuales suelen medir la "disponibilidad" (¿es el código público?) y la "ejecutabilidad" (¿se compila?). Sin embargo, existe una brecha crítica y no medida entre un artefacto que simplemente se ejecuta y produce una señal (por ejemplo, un fallo o un mensaje de registro) y uno que proporciona confirmación semántica de que el CVE específico fue realmente reproducido. Este estudio aborda la falta de métricas operacionalizadas para distinguir entre artefactos que simplemente "se ejecutan y muestran algo alarmante" y aquellos que validan rigurosamente una afirmación de vulnerabilidad específica contra la verdad fundamental (ground truth).

Metodología

El autor llevó a cabo una auditoría de reproducibilidad independiente y preregistrada de la literatura de validación de vulnerabilidades impulsada por LLMs/agentes. El estudio emplea una escalera de evidencia de cuatro niveles para calificar los artefactos:

1. Disponible: El artefacto es accesible públicamente.
2. Ejutable: El artefacto completa su flujo de trabajo en una instantánea limpia (R0) o tras una reparación mínima compatible con el entorno (R1), sin modificar la lógica del exploit ni el oráculo.
3. Generador de Señales: La ejecución produce señales candidatas (fallos, cambios de estado o marcadores específicos).
4. Semánticamente Confirmado: La señal coincide con una postcondición específica del CVE, validada mediante:
   • G3a (Control Negativo): La señal está ausente en entradas benignas.
   • G3b (Contrafáctico Parcheado): La señal está ausente en la versión parcheada.

Corpus y Muestreo:

• Búsqueda: Un protocolo de búsqueda congelado (2023–2026) a través de arXiv, DBLP y OpenAlex arrojó 104 artículos en un corpus de consenso.
• Disponibilidad: 59 de 104 artículos (56.7%) tenían artefactos públicamente alcanzables.
• Muestra a Nivel de Artículo: Se seleccionaron 18 artículos para medir la ejecutabilidad R0/R1 y las cargas de reparación.
• Muestra a Nivel de Caso: El estudio se centró fuertmente en un "benchmark ancla" (arXiv:2509.24037) que contiene 102 casos de vulnerabilidad distintos. Un subconjunto de 20 casos sirvió como piloto de calibración, mientras que los 82 restantes se ejecutaron para formar un análisis de corpus completo.

Protocolo de Ejecución:

• R0: Ejecución en una instantánea limpia y congelada con cero modificaciones.
• R1: Ejecución tras reparaciones exclusivas del entorno (por ejemplo, instalar dependencias faltantes, corregir fuentes de apt obsoletas) sin tocar la lógica del exploit, los oráculos o las postcondiciones.
• Auditoría de Oráculos: El estudio verificó independientemente la fiabilidad de los "oráculos integrados en el artefacto" (la lógica interna de los scripts para declarar un éxito) contra la verdad fundamental del contrafáctico parcheado.

Hallazgos Clave

1. La Brecha de Ejecutabilidad

Entre los 18 artefactos a nivel de artículo probados:

• Solo 10/18 (55.6%) completaron su flujo de trabajo declarado en una instantánea limpia (R0).
• Tras reparaciones exclusivas del entorno (R1), esta cifra aumentó ligeramente a 11/18 (61.1%).
• Los 7 artefactos restantes fallaron en ambos niveles. Los modos de fallo dominantes incluyeron manifiestos de dependencias faltantes, gestores de paquetes incompatibles (por ejemplo, uv frente a pip) y la dependencia de servicios externos o conjuntos de datos no incluidos en el artefacto.

2. Divergencia Interna del Script

Se identificó un problema estructural significativo en el corpus ancla: 58/102 (56.9%) de los casos contenían un identificador de CVE interno del script que divergía del CVE declarado en el directorio.

• Ejemplo: Un directorio declaraba CVE-2023-25668, pero el script ejecutaba un disparador para CVE-2023-25676.
• Esta divergencia socava la validez de la afirmación de reproducción incluso antes de que comience la ejecución, y es invisible para las auditorías de disponibilidad estándar.

3. Falta de Fiabilidad de los Oráculos Integrados en el Artefacto

El estudio encontró que los "oráculos" (la lógica interna que determina si un PoC tuvo éxito) son sistemáticamente poco fiables.

• Contrafácticos Parcheados (G3b): De 30 casos donde se produjo una señal y se auditó una versión parcheada, 20/30 (66.7%) aún produjeron la señal reclamada en la versión parcheada. Estas señales "sucias" indican que el PoC dispara un fallo genérico o un comportamiento no relacionado con la corrección específica del CVE.
• Controles Negativos (G3a): De 19 casos probados contra entradas benignas, 7/19 provocaron falsos positivos.
• Rendimiento del Oráculo: La matriz de confusión para los oráculos integrados en el artefacto mostró una sensibilidad del 60% y una especificidad del 45%.
  • Dos tercios de los disparos de los oráculos fueron falsos positivos (señales que persisten en las versiones parcheadas).
  • Las señales genuinas de CVE específico fueron omitidas por el oráculo en 4/10 casos (a menudo porque el oráculo buscaba un archivo de marcador específico que no fue creado, a pesar de que ocurrió un exploit real).

4. La Brecha de Confirmación Semántica

La confirmación estricta (E1), que requiere una señal que pase G2 (coincidencia de postcondición), G3a (control negativo) y G3b (contrafáctico parcheado), se logró en solo 2 casos de todo el corpus que produjo señales.

• El estudio destaca que "disponibilidad → ejecutable → generador de señales" no implica "semánticamente confirmado".
• Un disparo en una versión vulnerable no es evidencia de la reproducción específica de un CVE sin un contrafáctico parcheado limpio.

Significancia y Contribuciones

El artículo se posiciona como una auditoría exploratoria y preregistrada que operacionaliza la "brecha de confirmación semántica" por primera vez en este dominio. Sus principales contribuciones son:

1. Un Protocolo de Reproducibilidad: Una plantilla reutilizable para la comunidad de seguridad que incluye:
   • Postcondiciones específicas de CVE.
   • Una escalera de reparación R0/R1.
   • Niveles de evidencia semántica G1–G3.
   • Oráculos de contrafáctico parcheado para distinguir la reproducción de un CVE específico de fallos genéricos.
2. Evidencia Empírica de Fallo: El estudio demuestra que la mayoría de los artefactos de validación de LLM/agentes "exitosos" no proporcionan confirmación semántica. Específicamente, la mayoría de los casos que producen señales no sobreviven a su propio contrafáctico parcheado, y los oráculos internos son malos sustitutos de la verdad fundamental.
3. Paquetes de Evidencia Abiertos: El autor libera protocolos congelados, decisiones de cribado, hojas de afirmaciones y registros de ejecución por caso para servir como línea base para futuros estudios de reproducibilidad.

El autor concluye que la comunidad de seguridad debe ir más allá de las comprobaciones de cadenas de activación (trigger-strings) y exigir la verificación de contrafácticos parcheados para validar las afirmaciones de reproducción de vulnerabilidades impulsadas por LLM/agentes. El estudio señala que, aunque estos son resultados exploratorios de un único corpus ancla y una pequeña muestra de artículos, los modos de fallo identificados (IDs de CVE divergentes, oráculos poco fiables, falta de verificación de contrafácticos) sugieren un problema sistémico en la calidad actual de los artefactos.