VulnBump: agentes de IA conseguem corrigir dependências vulneráveis sem quebrar o build?

Agentes de IA conseguem corrigir dependências vulneráveis sem quebrar o build? Raramente, o mistério está na correção em si. Ao longo de seis meses em 2026, o Snyk Open Source registrou 459 milhões de descobertas de vulnerabilidades em cerca de 300 mil organizações. 94% dessas vulnerabilidades tinham uma versão corrigida conhecida, mas apenas cerca de 10% haviam sido resolvidas.

Isso acontece porque a parte difícil é atualizar com segurança: a maioria dos pacotes vulneráveis é importada de forma transitiva, cerca de um quarto das correções exige uma atualização para uma versão principal e até mesmo versões menores e de patch, que deveriam ser compatíveis com versões anteriores, frequentemente incluem mudanças incompatíveis.

VulnBump, uma nova pesquisa publicada pela Snyk, põe agentes de IA à prova em 307 atualizações reais de dependências vulneráveis. Uma atualização só conta como APROVADA se eliminar as vulnerabilidades e o projeto continuar instalando, compilando e passando nos testes.

O que há de novo: até onde sabemos, VulnBump é o primeiro benchmark para agentes de IA criado em torno de atualizações motivadas por segurança: cada tarefa começa com vulnerabilidades reais encontradas pela Snyk em um projeto real, entre seis gerenciadores de pacotes. Benchmarks anteriores de atualização verificam apenas se algo quebrou, não se a vulnerabilidade foi eliminada.

Então, agentes de IA conseguem corrigir dependências vulneráveis sem quebrar o build? Na maioria dos casos, sim, mas o modelo, por si só, não determina o resultado. Com o mesmo modelo, Claude Sonnet 5.5, o Evo Remediation Agent da Snyk foi aprovado em 90,2% das atualizações. O Claude Code, da Anthropic, foi aprovado em 77,5% quando recebeu a atualização recomendada e a verificação da Snyk (Claude Code + verificação da Snyk) e em 59,6% sem dados da Snyk (Claude Code sem auxílio). A diferença é de mais de 30 pontos percentuais. Como referência, a atualização pelo gerenciador de pacotes — uma linha de base sem IA que apenas aplica a versão recomendada pela Snyk — já foi aprovada em 46,9% dos casos.

Principais resultados do VulnBump

Manter o build funcionando não foi a parte difícil: os três agentes conseguiram isso em cerca de 93% dos casos. O desafio foi eliminar a vulnerabilidade. Em 70 das 124 falhas, o Claude Code, sem auxílio, afirmou ter corrigido vulnerabilidades que ainda foram detectadas em uma nova verificação.

Nossas conclusões são semelhantes às do VulnBench, nosso benchmark de junho sobre análise de segurança por IA, que mostrou que o Claude e o Snyk Code deixam passar vulnerabilidades diferentes e concluiu que os dois funcionam melhor em conjunto. O VulnBump testa outra tarefa — atualizar dependências open source vulneráveis — e aponta na mesma direção: com a versão recomendada e a verificação da Snyk, a taxa de aprovação do Claude Code subiu 17,9 pontos. O Evo Remediation Agent mostra até onde um agente desenvolvido para essa finalidade pode chegar: 12,7 pontos acima do Claude Code com a mesma verificação da Snyk. O VulnBump também dá continuidade a os resultados de correção que compartilhamos em maio, agora com um modelo mais recente e seis gerenciadores de pacotes.

Como criamos o VulnBump

Começamos com projetos reais que refletem o ambiente de produção. Reunimos 767 projetos candidatos do GitHub, incluindo projetos open source populares e repositórios que fixam versões sabidamente vulneráveis de pacotes. Antes de qualquer mudança, cada projeto precisava instalar e compilar, além de passar em mais de 85% dos testes, e a Snyk precisava encontrar pelo menos uma vulnerabilidade. Dos 99 projetos qualificados, selecionamos 43 que correspondem aos dados de produção da Snyk em ecossistema, gravidade das vulnerabilidades, dependências diretas versus transitivas e tamanho da atualização de versão.

