Resumen Técnico: WildCode Revisited

Planteamiento del Problema

La rápida adopción de Modelos de Lenguaje Extensos (LLMs) para la generación de código ha superado la evaluación de la seguridad y la calidad del código resultante. Estudios previos han dado la alarma sobre las vulnerabilidades en el código generado por LLMs, pero se centran predominantemente en prompts sintéticos o benchmarks controlados. Estos escenarios artificiales pueden no reflejar con precisión las interacciones reales de los desarrolladores, las intenciones de los usuarios o la postura de seguridad real del código producido en entornos de producción. Además, existe una falta de datos empíricos sobre si los usuarios solicitan activamente código seguro o si permanecen inconscientes de los riesgos de seguridad al interactuar con los LLMs.

Metodología

Este estudio presenta el primer análisis empírico a gran escala del código generado por ChatGPT basado en interacciones de usuarios del mundo real. La investigación aprovecha el conjunto de datos WildChat, un repositorio público de más de un millón de conversaciones anonimizadas con ChatGPT recopiladas entre abril de 2023 y mayo de 2024.

La metodología consistió en las siguientes etapas clave:

1. Construcción del Conjunto de Datos: De 837,989 conversaciones, los autores extrajeron 82,843 que contenían código generado por el modelo. Filtraron las conversaciones en lengua inglesa (34,478) para facilitar la verificación manual y el procesamiento de lenguaje natural, creando el conjunto de datos WildCode_EN. Los fragmentos de código fueron clasificados por lenguaje de programación utilizando un modelo de identificación dedicado y validados mediante verificadores de sintaxis específicos de cada lenguaje (por ejemplo, py_compile, eslint, javac).
2. Análisis de Seguridad: Los autores emplearon OpenGrep, una herramienta de análisis estático de código abierto con un conjunto de reglas personalizadas de 648 reglas mapeadas a categorías de Enumeración de Debilidades Comunes (CWE). Analizaron el código en busca de vulnerabilidades específicas, incluyendo funciones criptográficas de hash débiles, inyección SQL, generación de números aleatorios débiles, ataques de deserialización, problemas de seguridad de memoria (específicamente en C/C++) y Denegación de Servicio por Expresiones Regulares (ReDoS).
3. Detección de Alucinaciones y Secretos:
   • Alucinaciones: Se desarrolló un pipeline para detectar "alucinaciones de paquetes" (importaciones de librerías inexistentes) en Python y JavaScript, contrastando las importaciones con los repositorios oficiales de PyPI y NPM.
   • Secretos: Se utilizó una combinación de filtrado por regex y un clasificador LightGBM para distinguir entre secretos de marcador de posición (placeholders) y claves de API reales expuestas en los prompts de los usuarios.
4. Experimento de Re-prompting: Para evaluar la eficacia de la ingeniería de prompts, se reenviaron 1,126 prompts originales del conjunto de datos WildChat a cinco LLMs diferentes (OpenAI, Cohere y Alibaba Cloud) bajo cuatro condiciones: Original, Act_as_security_researcher, Be_aware_of_security_issues y Opengrep_log (proporcionando feedback de análisis estático).
5. Análisis de la Intención del Usuario: Utilizando clasificación zero-shot (BART-large-mnli), los autores categorizaron las consultas de los usuarios (iniciales y de seguimiento) para comprender sus intenciones, tales como corrección de errores (bug fixing), generación de código o codificación segura.
6. Análisis Estadístico: El estudio utilizó Puntuaciones de Riesgo de Seguridad Normalizadas (NSRS), divergencia de Kullback–Leibler (KL) para el análisis de distribución, pruebas de Chi-cuadrado y pruebas de Kruskal–Wallis para determinar la significancia estadística de los efectos de la ingeniería de prompts.

Contribuciones Clave

