LLM-based Vulnerability Detection at Project Scale: An Empirical Study

Resumen Técnico: Detección de Vulnerabilidades Basada en LLM a Escala de Proyecto: Un Estudio Empírico

Planteamiento del Problema
A medida que la complejidad del software y las escalas de despliegue aumentan, las vulnerabilidades de seguridad se han vuelto más frecuentes y perjudiciales, lo que requiere una detección automatizada robusta. Si bien las herramientas tradicionales de análisis estático son ampliamente adoptadas, dependen de reglas diseñadas manualmente y patrones predefinidos, lo que limita su capacidad para generalizar a tipos de vulnerabilidades no vistos o en evolución. Por el contrario, los detectores recientes basados en Modelos de Lenguaje de Gran Escala (LLM) prometen un razonamiento semántico mejorado al interpretar la semántica del código y la lógica compleja sin ingeniería de reglas explícita. Sin embargo, la mayoría de los enfoques basados en LLM actuales se evalúan en fragmentos a nivel de función o de trozo (hunk), dejando incierta su efectividad, confiabilidad y escalabilidad a la escala de proyecto. Existe una falta de comprensión sistemática con respecto a las causas raíz de los fallos (específicamente los falsos positivos) y la sobrecarga computacional cuando estos detectores especializados se aplican a bases de código reales y extensas.

Metodología
Los autores presentan el primer estudio empírico integral que compara cinco detectores especializados basados en LLM a escala de proyecto contra dos analizadores estáticos tradicionales (CodeQL y Semgrep). El estudio emplea una estrategia de evaluación de doble configuración:

1. Benchmark Interno: Un conjunto de datos curado de 222 vulnerabilidades reales conocidas (que cubren 8 tipos de CWE en C/C++ y Java) derivadas de ReposVul, CWE-Bench-Java y JLeaks. Esta configuración evalúa la capacidad de detección (Recall) frente a la verdad fundamental (ground truth).
2. Proyectos del Mundo Real: Un conjunto de 24 proyectos de código abierto mantenidos activamente (incluyendo componentes del kernel de Linux, ImageMagick, Jenkins y Keycloak). Esta configuración evalúa la usabilidad práctica mediante el análisis de los volúmenes de advertencias y las Tasas de Descubrimiento Falso (FDR).
3. Análisis Manual: Dos expertos en seguridad inspeccionaron manualmente 385 advertencias muestreadas (requiriendo más de 150 horas humanas) para construir una taxonomía de las causas raíz de los falsos positivos.
4. Medición de Costos: El estudio cuantificó la sobrecarga computacional, midiendo el consumo de tokens de entrada/salida y el tiempo de ejecución de extremo a extremo para cada herramienta.

Los métodos basados en LLM evaluados incluyen RepoAudit, KNighter, IRIS, LLMDFA e INFERROI, que representan diversos flujos de trabajo como marcos de trabajo multi-agente, generación de verificadores asistida por LLM y de inferencia guiada por flujo de control.

Contribuciones Clave

• Primera Comparación a Escala de Proyecto: El estudio proporciona la primera comparación sistemática de cinco detectores basados en LLM representativos frente a herramientas tradicionales a escala de proyecto.
• Evaluación Integral: Evalúa la efectividad de la detección en 222 vulnerabilidades conocidas y la usabilidad práctica en 24 proyectos del mundo real.
• Taxonomía de Fallos: Los autores etiquetaron manualmente 385 informes para construir una taxonomía detallada de las causas de los falsos positivos, cuantificando cómo las decisiones de diseño (por ejemplo, construcción de flujo de datos, inferencia de origen/sumidero) contribuyen a los fallos.
• Análisis de Costos: El documento mide y reporta el sustancial uso de tokens y los costos de tiempo asociados con la detección basada en LLM a escala de proyecto.
• Liberación de Artefactos: Todos los artefactos experimentales, incluyendo scripts, prompts y etiquetas de taxonomía, se liberan para fomentar la reproducibilidad.

Resultados Clave

