Security and Quality in LLM-Generated Code: A Multi-Language, Multi-Model Analysis

Este artigo analisa a segurança e a qualidade do código gerado por modelos de linguagem de grande escala (LLMs) em múltiplas linguagens, revelando que, embora a automação seja eficaz, os modelos frequentemente falham ao adotar recursos de segurança modernos e ainda empregam métodos desatualizados, especialmente em C++ e Java 17.

O essencial

Imagine que você contratou cinco cozinheiros robôs (os Modelos de Linguagem ou LLMs) para preparar 200 pratos diferentes. Alguns pratos são simples, como uma salada (Python), outros são complexos, como um soufflé de queijo (C++), e alguns exigem precisão cirúrgica, como cortar um filé (C).

O objetivo deste estudo foi ver não apenas se os robôs conseguiam fazer o prato, mas se o prato estava seguro para comer (sem veneno ou bactérias) e se a receita era fácil de seguir para outro cozinheiro no futuro.

Aqui está o resumo do que eles descobriram, usando analogias do dia a dia:

1. O Grande Experimento: 5 Robôs, 4 Cozinhas

Os pesquisadores pegaram 5 dos "robôs" mais famosos do mundo (como o GPT-4o, o Claude, o Gemini, etc.) e pediram para eles escreverem códigos em 4 "idiomas" de programação diferentes:

• Python: Como cozinhar com uma panela de pressão moderna. É fácil, rápido e difícil de errar.
• Java: Como cozinhar em uma cozinha industrial organizada. Tudo tem seu lugar, é estruturado, mas exige seguir regras rígidas.
• C++ e C: Como cozinhar com facas afiadas e fogo aberto. Você tem controle total, mas se errar um milímetro, pode se cortar (vazamento de memória) ou queimar a casa (falha de segurança).

2. O Que Eles Testaram?

Eles não olharam apenas se o prato saía pronto. Eles verificaram três coisas principais:

• O Prato Saiu? (Validade Sintática): O código compila? Ou seja, o robô conseguiu ligar o fogão e começar a cozinhar, ou ele derrubou a panela antes mesmo de começar?
• O Sabor Está Certo? (Correção Semântica): O prato tem o gosto que a receita pedia? Eles criaram 4.000 "testes de degustação" (testes unitários) para ver se o código fazia exatamente o que deveria.
• Tem Veneno no Prato? (Segurança): O robô usou ingredientes estragados? Ele deixou a porta da cozinha aberta para ladrões? Eles usaram "detectores de veneno" automáticos (ferramentas como SonarQube e CodeQL) e depois revisaram manualmente para ter certeza.

3. As Descobertas Surpreendentes

🍳 Python e Java: Os Cozinheiros Confiáveis

Os robôs foram excelentes em Python e Java.

• Analogia: Foi como pedir para eles fazerem um sanduíche ou uma omelete. A maioria dos robôs conseguiu fazer o prato sem queimar nada e sem deixar ingredientes perigosos.
• Resultado: O código quase sempre funcionava e tinha menos "veneno" (vulnerabilidades de segurança).

🔪 C e C++: A Cozinha Perigosa

Aqui foi onde as coisas deram errado.

