An Insight into Security Code Review with LLMs: Capabilities, Obstacles, and Influential Factors

Título: Una perspectiva sobre la revisión de código de seguridad con LLM: Capacidades, obstáculos y factores influyentes

Declaración del Problema
La revisión de código de seguridad es un proceso crítico pero intensivo en mano de obra, esencial para prevenir filtraciones de datos y pérdidas financieras. Si bien las organizaciones integran cada vez más el análisis de seguridad en la revisión de código, las herramientas automatizadas existentes (análisis estático/dinámico/híbrido) sufren de una pobre generalización, altas tasas de falsos positivos y una granularidad de detección tosca. Además, los enfoques basados en datos que utilizan aprendizaje automático tradicional o aprendizaje profundo a menudo carecen de robustez debido a la escasez de conjuntos de datos de entrenamiento realistas, desempeñándose mal en proyectos del mundo real. Aunque los Modelos de Lenguaje Grande (LLM) han demostrado ser prometedores en diversas tareas de ingeniería de software, sus capacidades específicas, limitaciones y los factores que influyen en su rendimiento en el contexto de granularidad fina de la revisión de código de seguridad permanecen en gran medida inexplorados.

Metodología
Los autores realizaron un estudio empírico para evaluar el potencial de los LLM en la detección de defectos de seguridad durante la revisión de código. El estudio utilizó un conjunto de datos curado manualmente de 534 archivos de código (258 en Python, 276 en C/C++) derivados de cuatro proyectos de código abierto (OpenStack Nova/Neutron y Qt Base/Creator), que contenían 614 comentarios de revisión relacionados con la seguridad.

• Modelos Evaluados: Se probaron siete LLM, incluyendo modelos propietarios (GPT-4, GPT-4 Turbo, Gemini Pro), modelos de código abierto (Llama 2 7B, Llama 2 70B) y un modelo optimizado para razonamiento (DeepSeek-R1).
• Ingeniería de Prompts: Se diseñaron cinco plantillas de prompts distintas basadas en las mejores prácticas y estrategias anteriores:
  1. Prompt Básico ($P_b$): Instrucción directa para revisar el código.
  2. Información del Proyecto ($P_r$): Se añadió el contexto del nombre del proyecto.
  3. Instrucción General CWE ($P_c$): Se instruyó para utilizar CWE como referencia.
  4. Instrucción Específica CWE ($P_{cid}$): Se proporcionó una lista de CWE de nivel superior.
  5. Cadena de Pensamiento ($P_{cot}$): Un prompt de dos etapas que requiere que el modelo genere el contexto del código a partir de un mensaje de commit antes de analizarlo en busca de defectos. También se probó una versión con "guardarríles" ($P_{cot-guardrail}$) para aislar el impacto del contexto generado.
• Métricas de Evaluación: Las respuestas se etiquetaron manualmente en cuatro categorías: Instrumental (tipo de defecto, ubicación y descripción precisos), Útil (parcialmente preciso), Engaño (fallo en la detección o falsos negativos) e Incertidumbre. Las métricas incluyeron I-Score, IH-Score y M-Score. La consistencia se midió mediante la entropía de las respuestas en tres ejecuciones experimentales.
• Análisis: El estudio comparó el rendimiento de los LLM frente a herramientas de análisis estático de última generación (por ejemplo, CodeQL, Bandit, CppCheck). Para los modelos de mejor rendimiento, un análisis lingüístico identificó problemas de calidad (por ejemplo, alucinaciones, vaguedad). Finalmente, se construyeron modelos de regresión de enlace cumulativo para analizar la influencia de 11 factores (por ejemplo, recuento de tokens, complejidad del código, tipo de defecto) en el rendimiento.

Contribuciones Clave