Comparação do conjunto de dados do VulnBump com os dados de produção do Snyk Open Source

Transformamos cada atualização recomendada em uma tarefa. Cada tarefa pede ao agente que aplique uma atualização recomendada pela Snyk: um pacote atualizado para uma versão que corrige suas vulnerabilidades. Cada tarefa começa com uma cópia nova do projeto e é avaliada de forma independente. Os 43 repositórios geram 307 tarefas, que abrangem 2.066 vulnerabilidades corrigíveis em Maven, Gradle, npm, Yarn, pip e Poetry — os seis gerenciadores de pacotes responsáveis por cerca de 92% das descobertas em produção.

Adicionamos um verificador que não confiava no agente. Quando o agente terminava, copiávamos as alterações para um contêiner limpo e as verificávamos do zero. Nesse ambiente, uma tentativa só era considerada APROVADA se passasse por todas as quatro etapas:

1. As dependências são instaladas com o comando que a CI executaria.

2. Uma nova verificação da Snyk confirma que as vulnerabilidades foram eliminadas.

3. O projeto compila.

4. Todos os testes que passavam antes continuam passando.

O pipeline do VulnBump

Os ambientes de execução que testamos. Os três agentes usaram Claude Sonnet 5.5, com um limite de 110 interações por atualização, no mesmo contêiner para cada linguagem:

• O Evo Remediation Agent é o mecanismo de correção agentiva da Snyk. Ele usa a inteligência da Snyk e pode executar suas próprias verificações, compilações e testes, além de corrigir erros antes de concluir. Nós o executamos no modo de aprovação automática, para que aplicasse todas as correções, inclusive atualizações que a Snyk considera propensas a quebrar o build.

• Claude Code com verificação da Snyk é o agente de programação de uso geral da Anthropic, ao qual foi fornecida a recomendação de atualização da Snyk: qual pacote atualizar, a versão de destino e as vulnerabilidades que ela corrige. Ele também pode executar uma verificação do Snyk Open Source para conferir o próprio trabalho.

• Claude Code sem auxílio recebe a mesma tarefa, mas sem a versão de destino nem acesso à Snyk. Ele precisa descobrir por conta própria qual versão corrige as vulnerabilidades, por exemplo, pesquisando bancos de dados de vulnerabilidades na web.

• A atualização pelo gerenciador de pacotes é a linha de base sem agente: aplica a versão recomendada pela Snyk usando o gerenciador de pacotes do próprio projeto e não altera mais nada.

Como escolhemos os repositórios, os prompts exatos e as ferramentas disponíveis para cada agente, além dos controles contra vazamento de dados, estão descritos no artigo de pesquisa: VulnBump: um benchmark para corrigir dependências vulneráveis em projetos reais sem deixar o build nem os testes falharem, junto com as limitações: testamos um modelo, executamos cada atualização uma única vez e usamos o Snyk Open Source como avaliador. Isso só pode prejudicar o Claude Code sem auxílio, já que os outros dois agentes trabalham com as mesmas descobertas da Snyk. Também não penalizamos novas vulnerabilidades introduzidas por uma atualização.

Resultado 1: o mesmo modelo, três resultados diferentes

O Evo Remediation Agent passou por todas as etapas em 90,2% das atualizações (e corrigiu 95,9% das 2.066 ocorrências de vulnerabilidade). Isso representa 12,7 pontos a mais que o Claude Code + verificação da Snyk — aproximadamente uma correção bem-sucedida a mais a cada oito atualizações — e 30,6 pontos a mais que o Claude Code sem auxílio.

