🤖 AI

SecRepoBench: Benchmarking Code Agents for Secure Code Completion in Real-World Repositories

Este artículo presenta SecRepoBench, un nuevo benchmark que evalúa agentes de código en repositorios reales y demuestra que, aunque los modelos de lenguaje grandes tienen dificultades para generar código seguro, los agentes de código superan significativamente a estos modelos en tareas de completado seguro.

Autores originales: Chihao Shen, Connor Dilgren, Purva Chiniya, Luke Griffith, Yu Ding, Yizheng Chen

Publicado 2026-02-17

📖 4 min de lectura☕ Lectura para el café

CC BY 4.0

Autores originales: Chihao Shen, Connor Dilgren, Purva Chiniya, Luke Griffith, Yu Ding, Yizheng Chen

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que estás construyendo una casa muy compleja (un programa de software) con la ayuda de un arquitecto asistente muy inteligente (una Inteligencia Artificial o IA). Este arquitecto puede escribir los planos para nuevas habitaciones o reparar grietas en las paredes.

El problema es que, aunque este arquitecto es genial escribiendo planos, a veces comete errores graves: puede poner una ventana donde no debería, usar materiales que se rompen con el viento o dejar una puerta abierta que cualquier ladrón puede usar. En el mundo de la informática, esto se llama vulnerabilidad de seguridad.

Aquí es donde entra el papel SecRepoBench.

¿Qué es SecRepoBench? (El "Examen de Seguridad Real")

Los investigadores crearon un examen especial llamado SecRepoBench. Piensa en él como un campo de entrenamiento de élite para probar a estos arquitectos (las IAs) en situaciones reales, no en ejercicios de práctica.

El escenario: En lugar de pedirle a la IA que invente un programa desde cero, le dan una casa ya construida (un repositorio de código real de C/C++ que usan millones de personas) y le dicen: "Aquí hay una habitación a medio terminar. Tienes que completarla sin romper nada y sin dejar puertas abiertas".
La prueba: Una vez que la IA escribe el código, los investigadores hacen dos cosas:
1. Prueba de Funcionamiento: ¿La habitación sirve para lo que debe? (¿Se puede abrir la puerta? ¿Funciona la luz?). Si no, el trabajo está mal hecho.
2. Prueba de Seguridad: ¿Hay algún ladrón que pueda entrar? Usan herramientas automáticas para intentar "romper" la habitación. Si la IA dejó una ventana rota, la prueba falla.

¿Qué descubrieron? (Las Sorpresas)

Los investigadores pusieron a prueba a 29 arquitectos individuales (modelos de IA puros) y a 15 equipos de arquitectos (agentes de IA que pueden buscar en toda la casa, revisar planos antiguos y usar herramientas).

Aquí están los hallazgos principales, explicados con analogías:

Los "Solitarios" se pierden: Los arquitectos individuales (modelos de IA que solo escriben sin investigar) se equivocaron mucho. A menudo, escribían planos que parecían bonitos pero que no funcionaban o que eran inseguros. Fue como pedirle a alguien que repare un motor de coche sin tener acceso al manual de instrucciones; adivinaron y fallaron.
- Resultado: El mejor arquitecto individual solo logró un trabajo perfecto y seguro en el 39% de los casos.
Los "Equipos" son mejores, pero no perfectos: Cuando dieron a la IA un "equipo" (un agente que puede navegar por toda la casa, leer otros archivos y usar herramientas), ¡mejoraron mucho!
- La analogía: Es como si, en lugar de solo escribir el plano, el arquitecto pudiera caminar por la obra, preguntar al fontanero y revisar los cimientos antes de escribir.
- El problema: Aunque los equipos escribieron planos que funcionaban mucho mejor, a veces seguían dejando puertas abiertas. Priorizaron que la habitación funcionara (que la luz se encendiera) sobre que fuera segura (que nadie pudiera entrar).
El examen es más difícil de lo que pensábamos: Compararon este nuevo examen (SecRepoBench) con exámenes anteriores. Resultó que los exámenes viejos eran como "pistas de entrenamiento" fáciles. SecRepoBench es como un terreno de guerra real. Las IAs que aprobaban los exámenes viejos con notas perfectas, aquí se quedaron atascadas.
El error más común: Alucinaciones: A veces, la IA inventaba cosas que no existían. Por ejemplo, intentaba usar un tornillo o una herramienta que no estaba en la caja de herramientas del proyecto. Esto hacía que el código ni siquiera se pudiera compilar (la casa no se podía construir).

