An Insight into Security Code Review with LLMs: Capabilities, Obstacles, and Influential Factors

Título: Uma Análise da Revisão de Código de Segurança com LLMs: Capacidades, Obstáculos e Fatores Influenciadores

Declaração do Problema
A revisão de código de segurança é um processo crítico, porém intensivo em mão de obra, essencial para prevenir violações de dados e perdas financeiras. Embora as organizações integrem cada vez mais a análise de segurança na revisão de código, as ferramentas automatizadas existentes (análise estática/dinâmica/híbrida) sofrem de baixa generalização, altas taxas de falsos positivos e granularidade de detecção grosseira. Além disso, abordagens baseadas em dados, fundamentadas em aprendizado de máquina tradicional ou aprendizado profundo, frequentemente carecem de robustez devido à escassez de conjuntos de dados de treinamento realistas, apresentando desempenho inferior em projetos do mundo real. Embora os Modelos de Linguagem de Grande Porte (LLMs) tenham demonstrado promessa em diversas tarefas de engenharia de software, suas capacidades específicas, limitações e os fatores que influenciam seu desempenho no contexto de granularidade fina da revisão de código de segurança permanecem amplamente inexplorados.

Metodologia
Os autores conduziram um estudo empírico para avaliar o potencial dos LLMs na detecção de defeitos de segurança durante a revisão de código. O estudo utilizou um conjunto de dados manualmente curado de 534 arquivos de código (258 Python, 276 C/C++) derivados de quatro projetos de código aberto (OpenStack Nova/Neutron e Qt Base/Creator), contendo 614 comentários de revisão relacionados à segurança.

• Modelos Avaliados: Sete LLMs foram testados, incluindo modelos proprietários (GPT-4, GPT-4 Turbo, Gemini Pro), modelos de código aberto (Llama 2 7B, Llama 2 70B) e um modelo otimizado para raciocínio (DeepSeek-R1).
• Engenharia de Prompt: Cinco modelos de prompt distintos foram projetados com base em melhores práticas e estratégias anteriores:
  1. Prompt Básico ($P_b$): Instrução direta para revisar o código.
  2. Informação do Projeto ($P_r$): Adição do contexto do nome do projeto.
  3. Instrução Geral CWE ($P_c$): Instrução para utilizar o CWE como referência.
  4. Instrução Específica CWE ($P_{cid}$): Fornecimento de uma lista de CWEs de nível superior.
  5. Cadeia de Pensamento ($P_{cot}$): Um prompt em duas etapas que exige que o modelo gere o contexto do código a partir de uma mensagem de commit antes de analisar defeitos. Uma versão com "guardrail" ($P_{cot-guardrail}$) também foi testada para isolar o impacto do contexto gerado.
• Métricas de Avaliação: As respostas foram manualmente classificadas em quatro categorias: Instrumental (tipo de defeito, localização e descrição precisos), Útil (parcialmente preciso), Enganoso (falha na detecção ou falsos negativos) e Incerta. As métricas incluíram I-Score, IH-Score e M-Score. A consistência foi medida via entropia de resposta em três execuções experimentais.
• Análise: O estudo comparou o desempenho dos LLMs contra ferramentas de análise estática de última geração (por exemplo, CodeQL, Bandit, CppCheck). Para os modelos de melhor desempenho, uma análise linguística identificou problemas de qualidade (por exemplo, alucinações, vaguidão). Finalmente, modelos de regressão de ligação cumulativa foram construídos para analisar a influência de 11 fatores (por exemplo, contagem de tokens, complexidade do código, tipo de defeito) no desempenho.

Principais Contribuições

1. Avaliação de Granularidade Fina: Fornecimento de uma avaliação abrangente de LLMs populares na revisão de código de segurança, indo além da classificação binária para avaliar a localização de defeitos, descrição e sugestões de remediação.
2. Análise de Não Determinismo: Medição do impacto do não determinismo dos LLMs na consistência dos resultados da revisão de código de segurança.
3. Quantificação de Problemas de Qualidade: Identificação e quantificação de problemas de qualidade específicos, incluindo alucinações (fáticas e de fidelidade), nas respostas dos modelos de melhor desempenho.
4. Análise de Influência de Fatores: Realização da primeira análise de regressão para validar estatisticamente como atributos específicos de código e projeto influenciam o desempenho dos LLMs neste domínio.

Resultados

• Desempenho vs. Baselines: Os LLMs superaram significativamente as ferramentas de análise estática de última geração na revisão de código de segurança. Entre os LLMs, o modelo otimizado para raciocínio (DeepSeek-R1) superou os modelos de propósito geral.
• Melhores Desempenhos: O DeepSeek-R1 alcançou o desempenho geral mais alto, seguido pelo GPT-4 (via plataforma ChatGPT).
  • Prompts Ótimos: O DeepSeek-R1 apresentou o melhor desempenho com um prompt combinando a mensagem de commit e orientação de Cadeia de Pensamento (CoT) ($P_{cot-guardrail}$). O GPT-4 (ChatGPT) apresentou o melhor desempenho com um prompt contendo uma lista específica de CWEs ($P_{cid}$).
• Problemas de Qualidade:
  • GPT-4 (ChatGPT): Frequentemente produziu expressões vagas e teve dificuldades com o seguimento de instruções (por exemplo, ausência de números de linha), embora tivesse menos erros factuais relacionados a detalhes do código.
  • DeepSeek-R1: Mais propenso a gerar detalhes de código imprecisos (por exemplo, números de linha ou nomes de função incorretos) e exibiu uma taxa mais alta de alucinações de "Fato Incorreto", apesar de possuir melhores capacidades de seguimento de instruções.
• Fatores Influenciadores:
  • Contagem de Tokens: Os LLMs foram mais aptos a identificar defeitos em arquivos com menos tokens; o desempenho geralmente diminuiu conforme a contagem de tokens aumentou.
  • Anotações: A presença de anotações relacionadas à segurança no código melhorou as capacidades de detecção.
  • Complexidade: Maior complexidade do código correlacionou-se com capacidades de detecção aprimoradas para o DeepSeek-R1 para tipos específicos de defeitos (excluindo os relacionados à memória), contrariando a suposição de que a complexidade sempre dificulta a detecção.
  • Consistência: Modelos com maiores capacidades de detecção (DeepSeek-R1, GPT-4 ChatGPT) exibiram menor consistência (entropia mais alta) entre execuções em comparação com modelos menos capazes.

Significado e Alegações
O artigo afirma que, embora os LLMs atuais ainda não sejam um substituto para revisores humanos, eles servem como ferramentas auxiliares poderosas que superam significativamente as ferramentas tradicionais de análise estática na detecção de defeitos de segurança. O estudo destaca que a eficácia dos LLMs depende altamente da engenharia de prompt (especificamente a inclusão de mensagens de commit, CoT ou listas de CWE) e das características específicas do código sendo revisado (contagem de tokens, complexidade, anotações).

Os autores enfatizam que o não determinismo dos LLMs é uma faca de dois gumes: modelos capazes de raciocínio mais profundo (e, portanto, melhor detecção) tendem a produzir saídas mais inconsistentes. Eles concluem que uma estratégia de revisão em camadas múltiplas é necessária, onde os LLMs lidam com revisões iniciais de código de baixa dificuldade (menos tokens), enquanto especialistas humanos focam em código de alta dificuldade e validam as descobertas dos LLMs. O estudo também sublinha a necessidade de trabalhos futuros para abordar alucinações relacionadas a detalhes de código e melhorar a estabilidade das saídas dos LLMs sem sacrificar a sensibilidade de detecção.