E a classificação não depende apenas de alguns repositórios grandes: na média por repositório, as taxas de aprovação foram de 93,1% para o Evo Remediation Agent, 80,1% para o Claude Code + verificação da Snyk, 68,0% para o Claude Code sem auxílio e 51,3% para a atualização pelo gerenciador de pacotes.

Resultado 2: os agentes precisam saber qual versão é realmente segura

Com o mesmo modelo, fornecer ao Claude Code a verificação e a atualização recomendada pela Snyk elevou sua taxa de aprovação em 17,9 pontos, de 59,6% para 77,5%.

A diferença mais clara está na versão escolhida. Sem auxílio, o Claude Code escolheu uma versão que a Snyk ainda sinaliza em 64 ocasiões. Com a verificação da Snyk, esse número caiu para 13. Os bancos de dados de vulnerabilidades nem sempre concordam sobre qual versão corrige uma vulnerabilidade; por isso, uma versão que parece segura em uma fonte ainda pode ser sinalizada por outra. 

A orientação da Snyk é especialmente importante para vulnerabilidades transitivas, em pacotes que o projeto não declara diretamente. Considerando apenas as atualizações aprovadas em todas as etapas, ela mais que dobrou a proporção de vulnerabilidades transitivas corrigidas pelo Claude Code, de 28% para 59%.

Resultado 3: a recomendação da Snyk, sozinha, resolve cerca de metade dos casos; depois, os agentes se diferenciam no restante

A atualização pelo gerenciador de pacotes divide as 307 atualizações em duas partes: nas 144 aprovadas, basta usar a versão recomendada pela Snyk, e um agente só pode manter ou comprometer uma correção fácil. As outras 163 exigem mais do que uma atualização de versão, como adaptar o código a mudanças incompatíveis ou resolver conflitos entre dependências.

Agentes nas 144 atualizações resolvidas pela recomendação da Snyk e nas outras 163

Com a orientação da Snyk, os agentes raramente desfazem o que a atualização resolve. Já o Claude Code sem auxílio regrediu em 20 das 144 atualizações, escolhendo em 15 delas uma versão que a Snyk ainda sinaliza. A diferença real fica evidente na metade mais difícil: entre as outras 163 atualizações, o Evo Remediation Agent foi aprovado em 82,2%, o Claude Code + verificação da Snyk em 61,3% e o Claude Code sozinho em 36,2%.

Resultado 4: um build aprovado pode ocultar uma vulnerabilidade não corrigida

A maneira mais fácil de manter o build funcionando é deixar a vulnerabilidade como está, e foi principalmente assim que vimos o Claude Code falhar. A nova verificação foi a primeira etapa reprovada em 107 das 124 falhas do Claude Code sem auxílio e em 48 das 69 falhas do Claude Code + verificação da Snyk, contra 9 das 30 falhas do Evo Remediation Agent.

Primeira etapa de verificação reprovada em cada tentativa malsucedida

As falhas do Evo Remediation Agent ficam visíveis (e isso não é ruim). 21 das suas 30 falhas interromperam o build ou os testes, principalmente em atualizações para versões principais que outros agentes muitas vezes evitaram. Uma falha evidente é muito mais segura do que uma falha silenciosa: quando uma atualização dá errado, o build e os testes do próprio projeto mostram o problema, que um desenvolvedor pode ver e, por fim, resolver.

Resultado 5: saber a versão de destino não basta

A verificação da Snyk ajuda bastante o Claude Code, mas acertar a atualização exige mais do que isso: com descobertas e versões de destino idênticas, o Evo Remediation Agent foi aprovado em mais 39 atualizações do que o Claude Code com verificação da Snyk, 23 delas envolvendo saltos para versões principais.

O Evo Remediation Agent combina a inteligência da Snyk com um ciclo em que compila, testa e corrige o projeto antes de concluir. Embora nossa configuração não permita isolar qual componente faz a diferença, ela mostra o quanto o sistema em torno de um modelo pode afetar o resultado, em linha com o DepBench, em que mudar apenas o ambiente de execução alterou os resultados em até 16,3 pontos.