¿Por qué importa esto?

Hoy en día, millones de desarrolladores usan estas IAs para escribir código. Si la IA escribe código inseguro, las aplicaciones que usamos todos los días (bancos, redes sociales, sistemas de salud) pueden tener agujeros por donde entran los hackers.

SecRepoBench nos dice: "Oigan, estas IAs son muy inteligentes, pero todavía necesitan aprender a ser más cuidadosas. No basta con que el código funcione; tiene que ser seguro".

En resumen

Imagina que SecRepoBench es un entrenador de seguridad muy estricto que le dice a las IAs: "No me importa si tu código es rápido o bonito. Si dejas una puerta abierta para los hackers, repruebas".

El estudio nos enseña que, aunque las IAs están mejorando y los "equipos" de IA son mejores que los "solitarios", todavía tienen un largo camino por recorrer para ser verdaderos expertos en seguridad en el mundo real.

1. El Problema

El desarrollo de software asistido por Agentes de Código impulsados por Modelos de Lenguaje Grande (LLM) ha aumentado la productividad, pero introduce riesgos significativos de seguridad. Aunque existen numerosos benchmarks para evaluar la seguridad del código generado por LLMs, la literatura actual presenta dos limitaciones críticas al evaluar agentes de código en repositorios reales:

Falta de evaluación dual (Correctitud + Seguridad): La mayoría de los benchmarks existentes evalúan o bien la corrección funcional o la seguridad, pero rara vez ambas simultáneamente en el mismo conjunto de datos. Evaluar solo la seguridad sin verificar la corrección funcional puede llevar a una sobreestimación de la seguridad del código (un código puede ser "seguro" pero no funcional).
Contexto de repositorio limitado: Los benchmarks actuales a menudo proporcionan un método fijo de recuperación de contexto o solicitan la generación de programas autocontenidos. Esto no refleja la realidad de los agentes de código modernos, que pueden navegar por todo el repositorio, buscar definiciones de funciones y entender la estructura de directorios para completar tareas de código.

2. Metodología: SecRepoBench

Los autores introducen SecRepoBench, un benchmark de nivel de repositorio diseñado para evaluar la capacidad de completar código de manera segura y correcta en proyectos C/C++ reales.

Construcción del Dataset:
- Se basa en el conjunto de datos ARVO, que contiene más de 5,000 vulnerabilidades reproducibles identificadas por Google OSS-Fuzz.
- Se seleccionaron 318 tareas de completado de código de 27 repositorios populares de GitHub (C/C++), cubriendo 15 CWE (Clases de Debilidad Común).
- Proceso de Filtrado: Se identificaron regiones sensibles a la seguridad basadas en commits de parches reales. Se seleccionaron tareas donde el parche modificaba una sola función.
- Enmascaramiento y Mutación: Se generó un bloque de código enmascarado cubriendo los cambios críticos de seguridad. Para evitar que los modelos memoricen el código de entrenamiento, se aplicó una mutación semántica (renombrado de variables locales) verificada manualmente.
- Descripciones Neutrales: Se generaron descripciones de la tarea que explicaban la funcionalidad sin revelar instrucciones específicas de seguridad, simulando un escenario real donde el desarrollador no sabe de antemano qué vulnerabilidad existe.
Evaluación:
- Correctitud Funcional: Se utilizan pruebas unitarias escritas por desarrolladores existentes en el repositorio. Si el código generado pasa todas las pruebas relevantes que pasó el parche original (ground truth), se considera correcto.
- Seguridad: Se utilizan casos de prueba de seguridad (PoC) de OSS-Fuzz. Si el código generado, al compilarse y ejecutarse con el PoC, provoca un fallo (crash), se considera vulnerable. Si no falla, se considera seguro.
- Métricas: Se utiliza secure-pass@k (probabilidad de que al menos una de $k$ generaciones sea correcta y segura) y pass@k (solo corrección). En el estudio, $k=1$ .

