Resumo Técnico: De Executável a Verificável

Declaração do Problema

A comunidade de pesquisa em segurança depende cada vez mais de Modelos de Linguagem de Grande Escala (LLMs) e sistemas agentes para automatizar a validação de vulnerabilidades, incluindo a reprodução de CVEs conhecidos, geração de Proof-of-Concept (PoC) de exploração e reparo de código. Embora um crescente corpo de literatura alegue sucesso nessas tarefas, a qualidade dos artefatos que as acompanham varia significativamente.

Estudos de reprodutibilidade atuais tipicamente medem "disponibilidade" (o código é público?) e "executabilidade" (o código compila/roda?). No entanto, existe uma lacuna crítica e não mensurada entre um artefato que meramente executa e produz um sinal (por exemplo, um crash ou uma mensagem de log) e um que fornece confirmação semântica de que o CVE específico foi de fato reproduzido. Este estudo aborda a falta de métricas operacionalizadas para distinguir entre artefatos que simplesmente "executam e imprimem algo alarmante" e aqueles que validam rigorosamente uma reivindicação de vulnerabilidade específica contra a verdade fundamental (ground truth).

Metodologia

O autor conduziu uma auditoria de reprodutibilidade independente e pré-registrada da literatura de validação de vulnerabilidades impulsionada por LLM/agentes. O estudo emprega uma escada de evidência de quatro níveis para graduar os artefatos:

1. Disponível: O artefato é publicamente alcançável.
2. Executável (Runnable): O artefato completa seu fluxo de trabalho em um snapshot limpo (R0) ou após reparo mínimo compatível com o ambiente (R1), sem modificar a lógica do exploit ou o oráculo.
3. Produtor de Sinal: A execução gera sinais candidatos (crashes, mudanças de status ou marcadores específicos).
4. Semanticamente Confirmado: O sinal corresponde a uma pós-condição específica do CVE, validada via:
   • G3a (Controle Negativo): O sinal está ausente em entradas benignas.
   • G3b (Contrafactual Corrigido/Patched): O sinal está ausente na build corrigida.

Corpus e Amostragem:

• Busca: Um protocolo de busca congelado (2023–2026) através do arXiv, DBLP e OpenAlex resultou em 104 artigos em um corpus de consenso.
• Disponibilidade: 59 de 104 artigos (56,7%) possuíam artefatos publicamente alcançáveis.
• Amostra ao Nível de Artigo: 18 artigos foram selecionados para medir a executabilidade R0/R1 e o ônus de reparo.
• Amostra ao Nível de Caso: O estudo focou intensamente em um "benchmark âncora" (arXiv:2509.24037) contendo 102 casos distintos de vulnerabilidade. Um subconjunto de 20 casos serviu como piloto de calibração, enquanto os 82 restantes foram executados para formar uma análise de corpus completo.

Protocolo de Execução:

• R0: Execução em um snapshot limpo e congelado com zero modificação.
• R1: Execução após reparos apenas no ambiente (ex: instalar dependências ausentes, corrigir fontes de apt obsoletas/EOL) sem tocar na lógica do exploit, oráculos ou pós-condições.
• Auditoria de Oráculo: O estudo verificou independentemente a confiabilidade dos "oráculos incorporados ao artefato" (a lógica interna dos scripts para declarar um sucesso) contra a verdade fundamental do contrafactual corrigido.

Principais Descobertas

1. A Lacuna de Executabilidade (Runnability Gap)

Entre os 18 artefatos de nível de artigo testados:

• Apenas 10/18 (55,6%) completaram seu fluxo de trabalho declarado em um snapshot limpo (R0).
• Após reparos apenas no ambiente (R1), este número subiu ligeiramente para 11/18 (61,1%).
• Os 7 artefatos restantes falharam em ambos os níveis. Os modos de falha dominantes incluíram manifestos de dependências ausentes, gerenciadores de pacotes incompatíveis (ex: uv vs. pip) e dependência de serviços externos ou conjuntos de dados não incluídos no artefato.