Resultado 6: saltos para versões principais e dependências transitivas continuam sendo as tarefas mais difíceis

Todos os agentes ainda têm dificuldade com migrações de frameworks para versões principais: 23 atualizações — principalmente migrações de Spring, Spring Boot e Dropwizard — foram demais para os três agentes. 

Nas atualizações para versões principais, em comparação com as demais, as taxas de aprovação caíram de 96% para 81% no Evo Remediation Agent, de 88% para 61% no Claude Code + verificação da Snyk e de 70% para 42% no Claude Code sem auxílio. As atualizações para versões principais também são as que exigem mudanças no código: em cerca de metade das aprovações do Evo Remediation Agent nessas atualizações, o código-fonte da aplicação foi alterado, contra 5% nas aprovações para atualizações menores.

Atualizações aprovadas em todas as etapas, por tamanho do salto de versão

As vulnerabilidades transitivas, nas quais o pacote vulnerável não está declarado no manifesto, representam 70% das ocorrências corrigíveis e são mais difíceis para todos os ambientes testados. Considerando apenas as correções de tentativas aprovadas em todas as etapas, o Evo Remediation Agent corrigiu 73% das ocorrências transitivas, o Claude Code + verificação da Snyk, 59%, e o Claude Code sem auxílio, 28%. Para as ocorrências diretas, os resultados foram, respectivamente, 91%, 71% e 62%.

Taxa de aprovação por tipo de dependência (direta versus transitiva)

Como o VulnBump se relaciona com o VulnBench?

O VulnBench avalia como agentes de programação com IA encontram vulnerabilidades no código que você escreve: com que consistência detectam os mesmos problemas em execuções repetidas e o quanto suas descobertas correspondem a uma linha de base determinística de SAST. O VulnBump avalia se conseguem corrigir vulnerabilidades no código de que você depende: atualizando dependências open source vulneráveis sem quebrar o build nem os testes.

Quando você analisa os dois em conjunto, eles apontam na mesma direção: os modelos trazem uma capacidade de raciocínio que as ferramentas determinísticas simplesmente não têm. Sozinhos, eles relatam descobertas diferentes entre execuções e muitas vezes não chegam a corrigir o problema. Em toda a plataforma, resumimos essa lição compartilhada de forma mais simples: quem gera não pode ser quem valida.

O que isso significa para as equipes que delegam tarefas de segurança a agentes?

• Avalie uma correção com base nas evidências que o agente não produziu: o relato do agente sobre a própria correção é uma alegação, enquanto uma nova verificação, um build e uma execução de testes são evidências. Se um agente está corrigindo seu backlog, exija que ele passe pelas mesmas verificações.

• Avalie a vulnerabilidade e o build em conjunto: avaliar apenas um deles oculta uma falha. Verificar somente se algo quebrou não detecta correções que nunca foram feitas, enquanto verificar apenas a vulnerabilidade não detecta uma correção que quebrou o projeto.

• Forneça os dados de segurança ao agente: a análise e a atualização recomendada pela Snyk valeram 17,9 pontos para um agente de uso geral, usando o mesmo modelo.

O Evo Remediation Agent é o mecanismo de correção agentiva da Snyk, disponível pela Snyk CLI e como serviço em nuvem. Ele é um dos agentes do Evo AppSec Agentivo, lançado hoje.

Execute seu agente no VulnBump

A estrutura de testes do VulnBump e os 43 casos de avaliação são de código aberto em github.com/snyk-labs/snyk-vulnbump.

A metodologia completa, a análise de falhas e as limitações estão no artigo de pesquisa. Se você estiver desenvolvendo seu próprio agente de correção, execute-o no VulnBump e conte para nós o que descobrir.

VulnBump foi desenvolvido por Gabija Pasiunaite, Ryan McMorrow, Brian Clark, Liran Tal e Luke Tu.