Generating Proof-of-Vulnerability Tests to Help Enhance the Security of Complex Software

Resumo Técnico: Geração de Testes de Prova de Vulnerabilidade para Ajudar a Aprimorar a Segurança de Software Complexo

Declaração do Problema
Ataques à cadeia de suprimentos de software (SSC) exploram vulnerabilidades em bibliotecas de terceiros (Libs) utilizadas por aplicações (Apps). Embora existam ferramentas para detectar dependências vulneráveis ou sugerir correções, elas frequentemente falham em demonstrar se uma vulnerabilidade específica é praticamente explorável dentro de uma aplicação a jusante. Desenvolvedores frequentemente necessitam de evidências concretas e executáveis — conhecidas como testes de Prova de Vulnerabilidade (PoV) — para avaliar riscos de segurança e priorizar correções. No entanto, a criação manual desses testes é desafiadora, e ferramentas automatizadas existentes (por exemplo, SIEGE, Transfer) demonstraram sucesso limitado na geração de testes PoV para aplicações Java complexas. O desafio central reside em identificar pontos de entrada ao nível da aplicação que alcancem APIs de bibliotecas vulneráveis, gerar testes que respeitem o contexto específico do programa e validar que esses testes acionam com sucesso a vulnerabilidade.

Metodologia: PoVSmith
Os autores propõem o PoVSmith, uma abordagem baseada em agentes projetada para automatizar a geração, execução e avaliação de testes PoV para aplicações Java. O sistema opera através de quatro fases distintas:

1. Fase I: Análise de Caminho de Chamada Baseada em Agentes

   • Objetivo: Identificar pontos de entrada ao nível da aplicação (métodos públicos) que invocam (in)diretamente APIs de bibliotecas vulneráveis (sumidouros).
   • Abordagem: Em vez de depender de ferramentas tradicionais de análise estática (como WALA ou Soot), que têm dificuldades com JDKs modernos e mapeamento de bytecode para código-fonte, o PoVSmith utiliza um agente de codificação com IA (Codex).
   • Processo: O agente é acionado via um script integrado à CLI para analisar o código-fonte da aplicação. Ele localiza todas as invocações da API vulnerável e rastreia os caminhos de chamada de volta para métodos públicos, filtrando caminhos que passam por outros métodos públicos para identificar a superfície de ataque mínima.

2. Fase II: Geração de Testes Baseada em Agentes

   • Objetivo: Gerar iterativamente testes JUnit que demonstrem a lógica de exploração.
   • Abordagem: O agente (Codex) é acionado com um modelo abrangente contendo:
     • Contexto: A API vulnerável, o método de origem e o caminho de chamada completo.
     • Exemplar: Um teste de referência da própria biblioteca que demonstra a vulnerabilidade (por exemplo, um teste mostrando como uma versão corrigida rejeita entrada maliciosa enquanto uma versão vulnerável a aceita).
     • Restrições: Regras para estrutura do teste (Organizar-Agir-Afirmar), independência (sem mock de entidades do caminho de chamada) e construção de payload.
   • Iteração: O agente engaja-se em um loop de autocrítica. Ele gera um teste, tenta compilá-lo/executá-lo, analisa a saída e refina o teste com base em erros (por exemplo, falhas de compilação ou comportamento incorreto) até um limite de tentativas.

3. Fase III: Compilação e Execução de Testes

   • Objetivo: Validar os testes gerados para prevenir "alucinações" onde agentes produzem código aparentemente correto, mas não funcional.
   • Processo: Um script automatizado compila e executa os testes gerados usando o sistema de construção do projeto (Maven ou Gradle). Ele captura logs detalhados, incluindo rastreamentos de pilha e resultados de tempo de execução, que servem como verdade fundamental para a próxima fase.

4. Fase IV: Avaliação Baseada em LLM

   • Objetivo: Determinar se o teste aciona com sucesso a vulnerabilidade.
   • Abordagem: Um Modelo de Linguagem de Grande Escala (GPT-5.1) analisa o código do teste e os logs de execução. É acionado para decidir se o comportamento do teste (por exemplo, exceções específicas ou falhas de afirmação) confirma a presença da vulnerabilidade. A saída inclui um julgamento ("sim/não/desconhecido"), nível de confiança e raciocínio.

Principais Contribuições

1. Metodologia Inovadora Baseada em Agentes: O PoVSmith introduz um pipeline que combina análise de caminho de chamada, geração orientada por exemplares, refinamento iterativo via feedback de execução e autocrítica baseada em LLM.
2. Caracterização das Capacidades de IA: O trabalho avalia sistematicamente a eficácia de agentes de codificação (Codex, Gemini, Mistral) na análise de caminhos de chamada e geração de testes, bem como a precisão de LLMs na avaliação da qualidade dos testes com base em logs de execução.
3. Novo Conjunto de Dados: Os autores compilaram um conjunto de dados de 33 pares <App, Lib> Java envolvendo 20 CVEs, contendo 207 caminhos de chamada verificados e 152 pontos de entrada únicos ao nível da aplicação.
4. Descobertas de Segurança: O sistema identificou vulnerabilidades previamente não reportadas, levando ao envio de seis pull requests e seis solicitações de CVE (embora o feedback estivesse pendente no momento da publicação).

Resultados Experimentais
Avaliado em 33 pares <App, Lib>:

• Análise de Caminho de Chamada (RQ1): O PoVSmith alcançou 96% de precisão (152/158 métodos corretamente identificados) e 81% de revocação contra pontos de entrada conhecidos, com uma pontuação F1 de 88%.
• Geração de Testes (RQ2): De 152 tarefas de geração, 141 (93%) compilaram com sucesso. Destes, 84 (55%) demonstraram com sucesso a vulnerabilidade (PoV). O sistema mostrou maior eficácia para os tipos de ataque Traversal Direta (DT) e Outro (OTH) em comparação com Execução Remota de Código (RCE).
• Precisão da Avaliação (RQ3): O avaliador baseado em LLM alcançou 68% de precisão na determinação de se um teste acionou uma vulnerabilidade, superando a autocrítica do agente de codificação (62%).
• Comparação de Agentes (RQ4): O Codex superou significativamente agentes alternativos (Gemini Code Assist e Mistral Vibe) tanto na qualidade da geração de código quanto na adesão às instruções do prompt.
• Comparação com Trabalhos Anteriores (RQ5): O PoVSmith superou substancialmente a abordagem baseada em LLM mais avançada [78]. Enquanto a abordagem anterior gerou 16 testes compiláveis com apenas 5 demonstrações de PoV bem-sucedidas, o PoVSmith gerou 22 demonstrações de PoV bem-sucedidas.

Significado e Alegações
O artigo afirma que o PoVSmith efetivamente preenche a lacuna entre detecção de vulnerabilidades e avaliação prática de riscos, fornecendo aos desenvolvedores prova executável de explorabilidade. Os autores enfatizam que sua abordagem reduz a intervenção humana enquanto melhora dramaticamente a qualidade dos testes em comparação com ferramentas existentes. Eles posicionam o PoVSmith não como um detector de vulnerabilidades, mas como uma ferramenta para validar a explorabilidade de vulnerabilidades conhecidas em contextos de aplicação específicos, auxiliando assim na priorização de correções de segurança. O trabalho destaca o potencial de combinar agentes de codificação com feedback iterativo de execução para resolver tarefas complexas de engenharia de software que ferramentas tradicionais de análise estática não conseguem lidar efetivamente.