Remediation Agent sem mistério: por que corrigir é melhor do que encontrar

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

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

Remediation Agent sem mistério reuniu uma conversa informal e uma demonstração ao vivo. Gérald Crescione, líder global da comunidade AI Security Engineers, foi o anfitrião, ao lado de Ryan McMorrow, responsável pelos produtos de remediação na Snyk, e Brendan Hann, gerente sênior de marketing de produto para a experiência dos desenvolvedores e a solução Agentic AppSec da Snyk.

O Remediation Agent, agora em prévia pública, é a resposta da Snyk ao problema do volume de vulnerabilidades que estamos enfrentando. Enquanto continua desenvolvendo e aprimorando o produto em público, a Snyk oferece o Remediation Agent sem custo adicional a todos os clientes atuais, em troca de feedback prático da comunidade. Você pode compartilhar esse feedback no subreddit da comunidade.

Por que a taxa de correção não aumentava

Os agentes de programação que os desenvolvedores usam hoje por toda parte são otimizados para criar código funcional, não código funcional e seguro. Por isso, o volume de problemas cresce, mas a taxa de correção continua igual. As ferramentas de AppSec respondiam com orientações determinísticas: você está na versão 1.0, a vulnerabilidade foi corrigida na 1.1, então atualize. Até aí, tudo bem — mas alguém ainda precisava provar que a atualização não quebraria nada, e nenhuma ferramenta fazia isso em nome do desenvolvedor. Quando a atualização envolvia três ou quatro versões principais, a maioria das equipes não tinha confiança para fazer o merge.

Hann situou esse gargalo em meio a uma transformação 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 remediação sempre foi um gargalo, argumentou ele, mas agora é ainda mais importante porque as ferramentas dos atacantes também mudaram. Modelos de ponta escapam de sandboxes e encadeiam vulnerabilidades de baixa gravidade, antes ignoradas, para criar novos ataques zero-day. O acúmulo de riscos aceitos se tornou uma superfície de ataque por si só.

Agentic AppSec abrange essa combinação: controles preventivos, detecção no nível dos modelos de ponta e remediação autônoma. Nas palavras de Hann, trata-se de equipar as equipes com um time de agentes capaz de executar todo o programa de AppSec por elas.

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

Os pesquisadores da Snyk começaram pelo óbvio: direcionaram um LLM ao backlog de segurança para ver o que acontecia.

O modelo se mostrou extremamente entusiasmado e só acertava de vez em quando. Os desenvolvedores ainda precisavam revisar cada alteração e rejeitar a maioria delas, o que consumia quase tanto tempo quanto corrigir os problemas manualmente. Um modelo maior teria produzido mais do mesmo.

A virada aconteceu quando a equipe fez outra pergunta: e se o LLM tivesse acesso a tudo o que a Snyk sabe? Dez anos de boas práticas de segurança de aplicações, conhecimento sobre atualizações específicas de cada ecossistema e experiência conquistada a duras penas sobre quais correções são aceitas no merge — e quais não são.

Assim surgiu o Remediation Agent, descrito por McMorrow como uma camada de orquestração que fica entre o modelo escolhido pelo desenvolvedor e uma camada de inteligência consultável, que abrange todos os problemas e CVEs monitorados pela Snyk. Quando necessário, o agente pode consultar:

• Avaliações do risco de quebra em atualizações de pacotes open source, indicando a probabilidade de uma atualização quebrar o build, com base em um banco de dados que cobre todas as versões de pacotes e as alterações incompatíveis em cada uma

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

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

• Guias específicos para cada ecossistema, criados pelos próprios engenheiros de segurança da Snyk, que mostram como um profissional experiente atualizaria uma dependência transitiva ou resolveria determinada classe de problemas de SAST

McMorrow comparou a situação a uma prova com consulta: o LLM faz a prova, e a Snyk fornece o material de referência. Depois, a Snyk avalia o trabalho do agente, executando novos scans para confirmar que o problema realmente desapareceu e rodando os testes unitários do projeto para garantir que as alterações não quebraram o build.

Os resultados internos que ele compartilhou apontaram uma melhora de 94% nas correções de SCA prontas para merge e de 13% nas correções de SAST prontas para merge. Hoje, a maioria das correções de SAST geradas internamente é aceita no merge sem alterações, com um custo de tokens significativamente menor do que o da abordagem ingênua.

Hann também mencionou os três padrões que mais deram certo para os parceiros de design da Snyk:

1. Campanhas para reduzir o backlog, eliminando problemas de baixa gravidade e informativos que os atacantes agora encadeiam

2. Implantações em toda a organização, com um agente de remediação ao lado de cada desenvolvedor

3. Uso do agente de remediaçã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 apresentou as duas formas de usá-lo.

1. No IDE

O fluxo pelo IDE precisa de dois componentes: uma skill /snyk-fix e o servidor MCP do Snyk Studio. Você pode instalar ambos com um único comando curl do repositório de receitas da Snyk. Isso permite executar todo o fluxo no Cursor, Windsurf, Antigravity ou VS Code com um plugin do Claude: dos scans de SAST e SCA à consulta de inteligência, às alterações no código, ao novo scan, à execução dos testes, ao relatório e ao pull request. Na demonstração, o agente atualizou uma dependência vulnerável do multer entre versões principais, confirmou que nenhuma alteração incompatível na API afetava o uso de armazenamento em disco pelo app e atualizou o arquivo de lock.

2. Na CLI

Na CLI, snyk fix --agentic --experimental --sca permite participar mais do processo. O comando lista cada pacote que pode ser atualizado, junto com a versão atual, a versão de destino recomendada pela Snyk — que elimina o maior número de problemas críticos e altos — e uma pontuação de risco de quebra. Os desenvolvedores podem:

• Corrigir tudo

• Corrigir apenas os itens com baixo risco de quebra

• Selecionar problemas específicos

• Conversar com o agente

McMorrow demonstrou a última opção perguntando por que uma atualização de versão principal do Glob tinha sido classificada como de alto risco. O agente explicou: a mudança para uma API baseada em promises, o estilo de callback descontinuado, os separadores de caminho passando a ser interpretados apenas como caracteres de escape e a classe Glob deixando de ser um emissor de eventos. Também listou as vulnerabilidades transitivas que a atualização resolveria. Em seguida, a versão mais recente usou essa mesma inteligência sobre risco de quebra para fazer as alterações compensatórias no código e transformar uma atualização de alto risco em uma de baixo risco.

Ao ser questionado sobre a origem dessa justificativa, McMorrow explicou que a análise do risco de quebra se baseia nas notas de versão e nas alterações incompatíveis do ecossistema open source. Os parceiros de design relataram poucos falsos positivos. Eles são principalmente uma preocupação do lado de SAST, e o agente usa os mecanismos existentes do Snyk Code para filtrá-los.

Com a pessoa no processo — e depois supervisionando

Na demonstração, todos os fluxos terminavam em um pull request. “Não estamos fazendo alterações malucas no código”, explicou Hann. Até que o agente conquiste confiança suficiente para alguém aceitar o trabalho dele no merge sem pensar duas vezes, a aprovação final continua nas mãos do desenvolvedor.

Hoje, as próprias equipes da Snyk executam o agente pela CLI, e uma versão autônoma está em desenvolvimento ativo: a Snyk inicia um sandbox, instala o agente, carrega o código da aplicação e entrega um PR concluído. Antes, o pipeline de CI da Snyk parava ao encontrar novas vulnerabilidades e devolvia o problema ao desenvolvedor; agora, gera as correções, e você integra o trabalho do agente junto com seu próprio commit. Segundo McMorrow, os engenheiros adoram não precisar voltar para corrigir tudo.

Hann apontou “backlog zero” como uma meta realista, além do bloqueio de pacotes maliciosos e de slopsquatting nas máquinas dos desenvolvedores e em toda a organização. McMorrow argumentou que o objetivo de longo prazo é ter controle, governança e confiança: passar de uma pessoa participando do processo para uma pessoa supervisionando-o. A diferença está em quem decide: no primeiro caso, é uma programação em dupla com um agente; no segundo, o agente decide por conta própria e sabe quando chamar você. Crescione acrescentou que essa é a descrição emergente do cargo: AI Security Engineers coordenando uma equipe de agentes em seu nome.

Coloque a mão na massa

Para começar, você precisa de uma conta da Snyk e da CLI ou de um ADE compatível, além da sua própria chave de API do modelo, já que a prévia aberta usa seu próprio LLM por padrão. Mantenedores de projetos open source podem acessar a plataforma completa gratuitamente pelo Secure Developer Program, que inclui uma licença empresarial completa.

Encontrou uma correção que não resolveu o problema? Conte para a gente em r/AISecEng. Seu feedback ajudará a definir os próximos passos do Remediation Agent enquanto a Snyk continua desenvolvendo e aprimorando o produto em público.