Resumo Técnico: Snyk VulnBench JS 1.0

Declaração do Problema

À medida que agentes de codificação e Modelos de Linguagem de Grande Escala (LLMs) se integram ao ciclo de vida de desenvolvimento de software para realizar revisões de segurança, surge uma questão crítica de confiabilidade: a revisão de segurança por agentes de LLM é repetível? Ao contrário das ferramentas tradicionais de Teste de Segurança de Aplicações Estáticas (SAST), que são determinísticas e produzem saídas idênticas para entradas idênticas, os LLMs são probabilísticos. Eles podem variar em suas descobertas entre as execuções, relatar excessivamente preocupações adjacentes ou parar após identificar uma única instância de um padrão repetido.

O artigo aborda a falta de dados empíricos que quantifiquem essa variabilidade. Ele busca determinar se um agente de LLM, quando apresentado ao mesmo código JavaScript vulnerável e ao mesmo prompt múltiplas vezes, reportará os mesmos problemas de segurança de forma consistente.

Metodologia

Os autores introduziram o Snyk VulnBench JS 1.0, um benchmark projetado para medir a repetibilidade e o acordo sob condições controladas.

• Conjunto de Dados: O benchmark consiste em 10 pequenos fixtures de aplicações JavaScript e baseadas em Express. Eles variam de trechos de arquivo único até uma aplicação "todo" maior (aprox. 380 linhas) apresentando rotas de servidor, interações com banco de dados, uploads de arquivos e lógica de frontend.
• Padrão de Referência: O Snyk Code (uma ferramenta SAST determinística) serve como o conjunto de referência. O benchmark não afirma que o Snyk Code identifica todas as vulnerabilidades possíveis; em vez disso, utiliza a capacidade do Sete Code de identificar reproduzivelmente suas próprias descobertas de referência como a linha de base para medição.
• Design Experimental:
  • Modelos: Seis configurações foram testadas usando o harness Claude Code e o TypeScript Agent SDK:
    • Claude Opus 4.6 (Medium, High)
    • Claude Opus 4.7 Max
    • Claude Sonnet 4.6 (Medium, High)
  • Repetições: Cada uma das 10 tarefas foi executada 5 vezes por configuração, totalizando 300 execuções.
  • Restrições: Os modelos receberam o mesmo prompt de auditoria e arquivos do projeto, mas foram explicitamente impedidos de ler o arquivo de referência findings.json.
• Mecanismo de Pontuação:
  • F1 da Referência Snyk: A métrica principal é a média harmônica da precisão e do recall, tratando as descobertas do Snyk Code como a verdade fundamental (ground truth).
  • Leniência: Uma descoberta do modelo é creditada se ele reportar o mesmo tipo de vulnerabilidade que uma descoberta de referência, independentemente do arquivo exato, linha, severidade ou caminho fonte-para-destino (source-to-sink).
  • Métricas de Estabilidade: O estudo rastreia com que frequência descobertas específicas (tanto correspondentes quanto não correspondentes) aparecem ao longo das cinco repetições.

Principais Contribuições

1. Quantificação da Variância de LLM: O artigo fornece a primeira medição sistemática de como as descobertas de segurança de LLM variam entre execuções idênticas, distinguindo entre estabilidade de "correspondência com a referência" e ruído de relatórios "extras".
2. Demonstração de Complementaridade: Demonstra empiricamente que LLMs e ferramentas SAST determinísticas falham de maneiras diferentes, sugerindo que eles são complementares em vez de intercambiáveis.
3. Análise de Custo vs. Desempenho: O estudo avalia se modelos maiores e mais caros geram melhor cobertura de segurança ou estabilidade.
4. Identificação de Lacunas de Produto: A metodologia do benchmark conseguiu evidenciar potenciais lacunas na ferramenta de referência SAST (Snyk Code), onde os LLMs identificaram vulnerabilidades válidas que a ferramenta SAST omitiu.

Resultados

1. Repetibilidade e Estabilidade

