Resumen Técnico: Un Estudio Empírico de la Calibración de Seguridad en Modelos de Lenguaje de Gran Escala para Código

1. Planteamiento del Problema

Los Modelos de Lenguaje de Gran Escala (LLMs) se están integrando cada vez más en los flujos de trabajo de desarrollo de software para tareas como la generación de código y la corrección de errores. Sin embargo, su despliegue en contextos críticos de seguridad plantea una pregunta fundamental: ¿saben los modelos con precisión cuándo su código generado es inseguro?

Mientras que los benchmarks existentes (por ejemplo, HumanEval, MBPP, SWE-Bench) evalúan la corrección funcional, ignoran en gran medida las propiedades de seguridad. Los benchmarks orientados a la seguridad recientes evalúan si el código contiene vulnerabilidades, pero no logran medir si los modelos pueden autoasentarse la seguridad de sus salidas. Esta brecha conduce al fenómeno de la Falsa Confianza (False Trust), donde los modelos asignan una alta confianza a código vulnerable. Los desarrolladores, confiando en estas señales de confianza, pueden aceptar salidas inseguras sin escrutinio, propagando vulnerabilidades en los sistemas de producción.

Trabajos previos no han medido sistemáticamente la calibración de seguridad —la alineación entre la confianza declarada por un modelo en la seguridad de su salida y el estado de seguridad real de dicha salida—. Además, sigue siendo desconocido si los patrones de calibración observados en programas aislados y autocontenidos se generalizan a contextos de repositorios realistas de múltiples archivos, o si las señales de calibración pueden guiar eficazmente la reparación automatizada de vulnerabilidades.

2. Metodología

Los autores presentan el primer estudio empírico a gran escala de la calibración de seguridad, evaluando tres modelos de vanguardia: GPT-4o-mini, Gemini-2.0-Flash y Qwen3-Coder-Next. El estudio emplea una evaluación de múltiples etapas a través de dos benchmarks complementarios y cuatro preguntas de investigación (RQs).

Conjuntos de Datos y Contextos

• Programas Autocontenidos (RQ1): Utilizó el benchmark SALLM, que consta de 100 tareas de Python críticas para la seguridad. Cada tarea proporciona un único prompt con entradas, salidas esperadas y requisitos de seguridad, aislados de dependencias externas.
• Contextos a Nivel de Repositorio (RQ2): Utilizó el benchmark AICGSecEval, que presenta 125 prompts en cuatro lenguajes (C, Java, PHP, Python) y 29 CWEs. Estas tareas requieren generar parches dentro de repositorios existentes de múltiples archivos, involucrando dependencias entre archivos, configuraciones de construcción y APIs externas.

Configuración Experimental

• Modelos y Parámetros: Cada modelo fue probado en seis configuraciones de temperatura (de 0.0 a 1.0), generando 20 muestras por tarea.
• Estimación de Confianza: Se compararon cuatro métodos:
  1. Agregación de probabilidad de tokens: Acceso directo a las probabilidades de logits (para GPT/Gemini).
  2. Confianza verbalizada: Solicitar al modelo que produzca un JSON con una puntuación de confianza (0–1) y un razonamiento.
  3. Consistencia basada en muestreo: Estimar la confianza como la fracción de 20 muestras que pasan la verificación.
  4. Prompting de auto-consistencia: Razonamiento de Cadena de Pensamiento (CoT) antes de reportar la confianza.
• Verificación: El código se ejecutó en contenedores Docker aislados. Las etiquetas de seguridad se definieron como $y_{sec} = y_{func} \land \neg y_{vuln}$, lo que significa que el código debe pasar todas las pruebas funcionales y fallar en todas las pruebas de explotación de vulnerabilidades para ser considerado seguro.
• Métricas: Error de Calibración Esperado (ECE), Puntuación de Brier, Brecha de Sobreconfianza y tasa de Falsa Confianza (FT) (predicciones de alta confianza que son inseguras).