2. Divergência Interna de Scripts

Uma questão estrutural significativa foi identificada no corpus âncora: 58/102 (56,9%) dos casos continham um identificador de CVE interno ao script que divergia do CVE declarado no diretório.

• Exemplo: Um diretório declarava CVE-2023-25668, mas o script executava um gatilho para CVE-2023-25676.
• Esta divergência compromete a validade da reivindicação de reprodução antes mesmo do início da execução e é invisível para auditorias padrão de disponibilidade.

3. Imprecisão dos Oráculos Incorporados ao Artefato

O estudo descobriu que os "oráculos" (a lógica interna que determina se um PoC teve sucesso) são sistematicamente não confiáveis.

• Contrafactuais Corrigidos (G3b): Dos 30 casos onde um sinal foi produzido e uma build corrigida foi auditada, 20/30 (66,7%) ainda produziram o sinal reivindicado na build corrigida. Esses sinais "sujos" indicam que o PoC dispara um crash genérico ou comportamento não relacionado à correção específica do CVE.
• Controles Negativos (G3a): Dos 19 casos testados contra entrada benigna, 7/19 dispararam falsos positivos.
• Desempenho do Oráculo: A matriz de confusão para os oráculos incorporados aos artefatos mostrou uma sensibilidade de 60% e especificidade de 45%.
  • Dois terços dos gatilhos de oráculo foram falsos positivos (sinais que persistem em builds corrigidas).
  • Sinais genuínos específicos de CVE foram perdidos pelo oráculo em 4/10 casos (frequentemente porque o oráculo procurava por um arquivo marcador específico que não foi criado, embora um exploit real tenha ocorrido).

4. A Lacuna de Confirmação Semântica

A confirmação estrita (E1), exigindo um sinal que passe por G2 (correspondência de pós-condição), G3a (controle negativo) e G3b (contrafactual corrigido), foi alcançada em apenas 2 casos de todo o corpus produtor de sinais.

• O estudo destaca que "disponibilidade → executável → produtor de sinal" não implica "semanticamente confirmado".
• Um gatilho em uma build vulnerável não é evidência de reprodução específica de CVE sem um contrafactual corrigido limpo.

Significância e Contribuições

O artigo posiciona-se como uma auditoria exploratória e pré-registrada que operacionaliza a "lacuna de confirmação semântica" pela primeira vez neste domínio. Suas principais contribuições são:

1. Um Protocolo de Reprodutibilidade: Um template reutilizável para a comunidade de segurança apresentando:
   • Pós-condições específicas de CVE.
   • Uma escada de reparo R0/R1.
   • Níveis de evidência semântica G1–G3.
   • Oráculos de contrafactual corrigido para distinguir a reprodução específica de CVE de crashes genéricos.
2. Evidência Empírica de Falha: O estudo demonstra que a maioria dos artefatos de validação de LLM/agente "bem-sucedidos" falha em fornecer confirmação semântica. Especificamente, a maioria dos casos produtores de sinal não sobrevive aos seus próprios contrafactuais corrigidos, e os oráculos internos são substitutos (proxies) ruins para a verdade fundamental.
3. Pacotes de Evidência Abertos: O autor libera protocolos congelados, decisões de triagem, folhas de reivindicação e logs de execução por caso para servir como linha de base para futuros estudos de reprodutibilidade.

O autor conclui que a comunidade de segurança deve ir além de verificações de strings de gatilho e exigir a verificação de contrafactual corrigido para validar reivindicações de reprodução de vulnerabilidades impulsionadas por LLM/agentes. O estudo observa que, embora estes sejam resultados exploratórios de um único corpus âncora e uma pequena amostra de artigos, os modos de falha identificados (IDs de CVE divergentes, oráculos não confiáveis, falta de verificação de contrafactual corrigido) sugerem um problema sistêmico na qualidade atual dos artefatos.