• Descobertas Correspondentes à Referência: Quando os LLMs identificavam vulnerabilidades já encontradas pelo Snyk Code, eles eram geralmente estáveis. 84,8% das descobertas únicas correspondentes à referência apareceram em todas as cinco repetições.
• Descobertas Não Correspondentes (O "Ruído"): As descobertas não presentes no conjunto de referência do Snyk Code foram altamente instáveis.
  • 49,7% das descobertas únicas não correspondentes apareceram em apenas uma das cinco execuções.
  • Apenas 13,7% das descobertas não correspondentes apareceram em todas as cinco execuções.
  • Variância do Modelo: O Claude Sonnet 4.6 Medium produziu os relatórios "extras" mais instáveis, com 61,7% de suas descobertas não correspondentes aparecendo em apenas uma execução. Em contraste, o Claude Opus 4.6 Medium foi o mais estável, com 0% de suas descobertas não correspondentes aparecendo em apenas uma execução.

2. Cobertura e Desempenho

• Scores F1: A melhor configuração de LLM (Claude Opus 4.6 Medium) alcançou um score F1 de referência Snyk de 75,4%, deixando uma lacuna de 24,6 pontos em relação à linha de base determinística do SAST (100,0%).
• Desempenho por Classe de Vulnerabilidade:
  • Pontos Fortes: Os LLMs tiveram bom desempenho em formas de exploração familiares e de alto sinal, como injeção de comando, injeção de código, credenciais codificadas (hardcoded), injeção de SQL, SSRF e poluição de protótipo (prototype pollution).
  • Pontos Fracos: Os LLMs tiveram dificuldades com classes sistemáticas de SAST, incluindo descobertas de limite de recursos, sanitização imprópria, validação de tipo, transporte inseguro e fluxos repetidos de travessia de diretório (path traversal).
• Estudo de Caso (js-project-nightowl): No maior fixture, o melhor modelo (Claude Opus 4.6 High) alcançou apenas 40,0% de F1 de referência Snyk. Ele consistentemente perdeu vulnerabilidades de travessia de diretório e limites de recursos, falhando em enumerar destinos de fluxo de dados repetidos, onde a análise determinística se destacou.

3. Custo vs. Qualidade

• Retornos Decrescentes: O modelo mais caro, Claude Opus 4.7 Max, custou 5,7x mais e utilizou 1,9x mais tokens do que o melhor modelo, o Claude Opus 4.6 Medium.
• Desempenho: Apesar do custo mais elevado, o Opus 4.7 Max obteve uma pontuação menor (68,8% F1) do que o Opus 4.6 Medium (75,4% F1).
• Conclusão: Um custo de inferência mais alto não se traduz automaticamente em melhor cobertura ou estabilidade de segurança.

4. Complementaridade e Lacunas de Produto

O estudo identificou instâncias específicas onde os LLMs encontraram problemas válidos que o SAST omitiu:

• Falsos Positivos: Alguns relatórios de LLM tinham "forma de vulnerabilidade", mas não eram exploráveis (ex: um relatório de injeção de SQL em uma função auxiliar mock que retorna um array vazio).
• Verdadeiros Positivos (Lacunas de Produto): No fixture js-project-nightowl, os LLMs reportaram vulnerabilidades de injeção de SQL que não estavam no conjunto de referência do Snyk Code. Os autores argumentam que estes são provavelmente achados válidos representando uma lacuna na cobertura da ferramenta SAST, em vez de alucinações.

Significância e Alegações

O artigo conclui que a revisão de segurança por agentes de LLM não é uniformemente repetível. Embora os LLMs possam identificar efetivamente vulnerabilidades familiares e de alto sinal, seus relatórios "extras" são frequentemente ruidosos e inconsistentes.

• Não é um Substituto: Os resultados argumentam contra o tratamento de LLMs como um substitor para o SAST determinístico. O SAST é superior para enumerar sistematicamente destinos de fluxo de dados repetidos e é determinístico.
• Abordagem Complementar: A estratégia ideal é um fluxo de trabalho combinado. O SAST determinístico fornece uma linha de base estável para padrões conhecidos, enquanto os agentes de LLM podem trazer à tona preocupações adjacentes e potenciais lacunas de produto (como a injeção de SQL no js-project-nightowl) que os analisadores estáticos perdem.
• Trabalhos Futuros: Os autores reconhecem as limitações do benchmark atual (pequenos trechos, falta de uma verdade fundamental independente) e propõem futuras liberações para incluir aplicações completas, vulnerabilidades de lógica de negócio e fontes de adjudicação independentes (ex: dados do estilo BaxBench).

O artigo enfatiza que o objetivo não é declarar um "vencedor" em um sentido de ranking, mas sim medir a repetibilidade, variância e complementaridade dessas tecnologias para informar como elas devem ser integradas em ciclos de desenvolvimento seguro.