Resumo Técnico: Do Veredito ao Diagnóstico: Revisão de Segurança Atribuível de Pull Requests

1. Definição do Problema: O Gap Veredito–Diagnóstico (VD)

Os revisores de código automatizados atuais são avaliados primariamente por sua capacidade de emitir um veredito de "bloqueio" para Pull Requests (PRs) maliciosos. No entanto, o artigo identifica uma falha crítica nesse paradigma de avaliação: um revisor pode bloquear corretamente um PR pelo motivo errado. Um bloqueio pode ser disparado por um problema não relacionado (ex: um erro de formatação ou um aviso não crítico) em vez da vulnerabilidade específica que torna o PR inseguro.

Essa discrepância é denominada gap Veredito–Diagnóstico (VD).

• Veredito: A decisão de aprovar ou bloquear um PR.
• Diagnóstico: A identificação específica da vulnerabilidade e a evidência que a sustenta.
• O Gap: Um veredito de bloqueio correto acompanhado de um diagnóstico incorreto ou não fundamentado. Nesses casos, os esforços de remediação são direcionados erroneamente, deixando a vulnerabilidade real sem tratamento.

O artigo argumenta que os benchmarks e métricas de avaliação existentes falham em distinguir entre um sistema que meramente "bloqueia" e um que "diagnostica" corretamente o defeito de segurança subjacente. Além disso, muitas vulnerabilidades (particularmente defeitos do tipo "ausência", onde um guarda necessário está faltando) exigem evidências de partes não alteradas do repositório, o que a análise baseada apenas em diff frequentemente deixa passar.

2. Metodologia

2.1 MALPR-BENCH: Um Benchmark Baseado em Mecanismos

Para medir o gap VD, os autores introduzem o MALPR-BENCH, um benchmark projetado para avaliar três dimensões distintas separadamente:

1. Corretude do Veredito (V): O sistema bloqueou o PR?
2. Identificação do Alvo da Vulnerabilidade (I): O sistema identificou corretamente o mecanismo específico da vulnerabilidade?
3. Validação de Evidência (E): O sistema fundamentou seu diagnóstico em fatos concretos e auditáveis do repositório (locais de código, arquivos não alterados, etc.)?

Construção:

• Escala: 89 PRs maliciosos e 50 controles benignos em 44 repositórios e oito famílias de linguagens.
• Fontes:
  • Histórico Minerado: Recuperação de correções incompletas de históricos de projetos.
  • Derivado de Avisos (Advisory-Derived): Construção de estados maliciosos a partir de avisos de segurança públicos (Pool A: correção incompleta; Pool B: reversão de aplicação de regras).
  • Descoberta no Mundo Real: Vulnerabilidades anteriormente não divulgadas encontradas pela ferramenta dos autores.
• Verdade Fundamental (Ground Truth): Cada caso inclui uma "rubrica congelada" especificando o alvo da vulnerabilidade, a cadeia de evidência necessária e descrições aceitas. Isso permite uma graduação precisa de se uma revisão é "atribuível" (isto é, $A = V \land I \land E$).
• Classificação de Defeitos: Os casos são categorizados como Tipo-Presença (o comportamento inseguro é visível no diff) ou Tipo-Ausência (a aplicação de segurança necessária está ausente). As localizações de evidência são classificadas de L0 (apenas o diff) a L2b (correspondência semântica em arquivos não relacionados).

2.2 PRGUARD: Um Revisor de Segurança de PR Atribuível

Para abordar o gap VD, os autores propõem o PRGUARD, um sistema que separa a identificação da vulnerabilidade da validação da evidência. Diferente de modelos de ponta a ponta que saltam do diff para o veredito, o PRGUARD opera através de um pipeline em estágios:

• Estágio 0 (Coleta Estrutural): Coleta deterministicamente o contexto estrutural (chamadores, chamados, importações) ao redor do código alterado antes de qualquer raciocínio do modelo.
• Estágio 1 (Caracterização da Mudança): O modelo descreve o comportamento relevante para a segurança da mudança sem propor uma vulnerabilidade específica ainda.
• Estágios 2 & 2.5 (Aquisição de Evidência):
  • Caminho 1 (Direcionado por Conhecimento): Utiliza uma Base de Conhecimento (KB) de mecanismos derivada de casos de desenvolvimento para recuperar evidências específicas do repositório via relações tipadas (ex: SIBLING-ENDPOINT).
  • Caminho 2 (Direcionado por Código): Constrói uma lista de caminhos do repositório baseada na estrutura do código alterado, independentemente da KB.
• Estágio 3 (Construção de Candidato): Formula candidatas concretas de vulnerabilidades baseadas na evidência coletada.
• Estágio 4 (Validação de Evidência): Uma invocação de modelo separada testa as candidatas contra a evidência do repositório. Ela verifica premissas de segurança críticas (controle do atacante, alcançabilidade, guardas ausentes). As candidatas são marcadas como VALIDADAS, REBAIXADAS (DOWNGRADED) ou REJEITADAS.
• Estágio 5 (Síntese da Revisão): Uma política determinística mapeia os resultados de validação para um veredito (Bloquear, Comentar, Aprovar) e sintetiza uma revisão que explica os achados validados com locais de código específicos.

