LLM-based Vulnerability Detection at Project Scale: An Empirical Study

Resumo Técnico: Detecção de Vulnerabilidades Baseada em LLM em Escala de Projeto: Um Estudo Empírico

Definição do Problema
À medida que a complexidade e a escala de implantação do software aumentam, as vulnerabilidades de segurança tornaram-se mais frequentes e prejudiciais, exigindo uma detecção automatizada robusta. Embora as ferramentas tradicionais de análise estática sejam amplamente adotadas, elas dependem de regras projetadas manualmente e padrões predefinidos, o que limita sua capacidade de generalização para tipos de vulnerabilidades não vistos ou em evolução. Por outro lado, os recentes detectores baseados em Grandes Modelos de Linguagem (LLMs) prometem um raciocínio semântico aprimorado ao interpretar a semântica do código e a lógica complexa sem engenharia de regras explícita. No entanto, a maioria das abordagens baseadas em LLM existentes é avaliada em trechos (snippets) de nível de função ou de fragmento (hunk), deixando incertas sua eficácia, confiabilidade e escalabilidade em escala de projeto. Há uma falta de compreensão sistemática sobre as causas raízes de falhas (especificamente falsos positivos) e o overhead computacional quando esses detectores especializados são aplicados a bases de código reais e de grande escala.

Metodologia
Os autores apresentam o primeiro estudo empírico abrangente comparando cinco detectores baseados em LLM especializados em escala de projeto contra duas ferramentas de análise estática tradicionais (CodeQL e Semgrep). O estudo emprega uma estratégia de avaliação de configuração dupla:

1. Benchmark Interno: Um conjunto de dados curado de 222 vulnerabilidades reais conhecidas (cobrindo 8 tipos de CWE em C/C++ e Java) derivadas de ReposVul, CWE-Bench-Java e JLeaks. Esta configuração avalia a capacidade de detecção (Recall) contra a verdade fundamental (ground truth).
2. Projetos do Mundo Real: Um conjunto de 24 projetos de código aberto mantidos ativamente (incluindo componentes do kernel Linux, ImageMagick, Jenkins e Keycloak). Esta configuração avalia a usabilidade prática analisando volumes de avisos e Taxas de Descoberta Falsa (FDR).
3. Análise Manual: Dois especialistas em segurança inspecionaram manualmente 385 avisos amostrados (exigindo mais de 150 horas humanas) para construir uma taxonomia de causas de falsos positivos.
4. Medição de Custo: O estudo quantificou o overhead computacional, medindo o consumo de tokens de entrada/saída e o tempo de execução de ponta a ponta para cada ferramenta.

Os métodos baseados em LLM avaliados incluem RepoAudit, KNighter, IRIS, LLMDFA e INFERROI, representando diversos fluxos de trabalho, como frameworks multiagentes, geração de verificadores assistida por LLM e inferência guiada por fluxo de controle.

Principais Contribuições

• Primeira Comparação em Escala de Projeto: O estudo fornece a primeira comparação sistemática de cinco detectores representativos baseados em LLM contra ferramentas tradicionais em escala de projeto.
• Avaliação Abrangente: Avalia a eficácia da detecção em 222 vulnerabilidades conhecidas e a usabilidade prática em 24 projetos do mundo real.
• Taxonomia de Falhas: Os autores rotularam manualmente 385 relatórios para construir uma taxonomia detalhada de causas de falsos positivos, quantificando como escolhas de design (ex: construção de fluxo de dados, inferência de fonte/pia) contribuem para as falhas.
• Análise de Custo: O artigo mede e relata o substancial uso de tokens e custos de tempo associados à detecção baseada em LLM em escala de projeto.
• Liberação de Artefatos: Todos os artefatos experimentais, incluindo scripts, prompts e rótulos de taxonomia, são liberados para fomentar a reprodutibilidade.

Principais Resultados

