Resumen Técnico: Código Correcto, Dependencias Vulnerables

Enunciado del Problema

Los Modelos de Lenguaje Grande (LLM) se han vuelto integrales en los flujos de trabajo de desarrollo de software, generando rutinariamente código que incluye importaciones de bibliotecas de terceros (TPL) anotadas con identificadores de versión específicos. Aunque la investigación previa ha estudiado extensamente la seguridad lógica del código generado (por ejemplo, vulnerabilidades CWE) y la existencia de nombres de paquetes alucinados, la dimensión de versión permanece en gran medida inexplorada. Específicamente, se desconoce si las versiones de lanzamiento específicas de bibliotecas correctamente nombradas recomendadas por los LLM son seguras, compatibles o incluso válidas.

Este trabajo identifica una superficie de riesgo crítica: los LLM pueden generar código sintácticamente correcto que fija una versión de biblioteca que porta Vulnerabilidades y Exposiciones Conocidas (CVE) o que es incompatible con el uso de API generado. Dado que estas decisiones se toman implícitamente a gran escala durante la generación de código, pueden propagar silenciosamente riesgos de seguridad sistémicos y fallos de instalación en proyectos aguas abajo.

Metodología

Los autores presentan PinTrace, el primer estudio de medición a gran escala de las versiones de bibliotecas especificadas por LLM. El estudio evalúa 10 LLM diversos (incluyendo modelos de código cerrado como GPT-5.4 y modelos de código abierto como Qwen3 y Llama-4) en un conjunto de referencia curado de 1.000 tareas de programación reales de Stack Overflow.

Diseño Experimental

El estudio emplea dos modos de prompting para reflejar las interacciones comunes de los desarrolladores:

