Resumen Técnico: POC-GYM: Hacia una Generación de Explotos de Concepto (PoC) Asistida por LLM Más Confiable

Declaración del Problema

La generación de explotos de concepto (PoC) es crítica para validar vulnerabilidades, ayudar en el desarrollo de parches y servir como pruebas de regresión. Sin embargo, una fracción significativa de las vulnerabilidades divulgadas públicamente carece de PoCs disponibles. Aunque los Modelos de Lenguaje Grandes (LLM) se han aplicado cada vez más para automatizar la detección de vulnerabilidades y la generación de explotos, los enfoques existentes a menudo sufren problemas de fiabilidad.

Los métodos actuales asistidos por LLM suelen generar PoCs basados en descripciones de vulnerabilidades y los validan utilizando señales superficiales, como marcadores impresos, archivos generados o efectos secundarios en tiempo de ejecución. El problema central identificado por los autores es que estas señales pueden ser satisfechas por rutas de código de "falsos positivos" que no activan realmente la vulnerabilidad subyacente. En consecuencia, un PoC puede parecer exitoso bajo verificaciones automáticas en tiempo de ejecución mientras falla en alcanzar la ubicación real del código vulnerable (la verdad fundamental). Existe la necesidad de un pipeline de generación más fiable que distinga entre el éxito superficial y la explotación genuina.

Metodología: Marco PoC-Gym

Los autores proponen PoC-Gym, un pipeline híbrido diseñado para generar explotos PoC en Java combinando trazas de flujo de datos de Pruebas de Seguridad de Aplicaciones Estáticas (SAST) con el razonamiento de LLM. El marco opera a través de tres etapas iterativas:

1. Construcción del Prompt:

   • Contexto Específico de la Vulnerabilidad: El sistema utiliza un LLM para generar "guía específica de CVE" explícita, definiendo un objetivo de explotación concreto y una verificación de validación programática basada en las descripciones del CVE y la Enumeración de Debilidades Comunes (CWE).
   • Contexto de Trazas: Para proporcionar rutas de programa concretas, PoC-Gym integra trazas de flujo de datos de fuente a sumidero extraídas estáticamente utilizando CodeQL y el marco IRIS. Estas trazas son clasificadas por un asistente de triaje LLM para seleccionar las rutas más relevantes antes de ser formateadas e insertadas en el prompt.
   • Restricciones del Repositorio: El prompt incluye metadatos sobre el repositorio vulnerable (URL, commit, scripts de compilación) y restricciones estrictas sobre el uso de API (por ejemplo, evitar la reflexión, limitar dependencias) para garantizar que el código generado sea ejecutable.

2. Generación del PoC:

   • Un agente LLM (por ejemplo, Claude Sonnet 4, GPT-5) recibe el prompt estructurado y genera un único archivo de código fuente Java (PoCTest.java).
   • El agente está restringido a crear una clase pública con un método main que active la vulnerabilidad e imprima un marcador de éxito específico ([VULN]).

3. Validación del PoC:

   • Validación en Tiempo de Ejecución: El PoC candidato se compila y ejecuta en el proyecto vulnerable utilizando instrumentación AspectJ. Un candidato se considera "válido en tiempo de ejecución" solo si:
     1. Sale exitosamente (código de salida 0).
     2. Imprime el marcador [VULN].
     3. Alcanza la ubicación de sumidero específica definida en la traza estática (Alcanzabilidad del Sumidero).
   • Retroalimentación Iterativa: Si la validación falla, un resumen de fallo (incluyendo salida y cobertura de trazas) se agrega al prompt para la siguiente iteración.
   • Validación Posterior: Crucialmente, los autores introducen un paso de validación separado contra ubicaciones vulnerables de "verdad fundamental" proporcionadas por el benchmark CWE-Bench-Java. Este paso verifica si la ejecución alcanzó realmente el rango específico de archivo y línea identificado en el parche, distinguiendo la explotación verdadera de la simulación.

Contribuciones Clave

• Pipeline Híbrido: La integración de trazas de flujo de datos derivadas del análisis estático con la generación por LLM y verificaciones dinámicas de alcanzabilidad del sumidero para guiar la generación de explotos.
• Mecanismo de Doble Validación: La distinción entre "válido en tiempo de ejecución" (satisfaciendo los criterios del bucle de generación) y "válido posterior" (alcanzando la ubicación vulnerable de verdad fundamental), destacando la sobreestimación del éxito en los métodos existentes.
• Análisis Exhaustivo de Fallos: Un análisis manual en profundidad de los PoCs que aprobaron la validación en tiempo de ejecución pero fallaron en las verificaciones posteriores, categorizando modos de fallo como "errores no relacionados" (trazas/descripciones incorrectas), "codificación fija", "simulación" (reimplementar la lógica de la vulnerabilidad en lugar de invocarla) y "mala validación" (señales de éxito poco fiables).

Resultados Experimentales

Los autores evaluaron PoC-Gym en 20 CVEs reales de Java de CWE-Bench-Java utilizando tres configuraciones diferentes de LLM.

• Validez en Tiempo de Ejecución vs. Posterior: A través de 338 ejecuciones, PoC-Gym generó 116 candidatos válidos en tiempo de ejecución (34.3%). Sin embargo, después de la validación posterior contra ubicaciones de verdad fundamental, solo 65 candidatos (19.2%) fueron confirmados como válidos. Esto indica que el 44% de los candidatos que parecían exitosos bajo verificaciones en tiempo de ejecución eran en realidad falsos positivos que no alcanzaron el sumidero de vulnerabilidad real.
• Impacto de la Guía de Trazas: Los experimentos sin información de trazas lograron una tasa de éxito inicial en tiempo de ejecución más alta (86.7%) pero una validez posterior mucho menor (36.7%). En contraste, la configuración de múltiples trazas tuvo una tasa de éxito inicial más baja (23.0%) pero una caída menor en la validez posterior (15.5%), lo que sugiere que la guía de trazas ayuda a filtrar soluciones inválidas que no corresponden a rutas vulnerables reales.
• Comparación con FaultLine: En los 14 CVEs que se superponen con el sistema FaultLine, la configuración más fuerte de PoC-Gym (Claude Sonnet 4 con trazas) logró 8/14 resultados válidos posteriores, en comparación con 5/14 para FaultLine bajo sus criterios de evaluación originales.

Significado y Afirmaciones

El artículo afirma que, aunque los LLM muestran promesa en la generación de estrategias de explotación, no pueden tratarse como un reemplazo completo de las técnicas deterministas de generación de pruebas. Los autores argumentan que:

1. La fiabilidad requiere validación de verdad fundamental: Las señales de tiempo de ejecución por sí solas sobreestiman sustancialmente la corrección del exploit; la validación posterior contra ubicaciones vulnerables conocidas es necesaria para evaluar la eficacia real.
2. El contexto de trazas reduce los falsos positivos: Aunque las trazas estáticas no eliminan todos los fallos, reducen significativamente la proporción de soluciones inválidas que satisfacen señales de éxito superficiales.
3. Los patrones de fallo son sistemáticos: Muchos fallos surgen de patrones específicos y recurrentes (por ejemplo, el LLM simulando la vulnerabilidad en lugar de activarla, o utilizando trazas no relacionadas). Comprender estos patrones es esencial para mejorar el diseño futuro de los sistemas.

Los autores concluyen que el progreso futuro en la generación de PoC asistida por LLM depende no solo de mejorar la calidad de la generación, sino también de desarrollar mecanismos de validación más sólidos y utilizar el análisis de fallos para guiar la combinación de la creatividad del LLM con verificaciones impulsadas por especificaciones.