Agentes de Remediação, Desmistificados: Por Que Corrigir é Melhor do que Encontrar

Seis novos problemas de segurança para cada um problema corrigido. Essa é a proporção identificada pela pesquisa da Snyk e é por isso que a AI Security Engineers Community dedicou uma hora de transmissão ao vivo para corrigir, em vez de encontrar problemas.

Play Video: Remediation Agents Demystified: Your AI Teammate for Fixing Security Bugs

Remediation Agents Demystified combinou uma conversa descontraída com uma demonstração ao vivo. Gérald Crescione, líder da comunidade global de AI Security Engineers, apresentou o evento, com Ryan McMorrow, que lidera os produtos de correção na Snyk, e Brendan Hann, gerente sênior de marketing de produto da experiência do desenvolvedor e da solução Agentic AppSec da Snyk.

Remediation Agent, agora em prévia pública, é a resposta da Snyk ao problema do volume de problemas que estamos observando. Enquanto a equipe continua desenvolvendo e iterando publicamente, a Snyk está oferecendo o Remediation Agent a todos os clientes atuais da Snyk sem custo adicional, em troca de feedback acionável da comunidade. Esse feedback pode ser compartilhado no subreddit da comunidade.

Por que a taxa de correção permaneceu estável

Os agentes de programação que os desenvolvedores agora usam em toda parte otimizam para código funcional, não para código funcional seguro. Assim, o volume de problemas está aumentando enquanto a taxa de correção permanece estável. As ferramentas de AppSec responderam com orientações determinísticas: você está na versão 1.0, a vulnerabilidade foi corrigida na 1.1, então faça a atualização. Até aí, tudo bem, exceto que alguém ainda precisa provar que a atualização não quebrou nada, e nenhuma ferramenta fazia isso em nome do desenvolvedor. Quando o salto abrangia três ou quatro versões principais, a maioria das equipes nunca ganhava confiança suficiente para fazer o merge.

Hann colocou esse gargalo dentro de uma mudança mais ampla. A IA criou três pressões distintas, mas relacionadas: os ataques agora são automatizados com IA; os agentes escrevem software mais rápido do que nunca e introduzem vulnerabilidades no mesmo ritmo; e a IA está chegando à produção, muitas vezes sem governança. A correção sempre foi um gargalo, argumentou ele, mas agora isso importa mais porque as ferramentas dos invasores também mudaram de forma. Modelos de classe frontier escapam de sandboxes e encadeiam descobertas de baixa gravidade antes ignoráveis em novos zero-days. O backlog de riscos aceitos tornou-se uma superfície de ataque por si só.

A Agentic AppSec aborda essa combinação: controles preventivos, detecção de nível frontier e correção autônoma — ou, nas palavras de Hann, equipar as equipes com uma equipe de agentes capaz de executar o programa de AppSec por elas.

Por que simplesmente usar um LLM no backlog não funciona

Os pesquisadores da Snyk fizeram primeiro o óbvio: apontaram um LLM para o backlog de segurança para ver o que acontecia.

O modelo demonstrou um entusiasmo extremo e acertou apenas ocasionalmente. Os desenvolvedores ainda precisavam revisar cada alteração e rejeitar a maioria delas, o que consumia praticamente o mesmo tempo que corrigir os problemas manualmente. Um modelo maior teria produzido mais do mesmo.

A virada aconteceu quando a equipe fez uma pergunta diferente: e se o LLM recebesse tudo o que a Snyk sabe? Dez anos de práticas recomendadas de segurança de aplicações, conhecimento de atualizações específico de cada ecossistema e a experiência conquistada com dificuldade sobre quais correções são incorporadas ao código e quais não são.

Isso se tornou o Remediation Agent, descrito por McMorrow como um harness ou camada de orquestração entre o modelo escolhido pelo desenvolvedor e uma camada de inteligência acessível que abrange todos os problemas e CVEs monitorados pela Snyk. Sob demanda, o agente pode consultar:

• Avaliações de possibilidade de quebra para atualizações de código aberto, atribuindo uma pontuação à probabilidade de uma atualização quebrar seu build, com base em um banco de dados de todas as versões de pacotes e de todas as alterações incompatíveis nelas

• Integridade dos pacotes e pontuações de alcançabilidade, incluindo se o código vulnerável pode ser explorado em produção

• Geração de correções SAST por meio do recurso Agent Fix da Snyk

• Playbooks de ecossistemas escritos pelos próprios engenheiros de segurança da Snyk, abrangendo como um profissional sênior faria a atualização de uma dependência transitiva ou eliminaria determinada classe de descobertas SAST

A analogia de McMorrow foi que o LLM está fazendo uma prova com consulta, e a Snyk fornece o livro. Em seguida, a Snyk corrige o trabalho do agente, executando novamente as verificações para confirmar que o problema realmente desapareceu e executando os testes unitários do projeto para garantir que as alterações não quebraram o build.