1. Bajo Recall pero Detecciones Únicas: En el benchmark interno, los métodos basados en LLM exhibieron un recall promedio bajo (21.09% para C/C++ y 33.82% para Java), fallando a menudo en detectar vulnerabilidades debido a definiciones de origen/sumidero desalineadas. Sin embargo, aun así descubrieron más vulnerabilidades únicas que las herramientas tradicionales, sugiriendo un valor complementario.
2. Altas Tasas de Descubrimiento Falso (FDR): En proyectos del mundo real, tanto las herramientas basadas en LLM como las tradicionales generaron advertencias sustanciales con FDRs muy altos. Incluso la herramienta con mejor desempeño tuvo un FDR promedio del 85.3%. Por ejemplo, RepoAudit en proyectos de C/C++ tuvo un SFDR promedio del 97.0%.
3. Causas Raíz del Fallo: El análisis manual identificó dos causas dominantes compartidas por herramientas LLM y tradicionales:
   • Razonamiento Interprocedimental Superficial (37.47% de los FPs): Las herramientas fallan al rastrear flujos de datos a través de cadenas de llamadas profundas o estructuras de control complejas.
   • Identificación Imprecisa de Origen/Sumidero (19.00% de los FPs): Las herramientas identifican erróneamente puntos benignos del programa como relevantes para la seguridad o no reconocen APIs específicas del proyecto.
   • Fallos Específicos de LLM: Las herramientas basadas en LLM sufrieron adicionalmente de comprensión de código alucinada, reconstrucción incorrecta del flujo de control (por ejemplo, fusionar rutas mutuamente excluyentes) y falta de adherencia estricta a las definiciones de prompts o alcances de CWE.
4. Sobrecarga Computacional: La detección basada en LLM a escala de proyecto es computacionalmente costosa. Herramientas como RepoAudit y LLMDFA requirieron cientos de miles a cientos de millones de tokens por proyecto, con tiempos de ejecución que variaron desde múltiples horas hasta múltiples días (por ejemplo, hasta 4,638 minutos). Las herramientas tradicionales (CodeQL, Semgrep) completaron los análisis en segundos o minutos con costos de tokens insignificantes.

Significancia e Implicaciones
El documento concluye que, si bien los detectores basados en LLM ofrecen capacidades de razonamiento semántico prometedoras que pueden descubrir vulnerabilidades omitidas por las herramientas tradicionales de coincidencia de patrones, aún no son lo suficientemente maduros para un despliegue fiable y autónomo en escenarios del mundo real. El estudio destaca limitaciones críticas en robustez (alto FDR), confiabilidad (bajo recall en la verdad fundamental) y escalabilidad (costos computacionales prohibitivos).

Los autores derivan cinco implicaciones para la investigación futura:

1. Profundizar el Razonamiento de Flujo de Datos: Ir más allá de la exploración superficial de grafos de llamadas hacia un análisis holístico de "entrada → propagación → salida".
2. Mejorar la Inferencia de Origen/Sumidero: Desarrollar mecanismos conscientes del contexto para identificar con precisión APIs específicas del proyecto en lugar de depender de definiciones genéricas o alucinadas.
3. Mejorar la Comprensión Semántica: Integrar LLMs con representaciones de programas intermedias y señales de análisis estático para manejar mejor las características complejas del lenguaje (por ejemplo, destructores, try-with-resources).
4. Forzar la Alineación de Prompts: Implementar la colaboración multi-agente estructurada o la autoverificación para asegurar que los modelos se adhieran estrictamente a las definiciones de vulnerabilidad.
5. Abordar la Escalabilidad: Adoptar el análisis jerárquico, el almacenamiento en caché del razonamiento intermedio y la optimización de flujos de trabajo para reducir el consumo de tokens y el tiempo de ejecución a niveles adecuados para la integración continua.

Los autores enfatizan que los hallazgos actuales subrayan la necesidad de enfoques híbridos que aprovechen las fortalezas semánticas de los LLM mientras mitigan sus problemas de costo y confiabilidad mediante la integración de un análisis estático riguroso.