• Conjunto de Datos Empírico del Mundo Real: La creación y publicación de WildCode, un conjunto de datos curado de conversaciones y fragmentos de código anotados de interacciones reales de usuarios, abordando la amenaza de validez de los benchmarks sintéticos.
• Auditoría de Seguridad Integral: Un análisis a gran escala de vulnerabilidades de seguridad en múltiples lenguajes de programación (Python, Java, C/C++, JavaScript, PHP, C#) utilizando análisis estático sobre datos auténticos.
• Caracterización de la Intención del Usuario: Una investigación sobre el comportamiento del usuario, revelando que la seguridad rara vez es una preocupación primordial en las consultas de los usuarios, incluso cuando interactúan con código con errores.
• Evaluación de la Ingeniería de Prompts: Una evaluación experimental de cómo las estrategias comunes de ingeniería de prompts (juego de roles, advertencias explícitas y bucles de retroalimentación) impactan la seguridad del código generado a través de diferentes arquitecturas de modelos.
• Análisis de Rechazo: Una categorización de los comportamientos de rechazo del modelo y una investigación sobre la "elusión de rechazo" (refusal circumvention), donde los usuarios logran sortear las restricciones de seguridad para generar código tras un rechazo inicial.

Resultados Clave

Vulnerabilidades de Seguridad

• Hallazgos Generales: El código generado por LLM contiene frecuentemente vulnerabilidades de seguridad. El estudio respalda hallazgos previos que indican que la corrección funcional no implica seguridad.
• Vulnerabilidades Específicas:
  • Funciones de Hash: El 20.61% de las conversaciones que involucraban funciones de hash activaron reglas para algoritmos débiles (por ejemplo, MD5, SHA1).
  • Inyección SQL: Se observó una tasa de vulnerabilidad del 3.93%, siendo Python (SQLAlchemy) y PHP contribuyentes notables.
  • Deserialización: El 100% de las instancias detectadas de deserialización en Java se consideraron vulnerables debido a la falta de controles de seguridad.
  • Seguridad de Memoria: El 14.85% de los fragmentos de C/C++ contenían funciones inseguras (por ejemplo, scanf, strcpy, gets).
  • ReDoS: Aproximadamente el 29.4% de las expresiones regulares en el conjunto de datos fueron marcadas como susceptibles a ataques ReDoS por las herramientas de detección.
• Alucinaciones: El estudio identificó un 14.4% de módulos de Python alucinados y un 3.5% de paquetes de JavaScript alucinados en modelos antiguos. Los modelos más nuevos mostraron tasas de alucinación reducidas, pero aún generaron paquetes ficticios.
• Secretos: Se encontraron claves de API y credenciales reales en los prompts de los usuarios, incluso después de filtrar los marcadores de posición.

Efectividad de la Ingeniería de Prompts

• Feedback de Análisis Estático: El prompt Opengrep_log (que proporciona al modelo los resultados previos del análisis estático) produjo consistentemente las Puntuaciones de Riesgo de Seguridad Normalizadas (NSRS) más bajas en la mayoría de los modelos, lo que indica que los bucles de retroalimentación reducen significativamente la severidad de las vulnerabilidades.
• Juego de Roles (Role-Playing): El prompt Act_as_security_researcher no mejoró consistentemente los resultados de seguridad y, en algunos casos, resultó en puntuaciones de riesgo más altas en comparación con el baseline.
• Significancia Estadística: Las pruebas estadísticas confirmaron que las estrategias de prompts influyen significativamente tanto en la distribución de las categorías de vulnerabilidad como en sus niveles de severidad, aunque el tamaño del efecto (Cramér's V) es modesto.

Intención y Comportamiento del Usuario

• Brecha de Conciencia de Seguridad: Los usuarios rara vez priorizan la seguridad. "Codificación Segura" fue una categoría extremadamente rara tanto en las consultas iniciales como en las de seguimiento.
• Reacción ante Errores (Bugs): Cuando los usuarios encontraban código con errores, se centraban predominantemente en corregir el error o explicar el código, en lugar de abordar las implicaciones de seguridad subyacentes.
• Valores por Defecto de Lenguaje: Cuando los usuarios no especificaban un lenguaje, ChatGPT optaba mayoritariamente por Python.
• Elusión de Rechazo: Aunque los modelos rechazaron la generación de código malicioso (por ejemplo, malware, actividades ilegales) en muchos casos, generaron frecuentemente código vulnerable. Los usuarios eludieron con éxito los rechazos de seguridad en un subconjunto de casos (por ejemplo, 40 de 152 casos de rechazo por "ilegalidad" resultaron en la generación de código).

Significado y Reivindicaciones

El artículo afirma proporcionar la primera evidencia empírica a gran escala de que el código generado por LLM es frecuentemente insuficiente en términos de seguridad cuando deriva de patrones de uso del mundo real. Los autores sostienen que sus hallazgos validan las preocupaciones planteadas anteriormente por estudios que utilizan datos sintéticos, confirmando que los riesgos están presentes en las interacciones auténticas de los desarrolladores.

Crucialmente, el estudio destaca un desconexión entre la intención del usuario y la seguridad: los usuarios no preguntan mucho sobre las características de seguridad del código que solicitan, y rara vez dan seguimiento a los problemas de seguridad cuando se les presenta código con errores. Esto sugiere que confiar en los prompts de los usuarios para imponer la seguridad es ineficaz.

Los autores concluyen que existe una necesidad urgente de LLMs conscientes de la seguridad y salvaguardas proactivas dentro de las herramientas de codificación generativa, ya que las estrategias actuales de ingeniería de prompts (como el juego de roles) son insuficientes por sí solas. Enfatizan que, si bien la ingeniería de prompts (específicamente los bucles de retroalimentación) puede mitigar la severidad, no elimina fundamentalmente el comportamiento de vulnerabilidad de los LLMs. El estudio sirve como un llamado a la acción para integrar controles de seguridad directamente en el pipeline de generación en lugar de depender de la verificación post-hoc del usuario.