Resumen Técnico: AUTOBAXBUILDER

Enunciado del Problema

A medida que los Modelos de Lenguaje Grandes (LLM) se integran cada vez más en la ingeniería de software, la evaluación fiable de la corrección y la seguridad del código generado por LLM se ha vuelto crítica. Investigaciones anteriores indican que los LLM generan frecuentemente código con vulnerabilidades de seguridad, a menudo descuidando la seguridad en favor de la corrección funcional. Los marcos de evaluación existentes adolecen de tres limitaciones principales:

1. Contaminación de Datos: Las pruebas de referencia (benchmarks) elaboradas manualmente inevitablemente se filtran en los datos de entrenamiento de modelos futuros, comprometiendo la validez de la evaluación.
2. Escalabilidad y Extensibilidad: Crear nuevas pruebas de referencia requiere un esfuerzo humano significativo para diseñar escenarios, escribir pruebas funcionales y desarrollar exploits de seguridad, lo que dificulta mantener el ritmo con modelos que mejoran rápidamente.
3. Dificultad de Escalar: Las pruebas de referencia deben aumentar continuamente en dificultad para desafiar a LLM más capaces, una tarea que consume muchos recursos para expertos humanos.

Las pruebas de referencia actuales suelen evaluar la corrección y la seguridad en tareas separadas o se centran únicamente en la generación a nivel de función, fallando en capturar las complejidades de los backends completos de aplicaciones. Aunque la prueba de referencia BAXBENCH abordó esto evaluando backends de aplicaciones web de extremo a extremo, su creación dependió en gran medida del esfuerzo humano manual, limitando su longevidad y escalabilidad.

Metodología: AUTOBAXBUILDER

Los autores proponen AUTOBAXBUILDER, una pipeline automatizada y agéntica que inicia la creación de tareas de evaluación de seguridad de código desde cero. El sistema aprovecha las capacidades de comprensión de código de los LLM combinadas con verificaciones robustas de fiabilidad basadas en la ejecución para generar especificaciones de escenarios, pruebas funcionales y exploits de seguridad de extremo a extremo sin intervención humana.

La pipeline opera en tres pasos iterativos de refinamiento, orquestados por un LLM central (el "Orquestador") y validados frente a soluciones de referencia generadas por "LLM de Solución":

1. Propuesta de Escenario: El orquestador genera una especificación de servicio backend novedosa (en formato OpenAPI) diseñada para exponer una superficie de ataque clara. Asegura la novedad verificando contra títulos de escenarios existentes. Los LLM de Solución generan luego implementaciones de referencia iniciales.
2. Generación de Pruebas Funcionales: El orquestador extrae requisitos funcionales y construye pruebas funcionales. Para asegurar la corrección, la pipeline emplea un bucle de refinamiento de dos fases:
   • Refinar Soluciones: Las soluciones de referencia que fallan se corrigen basándose en registros de ejecución, sin que el orquestador vea el código de prueba para evitar el sobreajuste.
   • Refinar Pruebas: El orquestador analiza la relación entre el código de prueba, el código de solución y los registros de ejecución para determinar si un fallo proviene de una prueba defectuosa o de una solución defectuosa. Itera hasta alcanzar un consenso global, asegurando que al menos una solución de referencia supere todas las pruebas.
3. Generación de Exploits de Seguridad: El orquestador identifica vulnerabilidades potenciales (CWE) en el escenario y en las soluciones de referencia. Para cada vulnerabilidad objetivo, genera un exploit y lo valida utilizando un enfoque contrastivo:
   • El exploit se ejecuta sobre una solución de referencia.
   • Si el resultado es correcto (por ejemplo, una solución vulnerable es señalada), el orquestador genera una solución "contrastiva" mediante la corrección de la vulnerabilidad o su introducción, basándose únicamente en la descripción en lenguaje natural de la vulnerabilidad (no en la lógica del exploit).
   • El exploit se acepta solo si distingue correctamente entre las versiones segura e insegura de la solución. Este proceso itera hasta encontrar un par preciso de soluciones segura/insegura.

