Resumen Técnico: DualGauge

Planteamiento del Problema

Los Modelos de Lenguaje Extensos (LLMs) y los agentes de codificación basados en LLM se utilizan cada vez más para generar código a partir de especificaciones en lenguaje natural. Si bien la corrección funcional se ha convertido en el criterio dominante para evaluar estos sistemas, es insuficiente para garantizar software desplegable. Investigaciones previas indican que los asistentes de codificación por IA generan frecuentemente código inseguro, y los desarrolladores suelen aceptar estas sugerencias manteniendo la confianza en su seguridad.

Los marcos de evaluación existentes sufren dos limitaciones principales:

1. Aislamiento de Métricas: Los benchmarks funcionales (p. ej., HumanEval, LiveBench) y los benchmarks de seguridad (p. ej., SecurityEval, CodeLMSec) suelen evaluar la corrección y la seguridad de forma aislada o en diferentes conjuntos de datos. Un programa que supera las pruebas funcionales pero contiene vulnerabilidades, o viceversa, no es útil.
2. Desafíos del Oráculo de Evaluación: La evaluación de seguridad no puede depender únicamente de la coincidencia exacta de la salida. Como ilustran los ejemplos de salto de directorio (path-traversal), una implementación segura y una vulnerable pueden producir salidas e códigos de salida idénticos ante entradas adversarias. La distincción suele residir en la traza de ejecución (p. ej., si se accedió a un archivo antes de que fallara una comprobación), lo que requiere un razonamiento semántico sobre el comportamiento en tiempo de ejecución en lugar de una simple comparación de salidas.
3. Limitaciones de Contexto: La mayoría de los benchmarks dependen de la completitud de código, el contexto del repositorio o el andamiaje del framework, pasando por alto la generación de "solo especificación", donde un modelo debe implementar una función a partir de una descripción en lenguaje natural por sí sola.

Metodología: DualGauge y DualGauge-Bench

Los autores presentan DualGauge, un marco de evaluación totalmente automatizado para la evaluación conjunta de la seguridad y la funcionalidad en la generación de código de solo especificación, respaldado por DualGauge-Bench.

DualGauge-Bench

Este es un benchmark agnóstico al lenguaje que consta de 307 tareas de codificación.

• Diseño de Tareas: Cada tarea consiste en una especificación en lenguaje natural sin fragmentos de código, firmas de funciones o restricciones específicas del lenguaje.
• Pruebas Emparejadas: Cada especificación está emparejada con dos conjuntos de pruebas derivados de la misma instrucción (prompt):
  • Pruebas Funcionales: Guiadas por el análisis de valores límite y la partición de clases de equivalencia para verificar la corrección del comportamiento.
  • Pruebas de Seguridad: Guiadas por los principios de OWASP y CERT para verificar la ausencia de comportamientos inseguros (p. ej., fallos de validación de entrada, problemas de control de acceso).
• Cobertura: El benchmark abarca siete dominios de funcionalidad y 90 categorías de Common Weakness Enumeration (CWE), cubriendo tareas intraprocedimentales e interprocedimentales.
• Construcción: Los prompts fueron seleccionados de conjuntos de datos existentes (CodeGuard+, SecurityEval, Purple Llama CyberSecEval) y convertidos a especificaciones puras. Los conjuntos de pruebas se crearon mediante un proceso de co-creación humano-LLM, donde los LLMs propusieron candidatos y evaluadores humanos los validaron y extendieron.

Sistema DualGauge

El sistema opera en cuatro fases para automatizar el flujo de evaluación:

1. Generación de Muestras: El LLM o agente objetivo genera $k$ candidatos de código para una especificación dada.
2. Ejecución Agéntica: Un ejecutor guiado por LLM ejecuta los candidatos en un entorno aislado. Clasifica los fallos en problemas de entorno, de script o de código. Repara los problemas de entorno y de script (p. ej., paquetes faltantes, errores de invocación), pero no altera el código candidato en sí. Esto asegura que el programa sea ejecutable sin arreglar artificialmente la lógica del modelo.
3. Evaluación de Tiempo de Ejecución Basada en LLM:
   • Oráculo Funcional: Utiliza la coincidencia exacta de la salida contra las salidas esperadas.
   • Oráculo de Seguridad: Utiliza un LLM para realizar un juicio semántico. Analiza el código candidato, las salidas de ejecución y las trazas de cobertura frente a los comportamientos de seguridad esperados. Si el código utiliza librerías desconocidas, un modelo de resolución con capacidad de búsqueda web recupera la documentación para ayudar a la evaluación. Este paso determina si el código implementó una defensa genuina en lugar de simplemente fallar por accidente.
