Snyk VulnBench JS 1.0: LLMs conseguem encontrar os mesmos bugs duas vezes?

Executamos 300 varreduras de detecção de vulnerabilidades para medir a repetibilidade de uma análise de segurança agentiva com LLM sobre o mesmo código, prompt e ambiente de execução. O principal resultado não é que um scanner “vence” um placar autorreferencial. É que as descobertas de segurança dos LLMs têm repetibilidade irregular: as descobertas alinhadas à referência foram estáveis, mas os relatórios adicionais dos modelos variaram bastante de uma execução para outra.

Em termos simples, quando Claude relatou bugs que não estavam na lista de referência do Snyk Code, esses relatórios adicionais muitas vezes foram inconsistentes. Em 250 execuções dos modelos, 80 das 161 descobertas únicas não correspondentes apareceram em apenas uma de cinco repetições idênticas, enquanto somente 22 apareceram nas cinco. Mas, quando Claude encontrou uma descoberta da referência, o comportamento foi bem mais estável: 134 das 158 descobertas únicas correspondentes à referência apareceram nas cinco repetições. Essa diferença é o principal resultado do Snyk VulnBench JS 1.0.

O benchmark também demonstra complementaridade. Os modelos identificaram de forma consistente padrões de exploração conhecidos e com alto sinal e, em um caso, apontaram uma provável lacuna nas descobertas do Snyk Code. O SAST do Snyk Code foi determinístico e melhor na enumeração sistemática de pontos de destino repetidos em fluxos de dados, além de manter tempos de execução significativamente rápidos na varredura de vulnerabilidades. Nenhum desses resultados justifica substituir uma técnica pela outra. Os dados apontam para a combinação das duas.

Principais destaques:

• A configuração de LLM com maior recall encontrou apenas 81% das vulnerabilidades de referência do Snyk Code.

• A configuração de LLM com melhor pontuação chegou a 75,4% de F1 em relação à referência do Snyk, uma diferença de 24,6 pontos em relação à reprodução determinística da referência pelo SAST.

• Quase 50% dos relatórios de vulnerabilidade exclusivos dos LLMs apareceram em apenas 1 de 5 varreduras idênticas.

• O LLM com maior recall também gerou a fila mais ruidosa: 41% dos relatórios ficaram fora do conjunto de referência do Snyk Code.

• No maior projeto de teste, semelhante a um app, o melhor modelo obteve apenas 40,0% de F1 em relação à referência do Snyk e deixou passar repetidamente vulnerabilidades de path traversal e de limite de recursos.

Por que a análise de segurança com LLM precisa ser repetível

Os agentes de codificação já fazem parte do ciclo de desenvolvimento. Eles escrevem código, modificam pull requests, explicam alterações e são cada vez mais usados para analisar o código e a segurança de aplicações antes que uma pessoa leia as diferenças. Isso transforma a confiabilidade em uma questão de produto: se o mesmo agente analisar duas vezes o mesmo código vulnerável, vai relatar os mesmos problemas de segurança nas duas ocasiões?

As ferramentas tradicionais de SAST são projetadas para ser determinísticas. Se o código e as regras não mudam, o resultado também não deve mudar. Os LLMs são diferentes. Eles conseguem raciocinar sobre código desconhecido, descrever riscos com clareza e, às vezes, identificar problemas que passam despercebidos por um analisador estático. Mas também podem variar entre execuções, relatar preocupações adjacentes em excesso ou parar depois de encontrar um exemplo representativo de um padrão repetido.

O Snyk VulnBench JS 1.0 foi criado para quantificar esse comportamento. O benchmark usa pequenas aplicações em JavaScript e Express, para que cada execução possa ser inspecionada. A ideia não é simular um monorepo inteiro, mas tornar o comportamento dos modelos mensurável em condições controladas e repetidas.

Desenho do benchmark: 300 execuções repetidas de segurança

O benchmark contém 10 projetos de teste em JavaScript, com 44 descobertas de referência do Snyk Code. Cada projeto é uma pequena aplicação baseada em Express, desde trechos compactos de um único arquivo até um app de lista de tarefas maior, com rotas de servidor, estado em banco de dados, uploads e JavaScript no frontend.

Avaliamos seis configurações:

Cada configuração executou cada tarefa cinco vezes: 10 tarefas x 6 configurações x 5 repetições = 300 execuções. As configurações dos modelos usaram o mesmo prompt de auditoria direta e retornaram as descobertas em JSON estruturado. O modelo podia ler os arquivos do projeto, mas não o arquivo de referência findings.json.

