Persistent Human Feedback, LLMs, and Static Analyzers for Secure Code Generation and Vulnerability Detection

Resumen Técnico: Retroalimentación Humana Persistente, LLMs y Analizadores Estáticos para la Generación de Código Seguro y Detección de Vulnerabilidades

Planteamiento del Problema
El artículo aborda la creciente dependencia de los Modelos de Lenguaje de Gran Escala (LLMs) para la generación de código seguro y la detección de vulnerabilidades, destacando una brecha crítica en las metodologías de evaluación actuales. Si bien los LLMs se utilizan cada vez más en el desarrollo de software, frecuentemente generan código inseguro incluso cuando se les instruye explícitamente para que no lo hagan. La literatura existente evalúa predominantemente estos modelos utilizando herramientas de análisis estático automatizadas (por ejemplo, CodeQL, Semgrep) como la única verdad fundamental (ground truth). Los autores argumentan que este enfoque es defectuoso porque los analizadores estáticos presentan altas tasas de falsos positivos y a menudo no se alinean con el juicio de expertos humanos respecto a las vulnerabilidades de seguridad reales. Además, los marcos actuales carecen de mecanismos para almacenar y reutilizar de forma persistente la retroalimentación de los expertos, lo que limita la capacidad de los LLMs para aprender de correcciones pasadas.

Metodología
El estudio emplea una metodología de dos vertientes: una revisión exhaustiva de la literatura y un estudio de validación empírica.

1. Revisión de la Literatura: Los autores examinaron 2025 publicaciones de conferencias de primer nivel en ingeniería de software (A/A*) para caracterizar las tendencias de investigación actuales. Analizaron los benchmarks, los lenguajes de programación objetivo, las familias de modelos y las herramientas de evaluación utilizadas en estudios de generación de código seguro y detección de vulnerabilidades.
2. Validación Empírica:
   • Construcción del Conjunto de Datos: Utilizando la técnica de prompting de Mejora de Críticas Recursivas (RCI) con GPT-4o, los autores generaron 1,080 muestras de código basadas en 108 tareas únicas mapeadas a la lista CWE Top 25.
   • Creación de la Verdad Fundamental (Ground Truth): Dos revisores capacitados (un estudiante de doctorado y uno de maestría), bajo supervisión docente, inspeccionaron manualmente las muestras para etiquetarlas como vulnerables o seguras con respecto a su CWE específico. Los desacuerdos se resolvieron mediante discusión o arbitraje de expertos, logrando un alto acuerdo entre evaluadores (Cohen's $\kappa = 0.94$).
   • Comparación de Herramientas: La verdad fundamental validada manualmente se comparó con los resultados de dos herramientas de análisis estático ampliamente utilizadas, CodeQL y Semgrep.
   • Propuesta de Marco de Trabajo: Basándose en los hallazgos, los autores proponen un marco conceptual que integra la retroalimentación humana en un flujo de trabajo de Generación Aumentada por Recuperación (RAG).

Resultados Clave
El estudio empírico reveló discrepancias significativas entre las herramientas automatizadas y los expertos humanos:

• Verdad Fundamental: El 61% de las muestras generadas eran genuinamente seguras, mientras que el 39% contenía vulnerabilidades.
• Desempeño de las Herramientas: Semgrep clasificó el 60% de las muestras como seguras y CodeQL clasificó el 80% como seguras. Aunque la tasa agregada de Semgrep parecía cercana al juicio humano, el análisis por muestra mostró desacuerdos sustanciales.
• Métricas de Precisión: Solo el 65% de los informes de Semgrep y el 61% de los de CodeQL coincidieron correctamente con las etiquetas de la verdad fundamental.
• Cobertura de CWE: Ambas herramientas fallaron en detectar los CWE objetivo en una fracción sustancial de los casos de verdad fundamental y reportaron con frecuencia hallazgos para CWE no objetivos (cuya validez permaneció desconocida en este estudio).
• Autocrítica: El estudio observó que los LLMs que proporcionaban autocríticas "específicas" (críticas dirigidas y accionables) producían código más seguro (64% seguro) en comparación con las críticas "generales" (56% seguro).

Marco Propuesto: Retroalimentación Humana Persistente
Para abordar las limitaciones de las herramientas estáticas y la naturaleza transitoria de los bucles de retroalimentación actuales, los autores proponen un marco conceptual (ilustrado en la Figura 3) que integra un agente de Humano en el Bucle (HIL) en un flujo de trabajo RAG dinámico. El marco consta de cuatro agentes:

1. Agente de Prompt: Orquesta la generación de código recuperando orientación de seguridad relevante de un RAG de Fuente Dual (Retroalimentación Humana y Conocimiento Externo de Vulnerabilidades) para refinar el prompt del desarrollador.
2. Agente de Seguridad: Evalúa el código generado utilizando analizadores estáticos y LLMs, produciendo informes legibles tanto para máquinas como para humanos.
3. Agente de Humano en el Bucle (HIL): Actúa como el decisor final. Los expertos revisan los informes del Agente de Seguridad. En casos de desacuerdo, la retroalimentación del experto se almacena de forma persistente en el RAG.
   • Ponderación de Confianza: El sistema asigna pesos de confianza dinámicos a la retroalimentación basándose en el consenso de los revisores y el éxito empírico histórico (usando una Media Móvil Exponencial).
   • Revisión Dual: Para prevenir el envenenamiento de datos, la nueva retroalimentación requiere la aprobación de dos revisores distintos antes de ingresar al grupo de recuperación activo.
4. RAG de Fuente Dual: Un servicio de conocimiento compartido que prioriza la retroalimentación validada por humanos (HF) sobre el conocimiento externo general (EVK) utilizando una función de puntuación compuesta que penaliza las contradicciones entre el consejo general y la retroalimentación del experto.

Significancia y Reivindicaciones
El artículo sostiene que confiar únicamente en las herramientas de análisis estático para evaluar el código generado por LLMs es poco fiable y plantea riesgos para la validez de la investigación de seguridad. Los autores afirman que la retroalimentación de los expertos no solo es necesaria para instancias individuales, sino que puede generalizarse a casos futuros similares. En consecuencia, el marco propuesto tiene como objetivo permitir que los LLMs reutilicen la retroalimentación humana previa de forma dinámica, mejorando tanto la generación de código seguro como la detección de vulnerabilidades. El estudio concluye que la comunidad de ingeniería de software debe ir más allá de la evaluación puramente automatizada e incorporar bucles de retroalimentación persistentes impulsados por expertos para garantizar la fiabilidad de los LLMs en contextos de seguridad crítica.

Limitaciones (Amenazas a la Validez)
Los autores reconocen varias limitaciones:

• Validez de Constructo: La revisión de la literatura se restringió a publicaciones de 2025 en entornos de ingeniería de software, lo que podría omitir patrones en entornos específicos de seguridad (por ejemplo, USENIX Security, CCS).
• Validez Interna: Las etiquetas de verdad fundamental dependen de la evaluación manual, la cual está sujeta al sesgo humano a pesar del alto acuerdo entre evaluadores.
• Validez Externa: Los experimentos se centraron en código Python generado por GPT-4o mediante el uso de prompting RCI. Los resultados pueden no generalizarse a otros lenguajes (particularmente lenguajes de bajo nivel como C/C++), otros dominios o diferentes LLMs y herramientas de análisis estático.