3. Principais Contribuições

1. Formulação do Gap VD: O artigo define e caracteriza a discrepância entre um veredito de bloqueio correto e um diagnóstico correto, argumentando que as métricas de avaliação atuais ocultam esse modo de falha.
2. MALPR-BENCH: Um framework de avaliação sistemática e benchmark que separa a corretude do veredito da identificação da vulnerabilidade e da validação da evidência, utilizando rubricas pré-comprometidas para a verdade fundamental.
3. PRGUARD: Uma arquitetura de revisor de segurança de PR atribuível que desacopla a geração de hipóteses da validação de evidência e recupera contexto além do diff.
4. Validação Empírica: Demonstração de que separar a identificação da validação melhora a atribuição de achados de segurança, particularmente para defeitos do tipo ausência.

4. Resultados

4.1 Desempenho no Conjunto de Desafio de Cobertura Comum

Avaliado em 31 PRs maliciosos retidos (19 de generalização própria + 12 de descoberta) contra o CodeRabbit (um revisor de IA comercial amplamente implantado):

• Desempenho de Bloqueio: Ambos os sistemas alcançaram taxas de bloqueio semelhantes (CodeRabbit: 24/31; PRGUARD/DeepSeek: 22/31).
• Identificação de Vulnerabilidade (I): O PRGUARD/DeepSeek identificou 1,38× mais vulnerabilidades alvo do que o CodeRabbit (22 vs. 16).
• Defeitos do Tipo Ausência: Em 14 casos onde um guarda necessário estava faltando, ambos os sistemas bloquearam 9 PRs. No entanto, o PRGUARD/DeepSeek identificou a vulnerabilidade alvo em 9/14 casos, enquanto o CodeRabbit identificou em apenas 3/14 (uma diferença de 3×).
• Bloqueios Atribuíveis (A): O PRGUARD/DeepSeek alcançou 19/31 bloqueios atribuíveis, comparado a 16/31 do CodeRabbit.
• Localização de Evidência: O CodeRabbit falhou em identificar alvos em 0/7 casos que exigiam evidência fora dos arquivos tocados (L2a/L2b), enquanto o PRGUARD teve sucesso na maioria.

4.2 Avaliação do Pipeline Completo

Em 63 casos maliciosos retidos (excluindo o nível de descoberta para evitar viés):

• Pool B (Reversão de Aplicação de Regras): Ambos os backends (GPT-5.5 e DeepSeek) identificaram todas as 37 vulnerabilidades alvo (I=37/37). No entanto, a validação de evidência (E) variou (26/37 para GPT-5.5, 34/37 para DeepSeek), destacando que a identificação não garante o embasamento de evidência válido.
• Controles Benignos: O PRGUARD mostrou baixas taxas de falsos positivos (4–5 bloqueios em 50 controles benignos), comparável ao CodeRabbit (0 bloqueios em um subconjunto de 6 controles).

4.3 Descoberta no Mundo Real

Aplicado a repositórios de produção, o PRGUARD descobriu 12 vulnerabilidades anteriormente não divulgadas, com prova de conceito, em cinco projetos amplamente utilizados.

• Execuções independentes do PRGUARD e do CodeRabbit bloquearam 10/12 PRs neste nível de descoberta.
• No entanto, o PRGUARD produziu 10/12 bloqueios atribuíveis, enquanto o CodeRabbit produziu apenas 4/12, demonstrando que totais de veredito idênticos podem mascarar uma diferença de 2,5× na qualidade do diagnóstico.

5. Significância e Alegações

O artigo alega que o gap Veredito–Diagnóstico é uma limitação fundamental na revisão de segurança automatizada atual. Um bloqueio "bem-sucedido" é insuficiente se não identificar e substanciar corretamente a vulnerabilidade, pois isso leva a uma remediação ineficaz.

• Atribuibilidade é a Chave: Os autores argumentam que as revisões de segurança devem ser atribuíveis — o veredito deve ser fundamentado em evidências específicas do repositório que validem o mecanismo identificado.
• Separação de Preocupações: Os resultados sugerem que separar as tarefas de identificar uma candidata a vulnerabilidade e validá-la contra a evidência melhora a confiabilidade do diagnóstico, particularmente para defeitos complexos que exigem contexto entre múltiplos arquivos.
• Limitações: O artigo reconhece que o PRGUARD não é uma solução definitiva. Ele trata o prompt injection e erros de julgamento como superfícies de ataque residuais. A descoberta de vulnerabilidades no mundo real demonstra capacidade, mas não pretende estimar a taxa de recall em PRs arbitrários, já que o fluxo de candidatos foi filtrado para validação manual.

Em resumo, o trabalho desloca o foco da avaliação de "ele bloqueou?" para "ele bloqueou pelo motivo certo, com provas?", introduzindo uma metodologia e um conjunto de ferramentas para medir e mitigar os riscos de revisões de segurança mal diagnosticadas.