O Snyk Code define o conjunto de referência deste benchmark. Isso significa que sua pontuação de 100% não é uma afirmação de precisão em relação a todas as vulnerabilidades possíveis nos projetos. Significa que o Snyk Code reproduziu suas próprias descobertas de referência de forma determinística em execuções repetidas. Usamos esse conjunto de referência para medir a concordância e a variação dos modelos, além de identificar onde o comportamento deles diverge.

O critério de avaliação é intencionalmente flexível: uma descoberta do modelo é contabilizada se relatar o mesmo tipo de vulnerabilidade que uma descoberta de referência. Não é necessário corresponder ao mesmo arquivo, linha, gravidade ou caminho da origem ao destino. Reportamos o F1 em relação à referência do Snyk: a média harmônica entre precisão e recall quando as descobertas do Snyk Code são tratadas como conjunto de referência. É uma métrica útil de concordância, mas não é o ponto principal.

Como este benchmark não usa um conjunto de referência independente, exaustivamente validado, o F1 em relação à referência do Snyk não deve ser interpretado como precisão real na detecção de vulnerabilidades. Um modelo com menor concordância com o conjunto de referência do Snyk Code ainda poderia ter uma pontuação melhor diante de uma referência independente, caso algumas de suas descobertas não correspondentes sejam válidas ou ele evite problemas exagerados pelo conjunto de referência. Neste relatório, o F1 em relação à referência do Snyk responde a uma pergunta mais específica: até que ponto e com que repetibilidade as descobertas dos modelos se alinham às descobertas de referência do Snyk Code?

Resultado 1: a repetibilidade dos LLMs variou conforme a configuração do modelo

No nível da configuração, a repetibilidade aparece na relação entre pontuação e variação. O melhor resultado fica no canto superior esquerdo: alta concordância com o conjunto de referência e baixa variação entre execuções. O SAST do Snyk Code ocupa esse canto, com 100,0% de F1 em relação à referência do Snyk e desvio padrão de 0,0 ponto percentual, pois reproduziu o conjunto de referência de forma determinística. As configurações dos modelos Claude se distribuem para baixo e para a direita, e Claude Sonnet 4.6 High apresenta a maior variação geral, de 3,5 pontos percentuais.

Figura 1: F1 em relação à referência do Snyk comparado ao desvio padrão geral dessa métrica. Os melhores pontos ficam no canto superior esquerdo: maior concordância e menor variação entre execuções. O SAST do Snyk Code aparece destacado em roxo, com variação zero.

O gráfico de dispersão deixa duas coisas claras ao mesmo tempo. Primeiro, o papel do Snyk Code neste benchmark é reproduzir uma referência de forma determinística, não fazer uma análise probabilística. Segundo, as configurações dos modelos não se alinham por custo ou recência: Claude Opus 4.6 Medium e High ficam próximos, com baixa variação e os maiores valores de F1 entre os modelos, enquanto Claude Opus 4.7 Max e Claude Sonnet 4.6 High ficam mais à direita, indicando maior variação entre execuções.

Em todas as configurações de modelo, 80 das 161 assinaturas únicas de descobertas não correspondentes apareceram em apenas uma de cinco execuções repetidas. Esse total explica parte da variação, mas também analisamos uma perspectiva potencialmente mais útil: os resultados separados por modelo:

Figura 2: Proporção das assinaturas únicas de descobertas não correspondentes de cada configuração de modelo que apareceram em apenas uma de cinco execuções repetidas. Assinatura = tarefa + tipo de vulnerabilidade + arquivo + linha, agrupados por configuração do modelo.

A tabela abaixo apresenta os valores exatos do gráfico anterior e os dois indicadores de estabilidade mais importantes.

A instabilidade não se distribui igualmente entre os modelos. Claude Sonnet 4.6 Medium gerou o maior conjunto de descobertas não correspondentes, com 60 assinaturas únicas; 37 delas apareceram em apenas uma de cinco execuções. Claude Sonnet 4.6 High e Claude Opus 4.7 Max apresentaram um padrão semelhante: muitos relatórios adicionais apareceram uma vez e não se repetiram. Em contraste, os 0,0% de Claude Opus 4.6 Medium no gráfico indicam alta estabilidade e poucas descobertas isoladas: todos os relatórios adicionais apareceram em duas ou mais execuções, e nenhum apareceu em apenas uma das cinco repetições.

As configurações do Opus 4.6 tiveram um comportamento diferente. Elas geraram muito menos descobertas não correspondentes, e seus relatórios adicionais foram mais estáveis. Isso não significa que todos esses relatórios estejam corretos, mas muda a interpretação operacional: menos descobertas inesperadas, menos alegações isoladas e menos retrabalho na triagem.