1. Evaluación de Granularidad Fina: Se proporcionó una evaluación exhaustiva de LLM populares en la revisión de código de seguridad, avanzando más allá de la clasificación binaria para evaluar la localización de defectos, la descripción y las sugerencias de remediación.
2. Análisis de No Determinismo: Se midió el impacto del no determinismo de los LLM en la consistencia de los resultados de la revisión de código de seguridad.
3. Cuantificación de Problemas de Calidad: Se identificaron y cuantificaron problemas de calidad específicos, incluidas las alucinaciones (factuales y de fidelidad), en las respuestas de los modelos de mejor rendimiento.
4. Análisis de Influencia de Factores: Se realizó el primer análisis de regresión para validar estadísticamente cómo atributos específicos del código y del proyecto influyen en el rendimiento de los LLM en este dominio.

Resultados

• Rendimiento frente a Líneas Base: Los LLM superaron significativamente a las herramientas de análisis estático de última generación en la revisión de código de seguridad. Entre los LLM, el modelo optimizado para razonamiento (DeepSeek-R1) superó a los modelos de propósito general.
• Mejores Rendimientos: DeepSeek-R1 logró el rendimiento general más alto, seguido por GPT-4 (a través de la plataforma ChatGPT).
  • Prompts Óptimos: DeepSeek-R1 funcionó mejor con un prompt que combinaba el mensaje de commit y la guía de Cadena de Pensamiento (CoT) ($P_{cot-guardrail}$). GPT-4 (ChatGPT) funcionó mejor con un prompt que contenía una lista específica de CWE ($P_{cid}$).
• Problemas de Calidad:
  • GPT-4 (ChatGPT): Frecuentemente producía expresiones vagas y tenía dificultades para seguir instrucciones (por ejemplo, números de línea faltantes), aunque cometía menos errores factuales sobre los detalles del código.
  • DeepSeek-R1: Más propenso a generar detalles de código inexactos (por ejemplo, números de línea o nombres de funciones incorrectos) y exhibió una tasa más alta de alucinaciones de "Hecho Incorrecto", a pesar de tener mejores capacidades de seguimiento de instrucciones.
• Factores Influyentes:
  • Recuento de Tokens: Los LLM fueron más hábiles para identificar defectos en archivos con menos tokens; el rendimiento generalmente disminuyó a medida que aumentaba el recuento de tokens.
  • Anotaciones: La presencia de anotaciones relacionadas con la seguridad en el código mejoró las capacidades de detección.
  • Complejidad: Una mayor complejidad del código se correlacionó con capacidades de detección mejoradas para DeepSeek-R1 en tipos de defectos específicos (excluyendo los relacionados con la memoria), contrariamente a la suposición de que la complejidad siempre dificulta la detección.
  • Consistencia: Los modelos con mayores capacidades de detección (DeepSeek-R1, GPT-4 ChatGPT) exhibieron menor consistencia (mayor entropía) entre ejecuciones en comparación con modelos menos capaces.

Significancia y Afirmaciones
El artículo afirma que, si bien los LLM actuales aún no son un reemplazo para los revisores humanos, sirven como herramientas auxiliares poderosas que superan significativamente a las herramientas de análisis estático tradicionales en la detección de defectos de seguridad. El estudio destaca que la efectividad de los LLM depende en gran medida de la ingeniería de prompts (específicamente la inclusión de mensajes de commit, CoT o listas de CWE) y de las características específicas del código que se está revisando (recuento de tokens, complejidad, anotaciones).

Los autores enfatizan que el no determinismo de los LLM es un arma de doble filo: los modelos capaces de un razonamiento más profundo (y por lo tanto de una mejor detección) tienden a producir salidas más inconsistentes. Concluyen que es necesaria una estrategia de revisión multinivel, donde los LLM manejen las revisiones iniciales de código de baja dificultad (menos tokens) mientras que los expertos humanos se centran en el código de alta dificultad y validan los hallazgos de los LLM. El estudio también subraya la necesidad de trabajos futuros para abordar las alucinaciones sobre los detalles del código y mejorar la estabilidad de las salidas de los LLM sin sacrificar la sensibilidad de detección.