Os resultados internos compartilhados por ele foram uma melhoria de 94% nas correções SCA passíveis de merge e de 13% nas correções SAST passíveis de merge, com a maioria das correções SAST geradas internamente agora sendo incorporada ao código sem alterações, a um custo de tokens significativamente menor do que na abordagem ingênua.

Hann acrescentou os três padrões com os quais os parceiros de design da Snyk obtiveram mais sucesso:

1. Campanhas de redução do backlog, eliminando as descobertas de baixa gravidade e informativas que os invasores agora encadeiam

2. Implementações em toda a organização, oferecendo um agente de correção ao lado de cada desenvolvedor

3. Uso do agente de correção em ambientes de desenvolvimento agentivo (ADE) para impedir que novos problemas entrem na base de código

A demonstração: IDE e CLI

McMorrow executou o agente ao vivo no OWASP Juice Shop e mostrou os dois pontos de entrada.

1. O caminho pela IDE

O caminho pela IDE precisa de duas partes: uma habilidade /snyk-fix e o servidor MCP do Snyk Studio, ambos instaláveis com um único comando curl a partir do repositório de receitas da Snyk. Isso oferece o ciclo completo dentro do Cursor, Windsurf, Antigravity ou VS Code com um plugin do Claude, desde as verificações SAST e SCA até a consulta de inteligência, alterações no código, nova verificação, execução de testes, relatório e pull request. No palco, ele atualizou uma dependência multer vulnerável entre versões principais, confirmou que nenhuma alteração incompatível na API afetava o uso do armazenamento em disco do aplicativo e atualizou o arquivo de lock.

2. O caminho pela CLI

Na CLI, snyk fix --agentic --experimental --sca é mais participativa. Ela lista todos os pacotes que acredita poder atualizar, junto com a versão atual, a versão-alvo recomendada pela Snyk por eliminar a maior quantidade de problemas críticos e graves, além de uma pontuação de possibilidade de quebra. Os desenvolvedores podem:

• Corrigir tudo

• Corrigir apenas os itens com baixa possibilidade de quebra

• Selecionar descobertas específicas

• Conversar com o agente

McMorrow demonstrou a última opção perguntando por que um salto de Glob versão principal foi classificado como de alto risco, e o agente retornou o raciocínio: uma mudança para uma API baseada em promises, o estilo de callbacks descontinuado, separadores de caminho se tornando caracteres que só podem ser usados como escape e a classe Glob deixando de ser um emissor de eventos. Ele também listou as vulnerabilidades transitivas que a atualização resolveria. A versão mais recente então usa essa mesma inteligência de possibilidade de quebra para fazer as alterações de compensação no código, transformando uma atualização de alto risco em uma de baixo risco.

Quando perguntado de onde vinha a justificativa, McMorrow explicou que o raciocínio sobre possibilidade de quebra vem da análise de notas de versão e alterações incompatíveis em todo o ecossistema de código aberto. Os parceiros de design relataram poucos falsos positivos. Eles são principalmente uma preocupação do lado SAST, e o agente usa os mecanismos existentes do Snyk Code para filtrá-los.

Humano no circuito, depois humano supervisionando o circuito

Todos os caminhos da demonstração terminavam em um pull request. “Não vamos sair fazendo alterações malucas no código”, como Hann explicou, e o desenvolvedor mantém a aprovação final até que um agente conquiste confiança suficiente para que alguém possa fazer o merge do trabalho sem pensar duas vezes.

As próprias equipes da Snyk executam o agente pela CLI atualmente, e uma variante autônoma está em desenvolvimento ativo: a Snyk inicia um sandbox, instala o agente, importa o código da aplicação e retorna um PR pronto. O pipeline de CI da Snyk costumava parar diante de novas vulnerabilidades e devolver o problema ao desenvolvedor; agora ele gera as correções, e você incorpora o trabalho do agente junto com seu próprio commit. Os engenheiros, relatou McMorrow, adoram não precisar voltar ao código.

Hann apontou o “backlog zero” como uma meta realista, além do bloqueio de pacotes maliciosos e de slopsquatting no nível da máquina do desenvolvedor e da organização. McMorrow argumentou que o objetivo de longo prazo é controle, governança e confiança: passar de um humano no circuito para um humano supervisionando o circuito. A distinção está em quem decide: no circuito é programação em par com um agente, enquanto supervisionando o circuito é um agente que decide por conta própria e sabe quando chamar você. O acréscimo de Crescione: essa é a descrição emergente do cargo — AI Security Engineers orquestrando um grupo de agentes em seu nome.

Colocando a mão na massa

Para começar, é necessário ter uma conta da Snyk e a CLI ou um ADE compatível, além da sua própria chave de API do modelo, já que usar seu próprio LLM é o padrão na prévia aberta. Mantenedores de projetos de código aberto podem obter toda a plataforma gratuitamente por meio do Secure Developer Program, que inclui uma licença empresarial completa.

Encontrou uma correção que não deu certo? Conte para nós em r/AISecEng. Seu feedback ajudará a definir os próximos passos do Remediation Agent enquanto a Snyk continua desenvolvendo e iterando publicamente.