O gráfico abaixo destaca como a maioria das configurações que não são Opus 4.6 teve dificuldade para manter a estabilidade das descobertas adicionais (não correspondentes) em execuções repetidas. Tanto Claude Sonnet 4.6 Medium quanto High tiveram baixa repetibilidade, com apenas 8,3% e 9,3% das descobertas não correspondentes persistindo nas cinco execuções. Claude Opus 4.7 Max também teve um desempenho fraco, com apenas 16,7% de estabilidade. Em contraste, Opus 4.6 Medium e High apresentaram muito mais estabilidade nas descobertas não correspondentes (60,0% e 50,0%, respectivamente), reforçando que as descobertas não correspondentes das configurações Sonnet e Claude Opus 4.7 Max, mais recentes, são menos previsíveis e mais ruidosas.

Figura 3: Proporção de assinaturas únicas de descobertas não correspondentes que apareceram nas cinco execuções repetidas de cada configuração de modelo.

O lado das descobertas correspondentes conta uma história diferente. Quando um modelo encontrava uma descoberta de referência do Snyk Code, geralmente voltava a encontrá-la. Claude Opus 4.6 Medium correspondeu a 25 descobertas únicas de referência e repetiu as 25 nas cinco execuções. Claude Opus 4.6 High repetiu 25 das 26. Até as configurações Sonnet mais ruidosas repetiram 29 das 36 descobertas correspondentes à referência.

Figura 4: Proporção de descobertas únicas de referência do Snyk Code encontradas nas cinco execuções repetidas de cada configuração de modelo.

A Figura 4 mostra o lado das descobertas correspondentes na análise de repetibilidade. Em todas as configurações de modelo, 134 das 158 descobertas únicas correspondentes à referência apareceram nas cinco repetições (84,8%). Isso significa que, quando um modelo identificava uma descoberta conhecida da referência do Snyk Code, geralmente fazia isso de forma confiável. O contraste com a Figura 5 é o principal resultado: os verdadeiros positivos costumavam ser estáveis, enquanto os relatórios adicionais fora da referência eram bem mais ruidosos.

Figura 5: Distribuição das descobertas únicas dos modelos que não correspondem à referência, de acordo com a frequência com que a mesma assinatura apareceu nas cinco repetições da mesma tarefa e configuração de modelo. Assinatura = tarefa + configuração + tipo de vulnerabilidade + arquivo + linha.

Quase metade das descobertas únicas dos modelos que não correspondiam à referência apareceu em apenas uma de cinco repetições idênticas. Isso representa um problema prático de confiabilidade: a fila de análise de uma pessoa desenvolvedora pode mudar substancialmente dependendo de qual execução foi realizada.

A distribuição exata por trás dessa visualização é:

Resultado 2: agentes com LLM e SAST identificaram diferentes lacunas de segurança

A interpretação mais útil não é “LLM contra SAST”, mas “LLM e SAST juntos identificam diferentes modos de falha”.

A maneira mais clara de perceber isso é observar as classes de vulnerabilidade. O mapa de calor abaixo mostra o recall médio em relação ao conjunto de referência do Snyk Code por tipo de vulnerabilidade e configuração. O Snyk Code aparece com 100% porque define e reproduz o conjunto de referência. As linhas dos modelos mostram onde a análise agentiva concorda com essa referência e onde fica aquém.

Figura 6: Recall médio em relação ao conjunto de referência do Snyk Code por tipo de vulnerabilidade e configuração. O Snyk Code é apresentado como reprodução determinística da referência; as linhas dos modelos mostram em quais classes a análise agentiva concorda ou fica aquém.

As configurações dos modelos tiveram melhor desempenho em padrões de exploração conhecidos e com sinais claros: injeção de comandos, injeção de código, credenciais codificadas diretamente no código, injeção de SQL, SSRF, redirecionamento aberto, poluição de protótipo e ReDoS foram frequentemente detectados com precisão. O desempenho foi inferior na detecção de problemas de limite de recursos, sanitização inadequada, validação de tipos, transporte inseguro, exposição de informações em frameworks e fluxos recorrentes de path traversal.

Esse padrão fica evidente em js-project-tigerteam, onde todas as configurações de modelo detectaram de forma consistente a senha do banco de dados codificada diretamente no código, XSS refletido, path traversal e injeção de comandos em todas as 25 repetições do modelo.

