Resumo Técnico: JavaVulBench

Declaração do Problema

A detecção de vulnerabilidades baseada em aprendizado profundo historicamente dependeu de corpora de C/C++ (ex: Big-Vul, Devign), deixando o Java — uma linguagem amplamente implantada em ambientes corporativos — subavaliado. Benchmarks focados em Java existentes (Vul4J, VJBench, CWE-Bench-Java, CVEfixes) sofrem de lacunas metodológicas críticas: frequentemente carecem de amostras explicitamente não vulneráveis, granularidade ao nível de linha, múltiplos splits realistas e harnesses de avaliação unificados. Crucialmente, avaliações anteriores utilizam frequentemente splits aleatórios em corpora multilíngues, uma prática que Chakraborty et al. [5] demonstraram inflar as métricas de desempenho (scores F1) em 15–40 pontos devido ao vazamento de dados (data leakage) entre os conjuntos de treinamento e teste (ex: métodos quase duplicados do mesmo projeto). Há uma falta de infraestrutura para auditar a contaminação de pré-treinamento, tornando difícil distinguir a generalização genuína da memorização.

Metodologia

1. Construção do Dataset (JavaVulBench)

Os autores construíram um corpus de aproximadamente 30.600 métodos Java abrangendo 1.740 CVEs e mais de 700 projetos (2015–2025).

• Mineração: Registros de CVE foram mesclados do NIST, GitHub Security Advisories e CVEfixes. Os commits de correção (fix commits) foram resolvidos, e snapshots pré/pós-correção foram extraídos usando uma gramática tree-sitter para preservar a proveniência de método, classe e arquivo. Um filtro de ruído removeu commits apenas de testes, apenas de formatação e apenas de refatoração.
• Rotulagem: Métodos vulneráveis foram pareados com seus contrapartes corrigidos. Amostras não vulneráveis (negativas) foram extraídas de três estratégias por método vulnerável: mesmo arquivo (3:1), mesmo projeto (2:1) e projeto aleatório (1:1).
• Granularidade: Os rótulos existem tanto ao nível de método quanto de linha, incluindo datas de publicação de CVE e tags CWE.
• Estratégias de Split: Cinco estratégias de partição realistas são fornecidas como JSONL:
  1. Aleatório (Random): Referência otimista.
  2. Desjunto de Projeto (Project-Disjoint): Sem sobreposição de projetos entre treino e teste.
  3. Temporal: Treina em CVEs antes de 2023; testa em 2023–07 em diante.
  4. Desduplicado (Deduplicated): Remove quase-duplicatas (Jaccard 0.8) antes da divisão.
  5. Família de CWE Não Vista (Unseen CWE-Family): Retém famílias inteiras de CWE para testar a generalização entre classes.

2. Harness de Avaliação Unificado

Um esquema único LlmPrediction unifica a avaliação através de três famílias de backends:

• Classificadores Encoder: HuggingFace Transformers (CodeBERT, GraphCodeBERT, UniXcoder).
• Modelos Generativos Locais: Modelos servidos via Ollama (ex: DeepSeek-Coder-1.3B) em configurações zero-shot e LoRA-fine-tuned.
• LLMs via API: Modelos roteados via OpenRouter (GPT-4o, GPT-4.1-mini, Claude Sonnet 4, DeepSeek-v3, DeepSeek-Coder-v2, Qwen-2.5-Coder, CodeLlama-13B).

O harness suporta zero-shot, few-shot e Geração Aumentada de Recuperação (RAG) usando uma base de conhecimento específica de Java de descrições de MITRE CWE e padrões de uso indevido de API de OWASP/CERT. Para gerenciar custos, as avaliações de API utilizam um subconjunto estratificado de 200 amostras por split.

3. Avaliação Consciente de Vazamento (Leakage-Aware)

Uma auditoria de contaminação de pré-treinamento particiona os conjuntos de teste em subconjuntos "arriscados" (CVEs publicados antes do cutoff do modelo) e "limpos" (publicados depois). Isso permite que as métricas sejam reportadas separadamente para evitar que a memorização seja confundida com a generalização.

Principais Contribuições

1. O Dataset: Um corpus fundamentado em CVE de ~30.600 métodos com rótulos de método/linha, 225 categorias CWE e cinco estratégias de split realistas.
2. O Harness: Um pipeline de avaliação unificado, de comando único, suportando classificadores encoder, LLMs locais e LLMs via API sob condições idênticas.
3. Auditoria de Contaminação: Um mecanismo de auditoria por modelo para identificar e separar amostras de teste potencialmente memorizadas.
4. Reprodutibilidade: Um pipeline de reprodução dockerizado, de um único comando, com checkpoints ajustados (fine-tuned) e dados arquivados no Zenodo.

Resultados

Impacto da Estratégia de Split

A mudança do split aleatório para o split desjunto de projeto reproduz a queda de desempenho observada em C/C++ por Chakraborty et al. [5]:

• UniXcoder: O F1 cai de 0.446 (aleatório) para 0.298 (desjunto de projeto).
• GraphCodeBERT: O F1 cai de 0.343 para 0.256.
• CodeBERT: O F1 colapsa para 0.000 nos splits desjunto de projeto e temporal, pois o modelo assume o padrão de prever a classe majoritária devido à falta de superfícies de API sobrepostas em seus dados de pré-treinamento.
• Conclusão: Splits desjuntos de projeto devem ser tratados como a métrica principal padrão; splits aleatórios servem apenas como referências otimistas.

Desempenho dos Modelos

• Encoders: Encoders ajustados (UniXcoder, GraphCodeBERT) alcançam scores F1 moderados (~0.25–0.30) em splits desjuntos de projeto.
• API LLMs: Em uma sonda de 200 amostras com custo equivalente, o GPT-4o (F1=0.419) e o Claude Sonnet 4 (F1=0.416) superam todos os baselines de encoder. O GPT-4o também demonstra a melhor calibração (ECE=0.147).
• DeepSeek-Coder-v2: Mostra um MCC negativo (-0.108), indicando desempenho abaixo do acaso em detecção de vulnerabilidades Java em sua configuração zero-shot.
• CodeLlama-13B: Exibe o maior PR-AUC (0.540), sugerindo um ranking de confiança útil, apesar de um F1 baseado em limiar mais fraco.

Auditoria de Contaminação

No split temporal, modelos com cutoffs de 2024–2025 (ex: Claude Sonnet 4, GPT-4.1-mini) marcam até 59% do conjunto de teste como "arriscado". Curiosamente, os modelos de API mais fortes mostram scores F1 mais altos no subconjunto "limpo" em comparação ao conjunto total, sugerindo que o subconjunto arriscado contém variantes de CVE mais difíceis em vez de variantes facilmente memorizadas.

Significância e Alegações

O artigo afirma que a estratégia de split é uma propriedade de primeira classe de qualquer número de benchmark de detecção de vulnerabilidades. O principal achado empírico é que, sem splits desjuntos de projeto ou temporais, os scores F1 reportados para a detecção de vulnerabilidades em Java são significativamente inflados devido ao vazamento de dados.

O JavaVulBench fornece a infraestrutura necessária (harness unificado, splits realistas e auditorias de contaminação) para tornar esses estudos reproduzíveis e garantir que as melhorias reportadas reflitam a generalização genuína em vez de memorização ou vazamento de dados. Os autores posicionam este trabalho como o preenchimento da lacuna entre os benchmarks de Java existentes e os padrões de avaliação rigorosos exigidos para a detecção de vulnerabilidades em nível empresarial.