3. Contribuciones Clave

Nuevo Benchmark de Alta Dificultad: SecRepoBench es el primer benchmark que evalúa simultáneamente la corrección funcional y la seguridad en tareas de completado de código dentro de repositorios reales completos, superando en dificultad a benchmarks anteriores como BaxBench.
Evaluación de Agentes vs. LLMs Aislados: Proporciona una comparación exhaustiva entre 29 LLMs independientes (con recuperadores de contexto estáticos) y 15 configuraciones de agentes de código (usando frameworks como OpenHands, Aider y Claude Code) que tienen acceso interactivo al repositorio.
Análisis de Fallos: Identifica patrones específicos de error, como la alucinación de identificadores no declarados y la incapacidad de implementar comprobaciones de seguridad correctas incluso cuando se logra la funcionalidad.

4. Resultados Principales

Dificultad del Benchmark: Los modelos más avanzados (SOTA) luchan significativamente en SecRepoBench. El mejor modelo independiente, GPT-5, alcanzó un 39.3% en secure-pass@1. Esto es notablemente inferior a su rendimiento en BaxBench (53.8%), demostrando que la capacidad de generar programas seguros y autocontenidos no se generaliza bien a repositorios complejos.
Ventaja de los Agentes: Los agentes de código superan significativamente a los LLMs independientes. La mejor configuración (OpenHands + OpenAI o3) logró un 53.5% en secure-pass@1.
La Brecha entre Corrección y Seguridad:
- La mejora principal de los agentes proviene de generar código más correcto (mejora promedio de pass@1 del 18.3%).
- La mejora en la seguridad es mucho menor (mejora promedio de porcentaje seguro del 14.5%).
- Esto indica que los agentes priorizan la funcionalidad pero carecen de mecanismos robustos para identificar y mitigar vulnerabilidades que introducen durante la generación.
Modelos de Razonamiento: Los modelos con capacidades de razonamiento (como OpenAI o3, Claude Sonnet 4.5 Thinking) tienden a superar a los modelos no de razonamiento, aunque la calidad del mecanismo de razonamiento es crucial.

Análisis de Fallos Específicos:

Errores de Compilación: Los agentes a menudo alucinan nombres de variables, miembros de estructuras o macros que no existen (27 tareas con errores de compilación).
Correcto pero Inseguro: El patrón más común de fallo de seguridad es la falta de comprobaciones condicionales necesarias (ej. no verificar límites de índices) o implementaciones incorrectas de dichas comprobaciones.

5. Significado e Impacto

Estándar de Evaluación Realista: SecRepoBench establece un nuevo estándar para evaluar la seguridad del código generado por IA, alineándose con flujos de trabajo reales de desarrollo (IDEs, repositorios completos) en lugar de ejercicios académicos aislados.
Dirección Futura: Los resultados sugieren que, aunque los agentes de código son una mejora necesaria sobre los LLMs puros, aún hay un camino largo por recorrer para garantizar la seguridad. La investigación futura debe centrarse en mejorar la capacidad de los agentes para realizar verificaciones de seguridad rigurosas sin sacrificar la funcionalidad, y en reducir las alucinaciones de elementos de código.
Relevancia para la Industria: Dado que los errores de seguridad en C/C++ (como desbordamientos de búfer) son críticos, este benchmark ofrece una herramienta vital para medir el progreso real de las herramientas de IA en entornos de producción.

En resumen, el artículo demuestra que, aunque los agentes de código representan un avance significativo, la generación de código que sea simultáneamente funcional y seguro en repositorios reales sigue siendo un desafío mayor para la inteligencia artificial actual.