La pipeline incluye salvaguardas como la verificación YAML para especificaciones OpenAPI, comprobaciones de compilación de Python para código y mecanismos de autocrítica para manejar fallos de los LLM.

Contribuciones Clave

1. Construcción Automatizada de Benchmarks: Un método robusto para construir completamente nuevos benchmarks siguiendo los principios de diseño de BAXBENCH con mínima intervención humana.
2. Validación frente a Líneas Base Expertas: Demostración de que el método reproduce o supera las pruebas funcionales y exploits escritos por expertos en las mismas tareas, estrechando efectivamente el límite superior de seguridad reportado por BAXBENCH.
3. AUTOBAXBENCH: La construcción y publicación de un nuevo benchmark compuesto por 40 escenarios novedosos, divididos en tres subconjuntos de dificultad creciente (Fácil, Medio, Difícil), que duplica más que los escenarios backend disponibles para la evaluación de seguridad de código.

Resultados Experimentales

Los autores evaluaron la pipeline y el resultado benchmark AUTOBAXBENCH utilizando una amplia gama de LLM de última generación (incluyendo GPT-5, Claude 4.5 Sonnet, Gemini 3 Pro y varios modelos de pesos abiertos).

• Validación de la Pipeline: Cuando se aplicó a escenarios existentes de BAXBENCH, las pruebas y exploits generados por AUTOBAXBUILDER mostraron un alto acuerdo con los escritos por humanos. Específicamente, las pruebas funcionales coincidieron en el 80,9% de las soluciones. Los exploits de seguridad generados por la pipeline señalaron más instancias como inseguras que los exploits originales escritos por humanos, atribuido al descubrimiento de CWE adicionales y variantes de ataque. La auditoría manual de 71 exploits generados encontró solo un exploit no sólido.
• Rendimiento del Benchmark: En AUTOBAXBENCH, incluso el modelo evaluado más fuerte (Claude 4.5 Sonnet) logró un sec_pass@1 general (proporción de soluciones seguras y correctas) de solo el 36%. En la división "Difícil", esto bajó al 25%. La brecha entre pass@1 (corrección funcional) y sec_pass@1 destaca que muchas implementaciones funcionalmente correctas siguen siendo explotables.
• Eficiencia: La pipeline genera nuevas tareas en menos de 2 horas con un costo de API de menos de 4 dólares por tarea. Incluyendo la verificación manual, esto reduce el esfuerzo humano en un factor de 12 comparado con la construcción manual.
• Robustez: Estudios de ablación utilizando conjuntos disjuntos de modelos para la construcción mostraron una alta correlación de rangos (Spearman $\rho > 0.9$) en el rendimiento de los modelos, indicando que el benchmark no está sesgado hacia los modelos utilizados para generarlo.

Significado y Afirmaciones

El artículo afirma que AUTOBAXBUILDER aborda el desafío crítico de la contaminación y la escalabilidad en la evaluación de seguridad de LLM. Al automatizar la generación de benchmarks no contaminados y de alta calidad, el marco permite una evaluación a largo plazo y fiable de las capacidades de codificación segura de los LLM.

Los autores enfatizan que su método proporciona un límite superior sólido en seguridad mediante el uso de exploits basados en ejecución en lugar de análisis estático, que es propenso a falsos positivos y negativos. Afirman que el marco es "a prueba de futuro", capaz de generar tareas cada vez más difíciles a medida que mejoran las capacidades de los modelos, acercándose a la complejidad de las APIs de backend desplegadas. El trabajo concluye que, aunque los LLM han avanzado en la generación de código funcional, persiste una brecha significativa en su capacidad para generar código seguro de manera fiable, una brecha que AUTOBAXBENCH expone efectivamente.