1. Baixo Recall, mas Detecções Únicas: No benchmark interno, os métodos baseados em LLM exibiram um recall médio baixo (21,09% para C/C++ e 33,82% para Java), muitas vezes perdendo vulnerabilidades devido a definições desalinhadas de fonte/pia (source/sink). No entanto, eles ainda descobriram mais vulnerabilidades únicas do que as ferramentas tradicionais, sugerindo um valor complementar.
2. Altas Taxas de Descoberta Falsa (FDR): Em projetos do mundo real, tanto as ferramentas baseadas em LLM quanto as tradicionais geraram avisos substanciais com FDRs muito altos. Mesmo a ferramenta com melhor desempenho apresentou um FDR médio de 85,3%. Por exemplo, o RepoAudit em projetos C/C++ teve um SFDR médio de 9,0%.
3. Causas Raízes de Falha: A análise manual identificou duas causas dominantes compartilhadas por ferramentas de LLM e tradicionais:
   • Raciocínio Interprocedural Superficial (37,47% dos FPs): As ferramentas falham em rastrear fluxos de dados através de cadeias de chamadas profundas ou estruturas de controle complexas.
   • Identificação Imprecisa de Fonte/Pia (19,00% dos FPs): As ferramentas identificam incorretamente pontos benignos do programa como relevantes para segurança ou falham em reconhecer APIs específicas de um projeto.
   • Falhas Específicas de LLM: Ferramentas baseadas em LLM sofreram adicionalmente com compreensão alucinada de código, reconstrução incorreta de fluxo de controle (ex: mesclando caminhos mutuamente exclusivos) e falha em aderir estritamente às definições de prompt ou escopos de CWE.
4. Overhead Computacional: A detecção em escala de projeto via LLM é computacionalmente cara. Ferramentas como RepoAudit e LLMDFA exigiram centenas de milhares a centenas de milhões de tokens por projeto, com tempos de execução variando de várias horas a vários dias (ex: até 4.638 minutos). Ferramentas tradicionais (CodeQL, Semgrep) completaram análises em segundos ou minutos com custos de tokens negligenciáveis.

Significância e Implicações
O artigo conclui que, embora os detectores baseados em LLM ofereçam capacidades promissoras de raciocínio semântico que podem descobrir vulnerabilidades perdidas por ferramentas tradicionais de correspondência de padrões, eles ainda não são maduros o suficiente para uma implantação independente e confiável em cenários do mundo real. O estudo destaca limitações críticas em robustez (alto FDR), confiabilidade (baixo recall na verdade fundamental) e escalabilidade (custos computacionais proibitivos).

Os autores derivam cinco implicações para pesquisas futuras:

1. Aprofundar o Raciocínio de Fluxo de Dados: Ir além da exploração superficial de grafos de chamada para uma análise holística de "entrada → propagação → saída".
2. Melhorar a Inferência de Fonte/Pia: Desenvolver mecanismos sensíveis ao contexto para identificar com precisão APIs específicas de projetos, em vez de depender de definições genéricas ou alucinadas.
3. Aprimorar a Compreensão Semântica: Integrar LLMs com representações de programas intermediárias e sinais de análise estática para lidar melhor com recursos de linguagem complexos (ex: destruidores, try-with-resources).
4. Forçar o Alinhamento de Prompt: Implementar colaboração multiagente estruturada ou autoverificação para garantir que os modelos adiram estritamente às definições de vulnerabilidade.
5. Abordar a Escalabilidade: Adotar análise hierárquica, cache de raciocínio intermediário e otimização de fluxos de trabalho para reduzir o consumo de tokens e o tempo de execução para níveis adequados à integração contínua.

Os autores enfatizam que as descobertas atuais ressaltam a necessidade de abordagens híbridas que aproveitem os pontos fortes semânticos dos LLMs enquanto mitigam seus problemas de custo e confiabilidade através da integração rigorosa com a análise estática.