1app.get("/greet", (req, res) => {
2  const name = req.query.name;
3  res.send(`<html><body><h1>Hello, ${name}!</h1></body></html>`);
4});
5
6app.get("/file", (req, res) => {
7  const filename = req.query.filename;
8  const basePath = "/var/app/public/";
9  fs.readFile(basePath + filename, "utf8", (err, data) => {
10    if (err) return res.status(404).send("Not found");
11    res.send(data);
12  });
13});
14
15app.get("/ping", (req, res) => {
16  const host = req.query.host;
17  exec("ping -c 1 " + host, (err, stdout, stderr) => {
18    if (err) return res.status(500).send("Error");
19    res.send(`<pre>${stdout}</pre>`);
20  });
21});

Mas esse mesmo caso de teste incluía uma função auxiliar simulada com aparência de SQL:

1function dbQuery(sql) {
2  console.log("Query:", sql);
3  return [];
4}
5
6app.get("/users", (req, res) => {
7  const username = req.query.username;
8  const sql = "SELECT * FROM users WHERE username = '" + username + "'";
9  const results = dbQuery(sql);
10  res.json(results);
11});

Os modelos relataram injeção de SQL em 25 de 25 execuções do modelo em js-project-tigerteam. Nesse caso de teste, o Snyk Code acertou ao não reportar o problema: dbQuery() registra a string e retorna um array vazio. Não há nenhum ponto de execução de SQL. Esse é o tipo de situação em que um LLM pode confundir código com aparência vulnerável com uma vulnerabilidade explorável.

js-project-nightowl mostrou a lição oposta. Todas as 25 execuções do modelo reportaram injeção de SQL fora do conjunto de referência do Snyk Code e, desta vez, o sinal do modelo provavelmente é valioso:

1deleteTodo: (id) => db.prepare("DELETE FROM todos WHERE id = " + id).all(),

Essa descoberta foi contabilizada como não correspondente porque não fazia parte do conjunto de referência do Snyk Code. Ela não deve ser descartada como uma alucinação. Provavelmente é uma lacuna real do produto que precisa ser investigada. O benchmark fica mais robusto, não menos, por ter revelado esse caso, e estamos incorporando esses aprendizados internamente para aprimorar os recursos de detecção da Snyk.

Figura 7: Média de relatórios não correspondentes por execução do modelo, por tipo de vulnerabilidade e configuração do modelo. Eles incluem falsos positivos dos modelos, comentários relacionados à revisão de segurança e possíveis lacunas do produto fora do conjunto de referência do Snyk Code.

Este segundo mapa de calor mostra o outro lado da complementaridade: os relatórios adicionais dos modelos não formam uma categoria homogênea. Alguns provavelmente são falsos positivos, como a função auxiliar simulada com aparência de SQL, mas não executável, em js-project-tigerteam. Outros são comentários relacionados à revisão de segurança, mas que estão fora do escopo do conjunto de referência. E alguns, como o relatório de injeção de SQL em js-project-nightowl, provavelmente são descobertas válidas que devem contribuir para ampliar a cobertura do Snyk Code.

A complementaridade também funciona na direção oposta. js-project-nightowl é o caso de teste mais parecido com um aplicativo no JS 1.0: server.js tem 198 linhas, e db.js e public/app.js acrescentam mais 183 linhas de JavaScript. O projeto inclui roteamento, uploads, exclusão de anexos, downloads e estado do banco de dados. Claude Opus 4.6 High teve resultados perfeitamente estáveis nesse caso de teste, mas com apenas 40,0% de F1 em relação à referência do Snyk. Em cinco repetições, deixou passar todas as descobertas de referência de path traversal e duas das três oportunidades de detecção de problemas de limite de recursos.

Figura 8: Pontuação média do benchmark para o caso de teste maior, com vários arquivos. As barras de erro mostram o desvio padrão entre execuções repetidas.

O padrão das falhas apareceu em fluxos recorrentes de anexos:

1if (req.file) {
2  if (existing.attachment_stored_name) {
3    fs.unlink(path.join(UPLOADS_DIR, existing.attachment_stored_name), () => {});
4  }
5  updates.push("attachment_original_name = ?", "attachment_stored_name = ?");
6  values.push(req.file.originalname, req.file.filename);
7} else if (req.body.removeAttachment === true || req.body.removeAttachment === "true") {
8  if (existing.attachment_stored_name) {
9    fs.unlink(path.join(UPLOADS_DIR, existing.attachment_stored_name), () => {});
10  }
11}

O modelo detectou alguns problemas representativos, mas não conseguiu enumerar pontos vulneráveis recorrentes. É exatamente aí que a análise determinística de fluxo de dados é valiosa. A cobertura do SAST e a revisão por modelos não são duplicatas: são instrumentos diferentes, com pontos cegos diferentes.

Resultado 3: execuções de LLM mais caras não significaram melhor cobertura

