Generating Proof-of-Vulnerability Tests to Help Enhance the Security of Complex Software

Resumen Técnico: Generación de Pruebas de Vulnerabilidad para Mejorar la Seguridad de Software Complejo

Enunciado del Problema
Los ataques a la cadena de suministro de software (SSC) explotan vulnerabilidades en bibliotecas de terceros (Libs) utilizadas por aplicaciones (Apps). Aunque existen herramientas para detectar dependencias vulnerables o sugerir reparaciones, a menudo no logran demostrar si una vulnerabilidad específica es explotable de manera práctica dentro de una aplicación aguas abajo. Los desarrolladores requieren frecuentemente evidencia concreta y ejecutable, conocida como pruebas de vulnerabilidad (PoV), para evaluar los riesgos de seguridad y priorizar las correcciones. Sin embargo, la creación manual de estas pruebas es un desafío, y las herramientas automatizadas existentes (por ejemplo, SIEGE, Transfer) han mostrado un éxito limitado en la generación de pruebas PoV para aplicaciones Java complejas. El desafío central radica en identificar puntos de entrada a nivel de aplicación que alcancen las APIs de bibliotecas vulnerables, generar pruebas que respeten el contexto específico del programa y validar que estas pruebas activan con éxito la vulnerabilidad.

Metodología: PoVSmith
Los autores proponen PoVSmith, un enfoque basado en agentes diseñado para automatizar la generación, ejecución y evaluación de pruebas PoV para aplicaciones Java. El sistema opera a través de cuatro fases distintas:

1. Fase I: Análisis de Rutas de Llamada Basado en Agentes

   • Objetivo: Identificar puntos de entrada a nivel de aplicación (métodos públicos) que invoquen (in)directamente APIs de bibliotecas vulnerables (sumideros).
   • Enfoque: En lugar de depender de herramientas tradicionales de análisis estático (como WALA o Soot) que tienen dificultades con los JDK modernos y la mapeo de bytecode a código fuente, PoVSmith utiliza un agente de codificación con IA (Codex).
   • Proceso: El agente se solicita mediante un script integrado en la CLI para analizar el código fuente de la aplicación. Localiza todas las invocaciones de la API vulnerable y rastrea las rutas de llamada hasta los métodos públicos, filtrando las rutas que pasan por otros métodos públicos para identificar la superficie de ataque mínima.

2. Fase II: Generación de Pruebas Basada en Agentes

   • Objetivo: Generar iterativamente pruebas JUnit que demuestren la lógica de la explotación.
   • Enfoque: El agente (Codex) se solicita con una plantilla exhaustiva que contiene:
     • Contexto: La API vulnerable, el método fuente y la ruta de llamada completa.
     • Ejemplo: Una prueba de referencia de la propia biblioteca que demuestra la vulnerabilidad (por ejemplo, una prueba que muestra cómo una versión parcheada rechaza una entrada maliciosa mientras que una versión vulnerable la acepta).
     • Restricciones: Reglas para la estructura de la prueba (Organizar-Agir-Afirmar), independencia (sin simulación de entidades de la ruta de llamada) y construcción de la carga útil.
   • Iteración: El agente participa en un bucle de autocrítica. Genera una prueba, intenta compilarla/ejecutarla, analiza la salida y refina la prueba basándose en errores (por ejemplo, fallos de compilación o comportamiento incorrecto) hasta un límite de intentos.

3. Fase III: Compilación y Ejecución de Pruebas

   • Objetivo: Validar las pruebas generadas para prevenir "alucinaciones" donde los agentes producen código aparentemente correcto pero no funcional.
   • Proceso: Un script automatizado compila y ejecuta las pruebas generadas utilizando el sistema de compilación del proyecto (Maven o Gradle). Captura registros detallados, incluidos rastros de pila y resultados de tiempo de ejecución, que sirven como verdad fundamental para la siguiente fase.

