Security Is Relative: Training-Free Vulnerability Detection via Multi-Agent Behavioral Contract Synthesis

1. O Problema: Ambiguidade Semântica e Falha de Modelos Atuais

O artigo identifica uma crise fundamental na detecção automática de vulnerabilidades de software baseada em aprendizado profundo. Embora modelos anteriores tenham obtido bons resultados em benchmarks antigos (como Big-Vul), avaliações rigorosas no novo benchmark PrimeVul (ICSE 2025) revelaram uma degradação catastrófica de desempenho (queda de F1 > 0,68 para 0,031).

Causa Raiz: O Problema da Ambiguidade Semântica
Os autores argumentam que o fracasso ocorre porque a segurança não é uma propriedade absoluta da sintaxe do código, mas sim relativa aos contratos comportamentais específicos do projeto.

• O Paradoxo do "Padrão Duplo": O mesmo padrão de código pode ser seguro em um contexto e vulnerável em outro, dependendo de sanitizadores, convenções arquitetônicas ou contexto de tempo de execução.
• Evidência Empírica: No conjunto de dados PrimeVul, existem pares de código com >99% de similaridade de sequência que recebem rótulos opostos (vulnerável vs. corrigido) dependendo de qual CVE está sendo avaliado.
• Limitação dos Abordagens Atuais:
  • Modelos de Aprendizado Supervisionado: Aprendem apenas correlações superficiais e vazamento de dados, não a semântica real.
  • RAG (Geração Aumentada por Recuperação): Baseiam-se em similaridade de padrões históricos, falhando em falhas lógicas de dia zero.
  • Análise Estática Agêntica: Frequentemente dependem de linguagens de consulta específicas ou falham devido à diluição da atenção ao adicionar contexto sem diretrizes explícitas.

2. Metodologia: O Framework Phoenix

O Phoenix é um framework multi-agente sem treinamento (zero-shot) que transforma a detecção de vulnerabilidades de um problema de classificação aberta para um problema de verificação de contrato fechado. A inovação central é o uso de Especificações Gherkin (um formato BDD - Behavior-Driven Development) como representação intermediária estruturada.

O pipeline consiste em três agentes especializados:

1. Agente 1: Semantic Slicer (Fatiador Semântico)

   • Função: Recebe o par de código (vulnerável + corrigido) e a descrição do CVE.
   • Ação: Extrai o contexto mínimo relevante para a vulnerabilidade, removendo código "boilerplate" e ruído.
   • Resultado: Reduz o tamanho médio do código de entrada em 82,8% (de ~5.300 para ~900 caracteres), focando a atenção dos agentes subsequentes na mecânica exata da falha.

2. Agente 2: Requirement Reverse Engineer (Engenheiro Reverso de Requisitos)

   • Função: Analisa o "diff" (diferença) entre o código vulnerável e o corrigido.
   • Ação: Sintetiza uma Especificação Gherkin (formato Given-When-Then) que codifica o "contrato de segurança" explícito.
   • Inovação: Em vez de apenas classificar, este agente define o que o código deve fazer para ser seguro. Ele transforma a lógica de segurança implícita em um contrato formal e legível.

3. Agente 3: Contract Judge (Juiz de Contrato)

   • Função: Avalia amostras de código individualmente contra a especificação Gherkin gerada.
   • Ação: Realiza uma verificação estrita de conformidade. O juiz não precisa "descobrir" a vulnerabilidade; ele apenas verifica se o código satisfaz os cenários definidos no contrato.
   • Vantagem: Isso reduz a carga cognitiva do modelo, permitindo que modelos menores (7B-14B) alcancem desempenho superior ao de modelos massivos sem treinamento.

3. Contribuições Principais

1. Arquitetura Phoenix: Um framework multi-agente sem treinamento que alcança F1 = 0,825 e Pair-Correct = 64,4% no PrimeVul Paired Test Set.
2. Uso de Especificações Gherkin: Introdução de contratos comportamentais estruturados como representação intermediária, resolvendo a ambiguidade semântica ao vincular a verificação a requisitos específicos do projeto.
3. Desempenho com Modelos Pequenos: O sistema supera modelos proprietários massivos (como DeepSeek-V3 de 671B) e modelos de debate (VulTrial), utilizando apenas modelos de código aberto de 7B a 14B (até 48x menores).
4. Análise de "Falsos Positivos" como Descoberta: Demonstração empírica de que 18% dos "falsos positivos" do Phoenix identificaram preocupações de segurança reais em código que os desenvolvedores consideravam corrigido, provando que a segurança é relativa ao contrato e não absoluto.

4. Resultados Experimentais

Os experimentos foram conduzidos no conjunto de dados PrimeVul Paired (435 pares de commits, 859 amostras efetivas) usando 5 famílias de LLMs.

• Comparação com o Estado da Arte (SOTA):
  • Phoenix: F1 = 0,825, Pair-Correct = 64,4%.
  • RASM-Vul (DeepSeek-V3 671B): F1 = 0,668, Pair-Correct = 21,4%.
  • VulTrial (GPT-4o Multi-Agente): F1 = 0,563, Pair-Correct = 18,6%.
• Estudo de Ablação (O que impulsiona o desempenho?):
  • A adição da especificação Gherkin (Agente 2) foi o fator decisivo, melhorando o F1 em +0,09 a +0,35 em todos os modelos.
  • O Agente 1 (Slicing) teve um impacto menor (+0,00 a +0,06).
  • Modelos especializados em código (Qwen2.5-Coder-14B) produziram as melhores especificações, enquanto modelos de raciocínio equilibrado (Qwen3.5-9B) foram os melhores juízes.
• Análise de Erros:
  • Falsos Positivos (FP): 18% dos FPs do Phoenix eram, na verdade, vulnerabilidades reais que o patch original não resolveu completamente (ex: comentários de desenvolvedores "TODO" ignorados ou novos overflow introduzidos na correção).
  • Falsos Negativos (FN): A maioria (73%) ocorreu porque o Agente 3 verificou superficialmente a existência de uma verificação de limite, sem perceber que a lógica da verificação era inválida (ex: while (u >= 0) com inteiro sem sinal).

5. Significado e Conclusão

O trabalho estabelece que a detecção de vulnerabilidades não deve ser tratada como um problema de classificação global de padrões, mas como um problema de verificação de conformidade a contratos comportamentais específicos.

• Mudança de Paradigma: O Phoenix demonstra que a reestruturação do problema (de f(código) -> {seguro, vulnerável} para (código, contrato) -> {conforme, não-conforme}) é mais eficaz do que simplesmente aumentar o tamanho do modelo ou a profundidade do debate entre agentes.
• Viabilidade Prática: O sistema funciona sem dados de treinamento, utilizando apenas modelos de código aberto pequenos, o que o torna economicamente viável e escalável.
• Futuro: Sugere-se que, em ambientes de produção, os contratos Gherkin podem ser extraídos de suites de testes BDD existentes ou políticas de segurança, eliminando a necessidade de reengenharia reversa automática para cada novo código.

Em resumo, o Phoenix prova que a segurança é relativa e que a síntese de contratos comportamentais é a chave para superar as limitações atuais da IA na detecção de vulnerabilidades.