1. Modo Inline: El LLM anota las importaciones con comentarios de versión (por ejemplo, import lib # version==x.y.z).
2. Modo Explícito: El LLM genera un archivo de manifiesto requirements.txt junto con el código.

La tubería de análisis consta de cinco etapas:

1. Generación: Producción de código para cada tarea bajo ambos modos.
2. Extracción: Análisis sintáctico de referencias a bibliotecas y especificadores de versión.
3. Validación: Verificación contra PyPI para asegurar que las versiones son lanzamientos publicados (filtrando alucinaciones).
4. Verificación de Vulnerabilidades: Cruce de versiones válidas contra la base de datos de Vulnerabilidades de Código Abierto (OSV) para identificar CVEs y severidad CVSS.
5. Verificación de Compatibilidad:
   • Estática: Intento de instalación en entornos virtuales aislados y ejecución de verificación de tipos estática (ty).
   • Dinámica: Ejecución de suites de pruebas del conjunto de referencia BigCodeBench para verificar la corrección en tiempo de ejecución.

El estudio también incluye comprobaciones de robustez a través de versiones de Python (3.8–3.14), un experimento de diagnóstico que sustituye versiones vecinas para aislar las causas de los fallos, y sondas de mitigación que prueban instrucciones de seguridad y anclaje de versiones externo.

Contribuciones Clave

1. Estudio de Medición: Una evaluación exhaustiva del comportamiento de especificación de versiones, validez, exposición a vulnerabilidades y compatibilidad en 10 modelos y 1.000 tareas.
2. Evidencia de Sesgo Sistémico: Prueba empírica de que los LLM convergen hacia un pequeño conjunto de versiones riesgosas y desactualizadas en diferentes familias de modelos, impulsado por un sesgo en la señal de entrenamiento en lugar de errores aislados del modelo.
3. Diagnóstico de Causa Raíz: Un experimento controlado que establece que los fallos de instalación son atribuibles principalmente a la selección de versión (elegir versiones incompatibles/antiguas) en lugar de defectos en la lógica del código generado.
4. Análisis de Mitigación: Una caracterización de intervenciones a nivel de prompt, demostrando que las instrucciones de seguridad en lenguaje natural son ineficaces, mientras que el anclaje de versiones externo reduce significativamente los riesgos.
5. Recursos Abiertos: Liberación del conjunto de datos PinTrace y la tubería de evaluación para investigación reproducible.

Resultados Clave

1. Comportamiento de Especificación de Versiones (RQ1)

• Facilidad de Formato: La anotación de versiones está impulsada por el formato de salida, no por la intención de ingeniería. En Modo Inline, los modelos especifican versiones para el 26,83%–95,18% de las referencias. En Modo Explícito (generación de manifiesto), esto cae al 6,45%–59,19%, con muchos modelos omitiendo versiones por completo.
• Convergencia: Los modelos convergen hacia una banda estrecha de lanzamientos populares. Por ejemplo, requests==2.31.0 y django==6.0.1 son especificados por casi todos los modelos.
• Retraso Temporal: Las versiones especificadas se retrasan respecto a los cortes de conocimiento del modelo entre 9 y 31 meses. Los modelos seleccionan preferentemente versiones más antiguas que han acumulado más señal de entrenamiento.
• Validez: Aunque la mayoría de las versiones especificadas en línea son válidas, el 7%–16% son alucinadas (lanzamientos PyPI inválidos), a menudo debido a omisiones de sufijos (por ejemplo, 4.8.0 en lugar de 4.8.0.74).

2. Exposición a Vulnerabilidades (RQ2)

• Alta Exposición: Bajo prompting inline, el 36,70%–55,70% de las tareas contienen al menos una versión con una CVE conocida.
• Severidad: El 62,75%–74,51% de estas versiones vulnerables se clasifican con severidad Crítica o Alta.
• Evitabilidad: En el 72,27%–91,37% de los casos, las CVE asociadas fueron divulgadas públicamente antes del corte de conocimiento del modelo, lo que indica que la exposición es evitable pero no reconocida por el modelo.
• Riesgo Estructural: El 95,11% de los pares (biblioteca, versión) vulnerables no tienen una alternativa libre de CVE dentro de la misma rama de versión mayor, lo que significa que las actualizaciones de parche simples no pueden resolver el riesgo.

3. Compatibilidad (RQ3)

• Compatibilidad Estática: Las tasas oscilan entre 19,70% y 63,20% en modo inline. La causa dominante de fallo es el error de instalación de dependencias, a menudo debido a la ausencia de distutils en entornos Python 3.12+ (una consecuencia de seleccionar versiones más antiguas).
• Compatibilidad Dinámica: Las tasas de aprobación colapsan al 6,49%–48,62% en modo inline. La mayoría de las tareas fallan antes de la ejecución debido a errores de instalación.
• Diagnóstico: Un experimento de sustitución confirmó que cambiar la versión especificada por el LLM por un lanzamiento vecino resuelve los fallos de instalación en el 17,19%–55,00% de los casos, demostrando que la lógica del código suele ser sólida pero la elección de versión es defectuosa.

4. Mitigación

• Prompting: Añadir instrucciones de seguridad en lenguaje natural ("evitar versiones vulnerables") produce una mejora insignificante (<2,2% de reducción en la exposición).
• Anclaje Externo: Inyectar versiones seguras precalculadas en el prompt reduce significativamente la exposición a vulnerabilidades (hasta ~10–27%) y mejora la compatibilidad estática al 80%–93%.

Significado y Afirmaciones

El trabajo argumenta que la selección de versiones por LLM es una superficie de riesgo de primera clase, previamente pasada por alto. Los hallazgos revelan que:

1. El riesgo es sistémico, no idiosincrásico: La convergencia hacia las mismas versiones vulnerables en todas las familias de modelos indica un sesgo compartido en la señal de entrenamiento, lo que hace imposible mitigarlo simplemente cambiando de modelo.
2. El problema es una brecha de fundamentación, no una brecha de alineación de seguridad: Dado que la mayoría de las CVE eran conocidas antes del entrenamiento, el fallo reside en la incapacidad del modelo para mapear identificadores de versión a su estado de seguridad en el momento de la inferencia.
3. El prompting es insuficiente: Las instrucciones en lenguaje natural no pueden cerrar la brecha entre la selección de versiones y el conocimiento de seguridad.
4. Se requiere herramientas externas: Los autores concluyen que abordar este riesgo requiere mecanismos externos (por ejemplo, herramientas SCA, anclaje de versiones) en lugar de depender del conocimiento interno del LLM.

Los autores han divulgado estos hallazgos a los proveedores de los modelos evaluados (incluyendo OpenAI, Alibaba y Moonshot AI), varios de los cuales han reconocido el problema. El trabajo pide la integración de la evaluación de seguridad y compatibilidad a nivel de versión en los conjuntos de referencia estándar de evaluación de LLM.