Resumo Técnico: Código Correto, Dependências Vulneráveis

Declaração do Problema

Os Modelos de Linguagem de Grande Escala (LLMs) tornaram-se integrantes dos fluxos de trabalho de desenvolvimento de software, gerando rotineiramente código que inclui importações de bibliotecas de terceiros (TPL) anotadas com identificadores de versão específicos. Embora pesquisas anteriores tenham estudado extensivamente a segurança lógica do código gerado (por exemplo, vulnerabilidades CWE) e a existência de nomes de pacotes alucinados, a dimensão da versão permanece amplamente inexplorada. Especificamente, é desconhecido se as versões de lançamento específicas de bibliotecas corretamente nomeadas recomendadas por LLMs são seguras, compatíveis ou mesmo válidas.

Este artigo identifica uma superfície de risco crítica: os LLMs podem gerar código sintaticamente correto que fixa uma versão de biblioteca carregando Conhecidas Vulnerabilidades e Exposições (CVEs) ou que é incompatível com o uso de API gerado. Como essas escolhas são feitas implicitamente em escala durante a geração de código, elas podem propagar silenciosamente riscos de segurança sistêmicos e falhas de instalação em projetos a jusante.

Metodologia

Os autores apresentam o PinTrace, o primeiro estudo de medição em larga escala de versões de bibliotecas especificadas por LLMs. O estudo avalia 10 LLMs diversos (incluindo modelos de código-fonte fechado como GPT-5.4 e modelos de código aberto como Qwen3 e Llama-4) em um benchmark curado de 1.000 tarefas de programação do mundo real do Stack Overflow.

Design Experimental

O estudo emprega dois modos de prompt para refletir interações comuns de desenvolvedores:

1. Modo Inline: O LLM anota importações com comentários de versão (por exemplo, import lib # version==x.y.z).
2. Modo Explícito: O LLM gera um arquivo de manifesto requirements.txt juntamente com o código.

O pipeline de análise consiste em cinco etapas:

1. Geração: Produzir código para cada tarefa sob ambos os modos.
2. Extração: Analisar referências a bibliotecas e especificadores de versão.
3. Validação: Verificar contra o PyPI para garantir que as versões são lançamentos publicados (filtrando alucinações).
4. Verificação de Vulnerabilidade: Cruzar versões válidas com o banco de dados de Vulnerabilidades de Código Aberto (OSV) para identificar CVEs e severidade CVSS.
5. Verificação de Compatibilidade:
   • Estática: Tentar instalação em ambientes virtuais isolados e executar verificação de tipos estática (ty).
   • Dinâmica: Executar suites de teste do benchmark BigCodeBench para verificar a correção em tempo de execução.

O estudo também inclui verificações de robustez em versões do Python (3.8–3.14), um experimento de diagnóstico substituindo versões vizinhas para isolar causas de falha e sondas de mitigação testando instruções de segurança e ancoragem de versão externa.

Contribuições Principais

1. Estudo de Medição: Uma avaliação abrangente do comportamento de especificação de versão, validade, exposição a vulnerabilidades e compatibilidade em 10 modelos e 1.000 tarefas.
2. Evidência de Viés Sistêmico: Prova empírica de que os LLMs convergem para um pequeno conjunto de versões arriscadas e desatualizadas em diferentes famílias de modelos, impulsionado por viés de sinal de treinamento e não por erros isolados do modelo.
3. Diagnóstico da Causa Raiz: Um experimento controlado que estabelece que as falhas de instalação são principalmente atribuíveis à seleção de versão (escolher versões incompatíveis/antigas) e não a defeitos na lógica do código gerado.
4. Análise de Mitigação: Uma caracterização de intervenções no nível do prompt, demonstrando que instruções de segurança em linguagem natural são ineficazes, enquanto a ancoragem externa de versão reduz significativamente os riscos.
5. Recursos Abertos: Lançamento do conjunto de dados PinTrace e do pipeline de avaliação para pesquisa reprodutível.

Resultados Principais

1. Comportamento de Especificação de Versão (RQ1)

• Facilidade de Formato: A anotação de versão é impulsionada pelo formato de saída, não pela intenção de engenharia. No Modo Inline, os modelos especificam versões para 26,83%–95,18% das referências. No Modo Explícito (geração de manifesto), isso cai para 6,45%–59,19%, com muitos modelos omitindo versões completamente.
• Convergência: Os modelos convergem para uma faixa estreita de lançamentos populares. Por exemplo, requests==2.31.0 e django==6.0.1 são especificados por quase todos os modelos.
• Atraso Temporal: As versões especificadas ficam defasadas em relação aos cortes de conhecimento do modelo em 9 a 31 meses. Os modelos selecionam preferencialmente versões mais antigas que acumularam mais sinal de treinamento.
• Validade: Embora a maioria das versões especificadas inline seja válida, 7%–16% são alucinadas (lançamentos PyPI inválidos), frequentemente devido a omissões de sufixo (por exemplo, 4.8.0 em vez de 4.8.0.74).

2. Exposição a Vulnerabilidades (RQ2)

• Alta Exposição: Sob prompt inline, 36,70%–55,70% das tarefas contêm pelo menos uma versão com uma CVE conhecida.
• Severidade: 62,75%–74,51% dessas versões vulneráveis são classificadas com severidade Crítica ou Alta.
• Evitabilidade: Em 72,27%–91,37% dos casos, as CVEs associadas foram divulgadas publicamente antes do corte de conhecimento do modelo, indicando que a exposição é evitável, mas não reconhecida pelo modelo.
• Risco Estrutural: 95,11% dos pares vulneráveis (biblioteca, versão) não têm alternativa livre de CVE dentro do mesmo ramo de versão principal, o que significa que atualizações simples de patch não podem resolver o risco.

3. Compatibilidade (RQ3)

• Compatibilidade Estática: As taxas variam de 19,70% a 63,20% no modo inline. A causa dominante de falha é erro de instalação de dependência, frequentemente devido à ausência de distutils em ambientes Python 3.12+ (uma consequência da seleção de versões mais antigas).
• Compatibilidade Dinâmica: As taxas de aprovação colapsam para 6,49%–48,62% no modo inline. A maioria das tarefas falha antes da execução devido a erros de instalação.
• Diagnóstico: Um experimento de substituição confirmou que trocar a versão especificada pelo LLM por um lançamento vizinho resolve falhas de instalação em 17,19%–55,00% dos casos, provando que a lógica do código é frequentemente sólida, mas a escolha da versão é falha.

4. Mitigação

• Prompting: Adicionar instruções de segurança em linguagem natural ("evitar versões vulneráveis") produz melhoria insignificante (<2,2% de redução na exposição).
• Ancoragem Externa: Injetar versões seguras pré-calculadas no prompt reduz significativamente a exposição a vulnerabilidades (para cerca de 10–27%) e melhora a compatibilidade estática para 80%–93%.

Significado e Alegações

O artigo argumenta que a seleção de versão por LLM é uma superfície de risco de primeira classe, anteriormente negligenciada. As descobertas revelam que:

1. O risco é sistêmico, não idiossincrático: A convergência para as mesmas versões vulneráveis em todas as famílias de modelos indica um viés compartilhado de sinal de treinamento, tornando impossível mitigar apenas trocando de modelo.
2. O problema é uma lacuna de fundamentação, não uma lacuna de alinhamento de segurança: Como a maioria das CVEs era conhecida antes do treinamento, a falha reside na incapacidade do modelo de mapear identificadores de versão para seu status de segurança no momento da inferência.
3. Prompting é insuficiente: Instruções em linguagem natural não conseguem preencher a lacuna entre a seleção de versão e o conhecimento de segurança.
4. Ferramentas externas são necessárias: Os autores concluem que abordar esse risco requer mecanismos externos (por exemplo, ferramentas SCA, ancoragem de versão) em vez de confiar no conhecimento interno do LLM.

Os autores divulgaram essas descobertas aos provedores dos modelos avaliados (incluindo OpenAI, Alibaba e Moonshot AI), vários dos quais reconheceram o problema. O artigo pede a integração de avaliação de segurança e compatibilidade no nível de versão em benchmarks padrão de avaliação de LLM.