4. Agregación de Resultados: Calcula métricas incluyendo la tasa de paso funcional ($PR$), la tasa de paso seguro ($SPR$) y la mética conjunta secure-pass@k (la probabilidad de que una sola muestra sea tanto funcionalmente correcta como segura).

Resultados Clave

Los autores evaluaron 10 LLMs representativos (incluyendo familias de GPT-5, Claude Opus/Sonnet, Llama, Qwen y Gemma) en Python, C++ y JavaScript, así como 3 sistemas de codificación agénticos (Codex, OpenHands, Claude Code).

1. La Corrección Funcional Sobrestima la Fiabilidad

Incluso los modelos más fuertes lograron una tasa de paso funcional de casi el 39% en tareas de Python, pero la tasa de éxito conjunta de seguridad-funcionalidad (secure-pass@1) se mantuvo por debajo del 15% en todos los lenguajes. Esto indica que la corrección funcional es un mal indicador de la generación de código seguro.

2. Los Factores del Lado del Modelo No Mejoran la Ejecución Conjunta de Manera Fiable

El estudio analizó cuatro factores: escala, pensamiento extendido, cuantización y especialización en instrucciones/código.

• Escala: El aumento del tamaño del modelo mejoró la fluidez funcional, pero la cobertura de seguridad se estancó mucho antes de alcanzar los tamaños más grandes.
• Pensamiento Extendido y Especialización: Estos factores desplazaron las métricas funcionales y de seguridad de manera diferente según la familia del modelo y no mejoraron de forma fiable la métrica conjunta.
• Conclusión: La generación de código seguro y correcto no surge simplemente de una mayor capacidad de codificación; requiere la aplicación consistente del conocimiento de seguridad en todos los requisitos.

3. Los Sistemas Agénticos No Ofrecen Ventaja

El andamiaje iterativo de los agentes de codificación (Codex, OpenHands, Claude Code) no proporcionó ninguna ventaja sobre la generación directa para tareas de solo especificación.

• Mecanismo de Fallo: Los agentes dedicaron un esfuerzo significativo a la sobrecarga orientada al repositorio (p. ej., listar directorios, buscar archivos de configuración), lo que no aportó ninguna señal en un espacio de trabajo vacío.
• Bucle de Retroalimentación: Los agentes a menudo dependieron de pruebas autogeneradas en lugar de benchmarks de verdad fundamental (ground-truth). Las defensas parciales que pasaban las comprobaciones internas del agente pero fallaban las pruebas de seguridad del benchmark no fueron revisadas. En consecuencia, los agentes heredaron los mismos modos de fallo que la generación directa sin cerrar la brecha de cobertura.

4. Modos de Fallo

• Fallos Funcionales: Se concentraron en el límite del contrato de salida (p. ej., estructura JSON incorrecta, CLI vs. servicio incorrecto), no en errores algorítmicos.
• Fallos de Seguridad: Caracterizados por defensas parciales. Los modelos a menudo implementaron protecciones (regex, comprobaciones de tipo) que parecían razonables pero fallaban en cubrir el vector de ataque específico o se aplicaban en el nivel de abstracción incorrecto.
• Brecha Conjunta: Un programa podía pasar las pruebas funcionales siendo inseguro, o pasar algunas pruebas de seguridad mientras fallaba otras. Solo el benchmarking conjunto expuso de forma fiable estos fallos "silenciosos".

Significado y Reivindicaciones

El artículo afirma presentar el primer marco totalmente automatizado para evaluar conjuntamente la seguridad y la funcionalidad en la generación de código de solo especificación. Su importancia radica en:

1. Revelar la Brecha: Demostrar que los modelos y agentes de vanguardia actuales luchan por satisfacer la corrección y la seguridad simultáneamente, manteniendo las tasas de éxito conjunto críticamente bajas (<15%).
2. Cambio Metodológico: Argumentar que la evaluación de seguridad requiere un razonamiento semántico sobre las trazas de ejecución en lugar de la coincidencia de salidas, y que los benchmarks deben emparejar pruebas funcionales y de seguridad para la misma especificación.
3. Limitaciones de los Agentes: Mostrar que el refinamiento de múltiples turnos y el uso de herramientas aún no superan automáticamente el desafío central de producir código seguro cuando no hay un código base existente o un ejecutor de pruebas que guíe al agente.
4. Estándar de Benchmark: Proporcionar un benchmark agnóstico al lenguaje y reutilizable (DualGauge-Bench) que va más allá de la completitud de código para probar la capacidad fundamental de los modelos para traducir la intención del lenguaje natural en código seguro y correcto.

Los autores concluyen que la generación de código seguro requiere la aplicación consistente del conocimiento de seguridad en todo el espacio de los requisitos, una capacidad que los modelos y agentes actuales aún no han dominado. Enfatizan que sus resultados son estimaciones de benchmark escalables y que la revisión humana de seguridad sigue siendo necesaria.