4. Fase IV: Evaluación Basada en LLM

   • Objetivo: Determinar si la prueba activa con éxito la vulnerabilidad.
   • Enfoque: Un Modelo de Lenguaje Grande (GPT-5.1) analiza el código de la prueba y los registros de ejecución. Se le solicita decidir si el comportamiento de la prueba (por ejemplo, excepciones específicas o fallos de afirmación) confirma la presencia de la vulnerabilidad. La salida incluye un juicio ("sí/no/desconocido"), nivel de confianza y razonamiento.

Contribuciones Clave

1. Metodología Novel Basada en Agentes: PoVSmith introduce una pipeline que combina el análisis de rutas de llamada, la generación impulsada por ejemplos, el refinamiento iterativo mediante retroalimentación de ejecución y la autocrítica basada en LLM.
2. Caracterización de Capacidades de IA: El trabajo evalúa sistemáticamente la efectividad de los agentes de codificación (Codex, Gemini, Mistral) en el análisis de rutas de llamada y la generación de pruebas, así como la precisión de los LLM para evaluar la calidad de las pruebas basándose en registros de ejecución.
3. Nuevo Conjunto de Datos: Los autores curaron un conjunto de datos de 33 pares <App, Lib> de Java que involucran 20 CVE, conteniendo 207 rutas de llamada verificadas y 152 puntos de entrada a nivel de aplicación únicos.
4. Descubrimientos de Seguridad: El sistema identificó vulnerabilidades previamente no reportadas, lo que llevó a la presentación de seis solicitudes de pull request y seis solicitudes de CVE (aunque la retroalimentación estaba pendiente en el momento de la publicación).

Resultados Experimentales
Evaluado en 33 pares <App, Lib>:

• Análisis de Rutas de Llamada (RQ1): PoVSmith logró una precisión del 96% (152/158 métodos identificados correctamente) y una recuperación del 81% frente a puntos de entrada conocidos, con una puntuación F1 del 88%.
• Generación de Pruebas (RQ2): De 152 tareas de generación, 141 (93%) se compiló con éxito. De estas, 84 (55%) demostraron con éxito la vulnerabilidad (PoV). El sistema mostró mayor efectividad para los tipos de ataque Recorrido Directo (DT) y Otros (OTH) en comparación con la Ejecución Remota de Código (RCE).
• Precisión de la Evaluación (RQ3): El evaluador basado en LLM logró una precisión del 68% para determinar si una prueba activó una vulnerabilidad, superando la autocrítica del agente de codificación (62%).
• Comparación de Agentes (RQ4): Codex superó significativamente a los agentes alternativos (Gemini Code Assist y Mistral Vibe) tanto en la calidad de la generación de código como en el cumplimiento de las instrucciones del prompt.
• Comparación con Trabajo Previo (RQ5): PoVSmith superó sustancialmente al enfoque basado en LLM más avanzado [78]. Mientras que el enfoque anterior generó 16 pruebas compilables con solo 5 demostraciones exitosas de PoV, PoVSmith generó 22 demostraciones exitosas de PoV.

Significado y Afirmaciones
El artículo afirma que PoVSmith cierra efectivamente la brecha entre la detección de vulnerabilidades y la evaluación práctica de riesgos al proporcionar a los desarrolladores una prueba ejecutable de explotabilidad. Los autores enfatizan que su enfoque reduce la participación humana mientras mejora drásticamente la calidad de las pruebas en comparación con las herramientas existentes. Posicionan a PoVSmith no como un detector de vulnerabilidades, sino como una herramienta para validar la explotabilidad de vulnerabilidades conocidas en contextos de aplicación específicos, ayudando así a priorizar los parches de seguridad. El trabajo destaca el potencial de combinar agentes de codificación con retroalimentación iterativa de ejecución para resolver tareas complejas de ingeniería de software que las herramientas tradicionales de análisis estático no pueden manejar de manera efectiva.