• Analogia: Pedir para um robô cozinhar com C++ é como pedir para ele usar um sopro de oxiacetileno para cortar um bife. Eles tendiam a esquecer de colocar a proteção de segurança (como #include ou cabeçalhos), usar facas velhas (métodos desatualizados) ou esquecer de limpar a bagunça (gerenciamento de memória).
• Resultado: Muitos pratos nem saíram do fogão (erros de compilação). E quando saíram, muitos tinham "bactérias" perigosas, como senhas escritas no código (como deixar a chave da casa embaixo do tapete) ou erros que poderiam deixar o sistema vulnerável a hackers.

🤖 Os Robôs Preferem o Passado

Um dos achados mais curiosos foi que os robôs, mesmo sendo "inteligentes", muitas vezes esqueceram as regras modernas de segurança.

• Analogia: É como se você pedisse para um robô cozinhar com a tecnologia de 2024, mas ele insistisse em usar uma receita de 1980 que usava um gás tóxico porque "sempre funcionou". Eles não estavam usando as ferramentas de segurança mais recentes que os programadores humanos já adotaram.

4. O Veredito Final

O estudo conclui que, embora os robôs sejam ótimos ajudantes, não podemos confiar neles cegamente, especialmente em tarefas complexas e perigosas (como lidar com dinheiro, dados sensíveis ou sistemas críticos).

• Para tarefas simples (Python/Java): Eles são ótimos assistentes, mas ainda precisam de um chefe de cozinha humano para revisar.
• Para tarefas complexas (C/C++): Eles são perigosos. Precisam de supervisão rigorosa, pois tendem a cometer erros básicos que humanos experientes não cometeria.

A Lição Principal: A inteligência artificial é como um estagiário muito rápido e criativo, mas que ainda não aprendeu todas as normas de segurança da cozinha. Se você não revisar o trabalho dele, pode acabar servindo um prato que vai fazer seus clientes (ou seus sistemas) ficarem doentes.

O estudo deixa claro: o código gerado por IA precisa ser tratado com o mesmo cuidado que um prato servido por um estagiário: sempre provado e verificado antes de servir.

Resumo técnico

Resumo Técnico: Segurança e Qualidade em Código Gerado por LLMs

1. Problema e Motivação

O uso de Inteligência Artificial (IA) e Modelos de Linguagem de Grande Escala (LLMs) para geração de código tem crescido rapidamente no ciclo de vida de desenvolvimento de software. Embora ferramentas como o GitHub Copilot aumentem a produtividade, a segurança e a qualidade do código gerado por essas IAs permanecem subexploradas. Estudos anteriores indicam que LLMs podem produzir código vulnerável, muitas vezes com mais falhas de segurança do que o código escrito por humanos, e com excesso de confiança na segurança do código gerado.

Existe uma lacuna significativa no entendimento de como a escolha da linguagem de programação e a seleção do modelo de LLM influenciam a segurança, a correção semântica e a qualidade geral do código. A maioria dos estudos anteriores foca em uma única linguagem ou modelo, ou utiliza benchmarks que não refletem adequadamente cenários de segurança complexos.

2. Metodologia

O estudo realiza uma análise quantitativa e comparativa abrangente, seguindo uma metodologia rigorosa:

• Modelos e Linguagens Avaliados:
  • 5 Modelos de LLM: GPT-4o, Claude-3.5, Gemini-1.5, Llama-3 e Codestral.
  • 4 Linguagens de Programação: Python, Java, C++ e C (cobrindo tipagem dinâmica e estática, além de gerenciamento de memória automático e manual).
• Construção do Dataset:
  • Foi criado um conjunto de dados manualmente curado com 200 tarefas de programação.
  • As tarefas foram agrupadas em 7 categorias funcionais e de segurança: Codificação Segura (baseada em CWEs), Estruturas de Dados e Algoritmos, Análise e Validação, Redes, Matemática e Lógica, Sistemas e Utilitários, e Concorrência/Sincronização.
  • As especificações das tarefas foram neutras em relação à linguagem, permitindo comparações justas.
• Geração de Código:
  • Foram gerados 4.000 arquivos de código (200 tarefas × 4 linguagens × 5 modelos).
  • Não foi utilizada engenharia de prompts complexa; foram usadas descrições originais das tarefas para simular o uso real.
• Avaliação e Métricas:
  • Validade Sintática e Compilação: Verificação de erros de compilação e sintaxe.
  • Correção Semântica: Utilização de 4.000 arquivos de testes unitários (10 testes por programa) para validar a lógica.
  • Qualidade e Segurança: Análise estática automatizada usando SonarQube (para qualidade, manutenibilidade e confiabilidade) e CodeQL (para vulnerabilidades específicas).
  • Revisão Manual: Uma amostra estratificada de 20% dos resultados foi revisada manualmente por engenheiros de software experientes para mitigar falsos positivos e validar achados críticos.
  • Métricas de Complexidade: Linhas de código (LoC), Complexidade Ciclomática (CyC), Densidade de Complexidade Ciclomática (CCD) e Complexidade Cognitiva (CoC).

3. Principais Contribuições

1. Novo Dataset de Avaliação: Introdução de um conjunto de dados de 200 tarefas, manualmente verificado, cobrindo múltiplos domínios e linguagens, projetado especificamente para avaliar LLMs em cenários de segurança e funcionalidade.
2. Avaliação Comparativa Multidimensional: Uma análise unificada que compara diretamente diferentes modelos e linguagens, revelando diferenças que estudos de linguagem única não capturam.
3. Análise de Segurança Profunda: Identificação de padrões de vulnerabilidades específicos por linguagem e modelo, mapeando-os para categorias de CWE (Common Weakness Enumeration).
4. Insights sobre Práticas de Codificação: Detecção de que muitos modelos falham em utilizar recursos modernos de segurança (ex: Java 17) e tendem a usar métodos desatualizados, especialmente em C++.

4. Resultados Chave

• Impacto da Linguagem de Programação:
  • Python e Java: Apresentaram as maiores taxas de sucesso na compilação e correção semântica. O Python, devido à sua sintaxe simples e tipagem dinâmica, teve a maior taxa de sucesso (100% em alguns modelos). O Java também performou bem, mas com variações dependendo do tratamento de dependências e imports.
  • C e C++: Apresentaram as taxas de sucesso mais baixas e mais erros de compilação. As principais causas foram falta de inclusões de bibliotecas (#include), tratamento incorreto de tipos, erros de gerenciamento de memória e uso inadequado de APIs. O C++ mostrou-se particularmente desafiador devido à complexidade de suas múltiplas versões de padrão (C++11, C++17).
• Desempenho dos Modelos:
  • Claude-3.5 e GPT-4o: Geralmente superaram os outros modelos em correção semântica e geração de código compilável, especialmente em Java e C++.
  • Llama-3 e Gemini-1.5: Mostraram taxas de erro mais altas em linguagens de baixo nível (C/C++), com dificuldades em sintaxe estrita e gerenciamento de dependências.
• Vulnerabilidades de Segurança:
  • C e C++: As vulnerabilidades predominantes foram relacionadas à segurança de memória (ex: CWE-120: Buffer Copy sem verificação de tamanho, CWE-787: Acesso fora dos limites, CWE-131: Cálculo incorreto de tamanho de buffer).
  • Java e Python: As vulnerabilidades mais comuns envolveram criptografia inadequada (ex: CWE-780: Uso de RSA sem OAEP), senhas codificadas (CWE-259) e validação inadequada de certificados (CWE-295).
  • Padrões Comuns: Todos os modelos tendiam a usar práticas inseguras ou desatualizadas (ex: geração de números aleatórios insegura no Java, mesmo com recursos do Java 17 disponíveis).
• Qualidade e "Clean Code":
  • O código gerado em C apresentou os maiores desafios em termos de consistência e intenção (clareza do propósito).
  • Modelos como o Claude-3.5 tendiam a gerar código mais verboso e complexo (maior LoC e CoC), enquanto o Codestral e o GPT-4o geraram código mais simples e com menor densidade de complexidade.

5. Significância e Conclusão

Este estudo fornece uma linha de base crítica para a comunidade de pesquisa e desenvolvimento, demonstrando que:

1. A escolha da linguagem importa: A segurança e a qualidade do código gerado por IA variam drasticamente dependendo da linguagem alvo. Linguagens de baixo nível (C/C++) apresentam riscos significativamente maiores de segurança e falhas de compilação.
2. LLMs não são infalíveis em segurança: Mesmo os modelos mais avançados frequentemente ignoram práticas modernas de segurança e introduzem vulnerabilidades conhecidas (CWEs).
3. Necessidade de Supervisão Humana: A dependência exclusiva de LLMs para geração de código, especialmente em sistemas críticos ou de baixo nível, é arriscada. A revisão humana e ferramentas de análise estática são essenciais.
4. Direções Futuras: Há uma necessidade urgente de avançar nos LLMs para que eles se alinhem melhor com as práticas de codificação segura emergentes e com as especificidades de cada linguagem. O estudo sugere que futuras pesquisas devem focar em engenharia de prompts, avaliação em nível de sistema (não apenas funções isoladas) e integração de análise dinâmica e fuzzing.

Em suma, o trabalho alerta que, embora os LLMs acelerem o desenvolvimento, eles introduzem novos vetores de risco de segurança que variam conforme o contexto tecnológico, exigindo uma avaliação rigorosa e contínua antes da adoção em produção.