Claude Opus 4.7 Max foi a configuração de modelo mais cara deste teste, mas não teve o melhor desempenho. Em média, consumiu 95.969 tokens e custou US$ 0,3559 por sessão do modelo. Claude Opus 4.6 Medium consumiu, em média, 51.574 tokens e custou US$ 0,0628 por sessão do modelo. Portanto, Opus 4.7 Max custa 5,67 vezes mais e usa 1,86 vez mais tokens, mas teve uma pontuação menor: 68,8% de F1 em relação à referência do Snyk, contra 75,4% do Opus 4.6 Medium.

Figura 9: Relação entre custo e qualidade apenas dos modelos. Os melhores resultados ficam no canto superior esquerdo: maior F1 em relação à referência do Snyk e menor custo estimado por sessão do modelo.

Os valores absolutos em dólares são baixos porque os casos de teste são pequenos. A questão da escala, não. Verificações de segurança reais são executadas durante sessões de agentes de programação, commits, pull requests e tarefas de CI em repositórios muito maiores do que esses trechos de código. Uma inferência mais cara não garante uma cobertura de segurança melhor.

Pontuações de concordância com o conjunto de referência do Snyk Code

A pontuação F1 em relação à referência do Snyk continua sendo útil, desde que seja descrita com precisão: ela mede a concordância com o conjunto de referência do Snyk Code. Nessa métrica, o SAST do Snyk Code reproduziu seu conjunto de referência com 100,0% de F1 em relação à referência do Snyk e desvio padrão de 0,0 ponto percentual. A configuração de modelo com melhor desempenho foi Claude Opus 4.6 Medium, com 75,4% de F1 em relação à referência do Snyk, 68,0% de recall e 91,5% de precisão.

Esta tabela não deve ser interpretada como “a Snyk provou que o Snyk tem 100% de precisão”. A leitura correta é: o Snyk Code gerou um conjunto de referência determinístico; os modelos concordaram parcialmente com ele; e as diferenças revelam compensações entre repetibilidade, custo e cobertura que vale a pena medir.

O que este benchmark significa para a revisão de segurança com LLMs

O conjunto de referência vem do Snyk Code. Isso é transparente e reproduzível, mas se torna circular quando tratado como um conjunto universal de verdades. Este relatório não faz essa afirmação. O benchmark mede a concordância dos modelos com as descobertas do Snyk Code e usa as divergências para estudar repetibilidade e complementaridade.

O método de pontuação é generoso. Ele faz a correspondência pelo tipo de vulnerabilidade, não pelo arquivo, linha, gravidade ou identidade exatos entre origem e destino. Um método mais rigoroso provavelmente reduziria as pontuações de concordância dos modelos e revelaria mais erros relacionados a fluxos duplicados.

Os casos de teste são aplicativos pequenos em JavaScript e Express. Eles são úteis para medições controladas, mas não abrangem monorepos grandes, aplicativos TypeScript com uso intenso de frameworks, arquiteturas de vários serviços ou vulnerabilidades de lógica de negócios. js-project-nightowl já mostra que uma estrutura mais parecida com a de um aplicativo muda o comportamento dos modelos.

A análise de recorrência usa assinaturas normalizadas das descobertas. Nos gráficos de descobertas não correspondentes por modelo, a assinatura é tarefa + tipo de vulnerabilidade + arquivo + linha, agrupados separadamente para cada configuração do modelo. Diferentes escolhas de normalização alteram as porcentagens exatas; por isso, a assinatura está incluída nas instruções para os gráficos e nas notas de reprodutibilidade.

Próximos passos: casos de teste mais abrangentes e fluxos de trabalho combinados de LLM + SAST

A próxima versão do Snyk VulnBench deve ir além de pequenos trechos independentes. Planejamos incluir estruturas de aplicativos mais completas, vulnerabilidades identificadas por LLMs, lógica de negócios e classes BOLA, além de uma fonte independente de verdade de referência, como dados de referência no estilo do BaxBench.

Também devemos separar as trilhas do benchmark. Uma delas pode continuar medindo a concordância com o Snyk Code para que possamos comparar o comportamento dos modelos com uma referência determinística de SAST. Outra deve usar uma verdade de referência independente e passível de revisão externa, para que os principais resultados não dependam das próprias descobertas da Snyk.

Por fim, os próximos relatórios devem avaliar fluxos de trabalho combinados: revisão apenas com modelos, análise apenas com SAST e revisão por LLM complementada pelo contexto do SAST. Os dados do JS 1.0 já apontam nessa direção. Modelos e SAST não falham da mesma maneira. É por isso que devemos combiná-los.