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 que a pesquisa da Snyk encontrou, e é por isso que a AI Security Engineers Community dedicou uma hora de transmissão ao vivo a corrigir, em vez de encontrar.

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 global da comunidade AI Security Engineers, apresentou o evento, com Ryan McMorrow, que lidera os produtos de correção da Snyk, e Brendan Hann, gerente sênior de marketing de produto para a experiência do desenvolvedor e a solução Agentic AppSec da Snyk.

Remediation Agent, agora em prévia pública, é a resposta da Snyk ao problema do volume de issues que estamos observando. Enquanto a equipe continua desenvolvendo e iterando publicamente, a Snyk oferece 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 são otimizados para código funcional, não para código funcional e seguro; por isso, o volume de issues aumenta enquanto a taxa de correção permanece estável. As ferramentas de AppSec responderam a isso com orientações determinísticas: você está na versão 1.0, a vulnerabilidade foi corrigida na 1.1, então faça o upgrade. Até aí, tudo bem, exceto que alguém ainda precisa provar que o upgrade 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 encontrava 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 atacantes também mudaram de forma. Modelos de classe frontier escapam de sandboxes e encadeiam descobertas de baixa severidade 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 abrange essa combinação: controles preventivos, detecção de nível frontier e correção autônoma — nas palavras de Hann, equipar as equipes com uma equipe de agentes que possa executar o programa de AppSec por elas.

Por que simplesmente jogar 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 aconteceria.

O modelo se mostrou extremamente entusiasmado e apenas ocasionalmente correto. Os desenvolvedores ainda precisavam revisar cada alteração e rejeitar a maioria delas, o que consumia praticamente o mesmo tempo que corrigir os issues 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 específico sobre upgrades de ecossistemas e experiência conquistada a duras penas sobre quais correções são integradas 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 chamável que abrange todos os issues e CVEs monitorados pela Snyk. Sob demanda, o agente pode obter:

• Avaliações de possibilidade de quebra para upgrades de código aberto, atribuindo uma pontuação à probabilidade de um upgrade quebrar seu build, com base em um banco de dados de todas as versões de pacotes e 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 o upgrade 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 a tarefa do agente, executando novamente as verificações para confirmar que o issue realmente desapareceu e executando os testes unitários do projeto para garantir que as alterações não quebraram o build.

Os resultados internos que ele compartilhou mostraram uma melhoria de 94% nas correções SCA integráveis e de 13% nas correções SAST integráveis, com a maioria das correções SAST geradas internamente agora sendo integrada 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 severidade e informativas que os atacantes agora encadeiam

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

3. Uso do agente de correção em ambientes de desenvolvimento agentic (ADE) para impedir que novos issues 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 peças: um /snyk-fix skill e o servidor MCP do Snyk Studio, ambos instaláveis com um único comando curl a partir do repositório de recipes 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 participativo. Ela lista todos os pacotes que acredita poder atualizar, juntamente com a versão atual, a versão-alvo recomendada pela Snyk por eliminar a maior quantidade de issues críticos e de alta severidade, 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 callback obsoleto, separadores de caminho se tornando caracteres somente de escape e a classe Glob deixando de ser um event emitter. Ele também listou as vulnerabilidades transitivas que o upgrade resolveria. A versão mais recente então usa essa mesma inteligência de possibilidade de quebra para fazer as alterações compensatórias no código, transformando um upgrade de alto risco em um de baixo risco.

Quando perguntado de onde vem a justificativa, McMorrow explicou que o raciocínio sobre a 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 estamos fazendo alterações absurdas no código”, como Hann colocou, e o desenvolvedor mantém a aprovação final até que um agente conquiste confiança suficiente para que alguém faça merge do trabalho sem pensar duas vezes.

As próprias equipes da Snyk já executam o agente pela CLI, e uma variante autônoma está em desenvolvimento ativo: a Snyk inicia um sandbox, instala o agente, incorpora 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ê integra o trabalho do agente junto com seu próprio commit. Os engenheiros, relatou McMorrow, adoram não precisar voltar ao código.

Hann apontou “backlog zero” como uma meta realista, além do bloqueio de pacotes maliciosos e 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 parceria 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, é preciso ter uma conta da Snyk e a CLI ou um ADE compatível, além da sua própria chave de API de modelo, já que usar seu próprio LLM é o padrão na prévia aberta. Mantenedores 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 orientar os próximos passos do Remediation Agent enquanto a Snyk continua desenvolvendo e iterando publicamente.