Estrategias de Reparación y Mitigación (RQ3 y RQ4)

• Reparación Guiada por Calibración: Un sistema de bucle cerrado filtró las muestras con baja confianza calibrada ($p_{sec} < 0.5$) para su reparación iterativa. Los resultados se estratificaron por tipo de vulnerabilidad: Reemplazo de Sumidero (SR) (que requiere cambios de API) y Cumplimiento de Restricciones (CE) (que requiere lógica de validación).
• Experimentos de Mitigación:
  1. Control de Ejecución (Execution Gating): Filtrar el código funcionalmente incorrecto antes de solicitar la confianza de seguridad.
  2. Reparación con Autorización de Ruptura: Autorizar explícitamente a los modelos para romper la compatibilidad hacia atrás (por ejemplo, reemplazar pickle con json) para corregir vulnerabilidades de SR.
  3. Prompting de Pocos Ejemplos (Few-Shot): Proporcionar ejemplos de código seguro.
  4. Few-Shot + CoT: Añadir pasos de razonamiento a los ejemplos de pocos ejemplos.

3. Resultados Clave

RQ1: Calibración en la Generación Autocontenida

• Sobreconfianza Sistemática: Todos los modelos exhiben una sobreconfianza severa. GPT-4o-mini y Qwen3-Coder-Next muestran un ECE alto (0.46–0.48 y 0.41–0.42, respectivamente), mientras que Gemini-2.0-Flash tiene un mejor desempeño pero sigue siendo sobreconfiado (ECE 0.25–0.26).
• Falsa Confianza: Con un umbral de confianza de 0.8, las tasas de Falsa Confianza son alarmantemente altas (por ejemplo, 33.5% para GPT-4o-mini, 40.3% para Qwen3-Coder-Next), lo que indica que las salidas de alta confianza son frecuentemente inseguras.
• Calibración Funcional vs. de Seguridad: Contraintuitivamente, la calibración funcional es consistentemente peor que la de seguridad ($\Delta ECE < 0$). Los modelos están más mal calibrados respecto a la corrección funcional que respecto a la seguridad. Esto sugiere que los modelos estiman los resultados de seguridad de manera más fiable que los funcionales, posiblemente porque la corrección funcional depende de comportamientos de ejecución complejos y ocultos.
• Métodos de Confianza: La agregación de probabilidad de tokens produce una pobre calibración (ECE $\approx$ 0.80). La consistencia basada en muestreo muestra un ECE cercano a cero pero carece de discriminación por muestra. La confianza verbalizada es la señal más práctica para el análisis posterior.

RQ2: Degradación a Nivel de Repositorio

• Colapso de la Calibración: Pasar de tareas autocontenidas a contextos de nivel de repositorio causa que la calibración se deteriore significativamente. El ECE aumenta aproximadamente el triple o el cuádruple (por ejemplo, el ECE de GPT-4o-mini sube de 0.41 a 0.70).
• Oleada de Falsa Confianza: Las tasas de Falsa Confianza saltan de ~17% en tareas autocontenidas a >80% en entornos de repositorio.
• Descomposición: La degradación es impulsada por dos factores: fragilidad de la construcción (el código falla al compilar/ejecutar) y complejidad entre archivos. La fragilidad de la construcción explica una gran parte del error (hasta el 82% para GPT), pero la genuina complejidad entre archivos sigue siendo un factor significativo incluso en parches que se construyen con éxito.

RQ3: Reparación Guiada por Calibración

• Eficacia Limitada: El uso de señales de calibración para guiar la reparación produce mejoras de seguridad mínimas y a menudo degrada la funcionalidad.
• Barreras Estructurales: Las vulnerabilidades de Reemplazo de Sumidero (SR) (que requieren cambios de API) tienen una tasa de éxito de reparación del 0% en todos los modelos. Los modelos no logran reemplazar las APIs inseguras, en su lugar preservan la vulnerabilidad o introducen arreglos superficiales.
• Regresiones Funcionales: Los intentos de reparación rompen frecuentemente la corrección funcional (tasas de ruptura >60%), lo que lleva a una disminución general de la tasa de seguridad. La calibración actúa como una señal de estratificación de riesgo pero no puede impulsar una reparación automatizada efectiva para vulnerabilidades estructurales.

