Resumo Técnico: Inteligência de Fontes Abertas para Proveniência de Código e Padrões de Segurança

Declaração do Problema

Desenvolvedores atualmente obtêm código de duas origens distintas: respostas humanas acumuladas em plataformas como o Stack Overflow e saídas de Grandes Modelos de Linguagem (LLMs). Ambas as fontes carregam custos de segurança mensuráveis. O código de origem humana frequentemente propaga padrões inseguros devido à idade de respostas altamente votadas, enquanto o código gerado por LLMs introduz novos riscos, incluindo saídas inseguras e a dependência excessiva do desenvolvedor. Este artigo aborda duas questões centrais sobre essa divisão:

1. Proveniência: A origem de um trecho de código (humano vs. um LLM específico) pode ser recuperada a partir do próprio código usando recursos leves e interpretáveis?
2. Divergência de Segurança: Essas duas fontes adotam padrões de segurança diferentes para as mesmas tarefas de programação e, se sim, onde elas divergem?

O estudo é estrutido como um exercício de Inteligência de Fontes Abertas (OSINT), baseando-se exclusivamente em dados públicos (API do Stack Overflow) e modelos de pesos abertos para garantir total reprodutibilidade.

Metodologia

Os autores construíram um pipeline totalmente reprodutível e orientado a dados para coletar e analisar amostras de código através de 31 tarefas de programação sensíveis à segurança (ex: OAuth com PKCE, verificação de JWT, hashing de senhas, acesso SQL).

• Coleta de Dados:

  • Corpus Humano: Recuperado via API pública do Stack Overflow usando consultas de busca específicas para cada tarefa. O estudo reteve os maiores blocos de código de respostas com pontuação positiva, registrando sua idade e pontuação para considerar o viés temporal.
  • Corpus de Modelo: Gerado usando um gateway local que expõe 9 modelos diversos de pesos abertos (abrangendo famílias como Mistral, Nemotron, Qwen e Tencent) via uma interface compatível com OpenAI. Os prompts foram enviados literalmente com uma instrução de sistema fixa solicitando uma única solução completa.
  • Escala: O conjunto de dados final compreende 528 amostras reais (117 humanas, 411 de modelos) em 5 linguagens (Python, JavaScript, Go, Java, HTML).

• Extração de Recursos:

  • Verificações de Padrões de Segurança: Expressões regulares determinísticas rotuladas como "seguras" ou "inseguras" para cada tarefa (ex: presença de bcrypt vs. md5, consultas parametrizadas vs. concatenação de strings).
  • Métricas de Estilo: Métricas independentes de linguagem que capturam a forma do código, incluindo contagem de linhas, contagem de caracteres, densidade de comentários, contagem de imports, presença de tratamento de erros e comprimento médio da linha.

• Análise:

  • Atribuição de Proveniência: Um classificador Random Forest foi treinado para distinguir entre código humano e de modelo (binário) e para atribuir o código de modelo a modelos específicos (classificação de 7 vias) usando validação cruzada.
  • Pontuação de Segurança: Uma pontuação determinística foi calculada para cada amostra com base na fração de padrões seguros adotados menos a fração de padrões inseguros presentes.
  • Estudo de Caso de Reparo de Vulnerabilidade: Um subconjunto de 21 trechos de código inseguros (cobrindo 12 classes CWE) foi fornecido aos modelos com instruções para corrigi-los. O sucesso foi definido estritamente como a remoção do padrão inseguro e a adição da defesa segura correta.

Principais Contribuições

1. Pipeline de OSINT Reprodutível: Um pipeline baseado em especificações onde adicionar uma nova tarefa requer apenas uma única entrada de dados (prompt, consulta, detectores), permitindo que o estudo se generalize sem a necessidade de novo código.
2. Resultados de Atribuição de Proveniência: Demonstração de que a proveniência do código é altamente recuperável a partir de recursos superficiais.
3. Análise de Divergência de Segurança: Uma comparação granular de padrões de segurança adotados por humanos versus modelos, identificando áreas específicas de melhoria e regressão.
4. Validação Cross-Language: Análise de se as diferenças de segurança e estilo são propriedades da fonte ou da linguagem de programação.
5. Verificador de Fechamento Falho (Fail-Closed): Um mecanismo que re-deriva cada número relatado a partir dos artefatos armazenados, garantindo a integridade dos resultados.

Principais Resultados

1. Atribuição de Proveniência

• Humano vs. Modelo: Um classificador separa o código humano do código de modelo com 93% de precisão (F1 0.955 para a classe do modelo), superando significativamente a linha de base de 78% da classe majoritária.
• Modelo vs. Modelo: Um classificador de 7 vias atribui amostras escritas por modelos à sua origem específica com 48% de precisão (vs. 17% de linha de base).
• Importância de Recursos: O sinal é dominado pelo estilo (tamanho do código, estrutura, scaffolding) em vez do conteúdo de segurança. O código do modelo é significativamente maior, mais estruturado e inclui mais tratamento de erros e imports do que os trechos humanos.
• Especificidade de Linguagem: A fronteira de proveniência não é simétrica entre as linguagens. Um classificador treinado em JavaScript transfere-se bem para Python (89% de precisão), mas o inverso (Python para JavaScript) cai para próximo do acaso (93% de precisão no contexto de frase específica do artigo, indicando uma queda no desempenho relativo à linha de base ou dentro do desempenho da linguagem).

2. Divergência de Segurança

• Segurança Agregada: Os modelos adotam padrões seguros a uma taxa substancialmente maior do que o corpus humano. A pontuação de segurança agregada é de 0.40 para modelos contra 0.12 para humanos.
• Áreas de Melhoria: Os modelos se destacam em tarefas onde a orientação de codificação segura moderna é bem estabelecida e baseada em bibliotecas, tais como:
  • Uso de Funções de Derivação de Chave (KDFs) fortes para hashing de senhas.
  • Implementação de PKCE para OAuth.
  • Uso de consultas parametrizadas para SQL.
  • Fixação de algoritmos e verificação de expiração para JWTs.
• Áreas de Regressão (O "Perigo da Completude"): Os modelos introduzem um modo de falha específico: segredos hardcoded. Como os modelos visam produzir um "programa completo e executável", eles frequentemente inserem segredos de espaço reservado (ex: client_secret = "placeholder") que permanecem inalterados. Em contraste, as respostas humanas frequentemente omitem esses valores inteiramente, deixando-os para o leitor configurar.
• Capacidades de Reparo: No estudo de caso de reparo de vulnerabilidade, os modelos alcançaram uma taxa de sucesso de 77%. No entanto, 16% dos "reparos" foram correções parciais onde o padrão inseguro foi removido, mas a defesa segura não foi adicionada (ex: deletar uma chamada md5, mas armazenar a senha em texto simples).

3. Análise Cross-Language

• Segurança: A divergência de segurança (modelos sendo mais seguros em padrões defensivos, mas piores no tratamento de segredos) mantém-se consistente em Python, JavaScript e Go.
• Estilo: As diferenças estilísticas que impulsionam a atribuição de proveniência variam por ecossistema de linguagem. Por exemplo, a quantidade de scaffolding difere significamente entre Go e Python, o que significa que um classificador de proveniência deve ser calibrado por linguagem.

Significância e Alegações

O artigo afirma que as duas fontes de código não são classificadas simplesmente como "seguro" vs. "inseguro". Em vez disso, elas falham em lugares diferentes:

• Código Humano: Propenso a omissões de legado (ex: falta de tokens CSRF, hashes fracos) devido à idade do material de origem.
• Código de Modelo: Propenso a "perigos de completude" (ex: segredos embutidos, falta de verificações para ameaças não mencionadas como SSRF) devido ao objetivo de gerar um programa autossuficiente.

Implicações para Revisão:
Os autores propõem que a atribuição de proveniência deve atuar como um roteador para a revisão de código.

• Código identificado como gerado por humano deve ser roteado para verificações de omissões defensivas de legado (hashing, padrões de tokens).
• Código identificado como gerado por modelo deve ser roteado para verificações de segredos embutidos e configurações de espaço reservado.

Limitações e Modéstia:

• O estudo baseia-se em correspondência de padrões lexicais (regex), não em análise semântica; uma pontuação de segurança alta indica a adoção de padrões, não segurança absoluta.
• O corpus de modelos é limitado a modelos de pesos abertos disponíveis via um gateway específico, excluindo os principais assistentes comerciais.
• O classificador de proveniência é um experimento de mundo fechado; sua precisão provavelmente degradaria em um cenário de mundo aberto com modelos não vistos.
• Os resultados são instantâneos; tanto o corpus humano (envelhecendo) quanto os dados de treinamento dos modelos (evoluindo) mudarão ao longo do tempo.

O artigo conclui que, embora os modelos tenham absorvido o consenso de segurança recente melhor do que o corpus humano arquivado, eles introduzem novos riscos através de seu impulso pela completude. O pipeline fornecido permite que a comunidade reavalie essas métricas conforme os modelos e as práticas evoluem.