RQ4: Estrategias de Mitigación

• Control de Ejecución (Execution Gating): La mitigación más efectiva. Filtrar el código funcionalmente incorrecto antes de solicitar la confianza de seguridad reduce el ECE entre un 31 y 39% en todos los modelos. Sin embargo, esto conlleva el alto costo de descartar entre el 46 y 86% de las muestras.
• Reparación con Autorización de Ruptura: Autorizar explícitamente los cambios de API mejora la eliminación de vulnerabilidades para GPT y Gemini (35–42%), pero sigue resultando en una alta ruptura funcional y un bajo éxito estricto.
• Técnicas de Prompting: El prompting de pocos ejemplos elimina aproximadamente el 61–65% de las vulnerabilidades, pero rara vez pasa la evaluación estricta debido a desajustes de integración estructural. Añadir razonamiento de Cadena de Pensamiento (CoT) degrada la calibración y reduce el éxito estricto a 0%.

4. Contribuciones Clave

1. Primer Estudio a Gran Escala: La primera investigación empírica de la calibración de seguridad en código generado por LLM, cubriendo 36,000 muestras a través de tres modelos, seis temperaturas y dos contextos de desarrollo distintos.
2. Análisis de Degradación de la Calibración: Cuantificación de la severa penalización de calibración incurrida al pasar de funciones aisladas a contextos realistas de nivel de repositorio, resaltando los riesgos de las dependencias entre archivos.
3. Limitaciones de la Reparación: Demostración de que la reparación guiada por calibración es poco fiable, particularmente para vulnerabilidades de Reemplazo de Sumidero (SR), debido a una "barrera de rigidez" donde los modelos no pueden realizar las transformaciones estructurales necesarias.
4. Evaluación de Mitigación: Evaluación sistemática de intervenciones arquitectónicas (control de ejecución) y a nivel de prompt, identificando el control de ejecución como la estrategia más efectiva para reducir la Falsa Confianza, aunque con altos costos de rechazo.

5. Significado y Afirmaciones

El artículo argumenta que la calibración, no solo la precisión, debe ser un criterio de evaluación central para los LLMs en entornos críticos de seguridad. Los hallazgos desafían la suposición de que "la seguridad es más difícil" para los LLMs; en cambio, el estudio revela que la calibración funcional es peor que la de seguridad, sugiriendo que la mala calibración surge en gran medida de restricciones de ejecución ocultas (fragilidad de ejecución) en lugar de una falta de conocimiento de seguridad.

Los autores afirman que:

• La confianza autorreportada es poco fiable: Las salidas de alta confianza son frecuentemente inseguras, creando un riesgo sistémico de Falsa Confianza.
• El contexto importa: Los benchmarks basados en programas autocontenidos subestiman significativamente los riesgos de despliegue, ya que la calibración se degrada drásticamente en entornos de nivel de repositorio.
• La reparación no es una solución milagrosa: Las señales de calibración pueden priorizar muestras para la revisión humana, pero actualmente no pueden impulsar una reparación automatizada fiable para vulnerabilidades estructurales.
• Guía para Profesionales: La evaluación de seguridad solo debe ocurrir después de las pruebas funcionales (control de ejecución), y las señales de confianza para la seguridad y la funcionalidad deben solicitarse por separado para evitar la contaminación por la incertidumbre de la ejecución.

El estudio concluye que, si bien los LLMs muestran cierta capacidad para autoasentarse la seguridad, su sobreconfianza e incapacidad para realizar reparaciones estructurales hacen necesaria la supervisión humana, particularmente en entornos de desarrollo complejos y de múltiples archivos.