Cognition lança Devin Security 2.0 e distribui créditos na casa das centenas de milhões

A Cognition lançou o Devin Security 2.0, produto que acompanha a vulnerabilidade da detecção até um pull request verificado. A base é um escaneamento gerenciado com o Claude Mythos e outros modelos frontier voltados à cibersegurança, a priorização conforme o modelo de ameaças de cada empresa e correções autônomas. Junto com o lançamento, a Cognition promete créditos do Devin na casa das centenas de milhões de dólares: scans gratuitos para clientes corporativos atuais e futuros e créditos para corrigir as falhas mais críticas dos novos clientes.

Por que a fila de vulnerabilidades passou a pesar mais que as próprias

vulnerabilidades

A empresa explica o lançamento com um episódio recente. Na semana passada, os projetos PHP e Node.js divulgaram vulnerabilidades de execução remota de código. Toda empresa que usa essas stacks ficou na mesma situação: caminho de exploração público, atacantes lendo o mesmo advisory e patches para aplicar em imagens de contêiner, pacotes de SO, pipelines de CI e configurações de infraestrutura em dezenas de repositórios.

A Cognition também analisa o exploit PHP2Shell. Sinais de um dos problemas de fundo já tinham sido notados em 2024, mas os mantenedores não encontraram um caminho concreto até o RCE. A correção travou em concessões de compatibilidade, falta de recursos e disputas sobre a abordagem, enquanto bugs mais óbvios ganharam prioridade. Segundo o Wiz, modelos frontier ajudaram pesquisadores a montar e adaptar, em poucas horas, exploits funcionais para vários aplicativos. A conclusão é incômoda: os backlogs podem guardar muitos bugs adiados que a IA tornou práticos para ataques.

Por outro lado, a IA também infla o fluxo de entrada. O mantenedor do curl, Daniel Stenberg, descreveu o fenômeno como “alto volume com alta qualidade”. Segundo dados do projeto de 22 de outubro de 2026, já são 356 relatórios, contra 181 em todo o ano de 2025. Para comparação, em 2024 foram 86, e em 2023, 102.

Como funciona o pipeline do Devin Security

O escaneamento usa a arquitetura Agentic MapReduce, independente de modelo. Os repositórios mais críticos recebem modelos frontier; para os demais, é possível escolher opções mais baratas. O processo tem cinco etapas:

• Plan: o agente cruza o repositório com o modelo de ameaças e escreve regras para o código sensível, como rotas, limites de autorização, acesso a dados, desserialização e chamadas de API perigosas. • Shard: o código selecionado é dividido em grupos. • Map: agentes separados investigam os grupos em paralelo. • Reduce: os resultados são agregados, os duplicados são removidos e as descobertas que juntas formam uma cadeia de ataque mais grave são ligadas entre si. • Verify: os casos prioritários são verificados em sandbox, em uma instância em execução do aplicativo.

Depois disso, as descobertas podem ser atribuídas ao Devin uma a uma ou em lote. Ele as confronta com o código atual, agrupa as que se resolvem com uma única correção e abre sessões independentes, cada uma com sua própria máquina virtual. Nela, o Devin sobe serviços reais, reproduz o problema, escreve uma correção pontual, roda o teste de reprodução e os testes existentes e abre um PR com os resultados da investigação.

A descoberta continua aberta até o PR ser mergeado e o Devin confirmar que o caminho de ataque foi fechado. Se a correção definitiva ainda estiver em preparo, e desde que o acesso esteja configurado, o agente pode aplicar temporariamente uma regra de WAF, alterar um security group ou fechar o acesso público ao serviço.

Modelo de ameaças em vez de uma única nota CVSS

A prioridade é definida por perguntas: o código vulnerável é alcançável a partir de entrada não confiável, por qual fronteira de confiança, se é preciso autenticação ou uma configuração específica, se o código está em uso; e o que o dano significa para o negócio, seja ler dados de terceiros, escalar até administrador da organização ou usar o produto sem pagar. O Devin reúne as respostas em um modelo de ameaças, junto com a equipe: serviços, hosts, políticas de rede, fluxos de dados e fronteiras de confiança. Parte disso pode ser lida do código e das definições de infraestrutura; outra parte (a região do serviço, a acessibilidade de uma ferramenta interna pela internet) não pode, e por isso o trabalho é conjunto.

A verificação é necessária mesmo para modelos fortes. Segundo a análise Glasswing, da Anthropic, de 1752 descobertas inicialmente classificadas como high ou critical, 90,6% eram vulnerabilidades reais, mas só 62,4% se confirmaram como high ou critical. Encontrar um bug e avaliar corretamente sua gravidade são tarefas diferentes.

O mesmo processo vale para o passivo acumulado: o Devin importa descobertas do Snyk, do Wiz, de arquivos CSV e de relatórios de bug bounty, preservando os identificadores e links originais. Sessões paralelas as reverificam no código atual, procuram duplicatas e checam se o problema já foi resolvido. As decisões de fechar e reabrir são sincronizadas de volta com as ferramentas compatíveis. Também é possível reverificar relatórios antigos, gerados por modelos de IA mais fracos.

Outro cenário é o de compliance. Em FedRAMP, PCI DSS e políticas internas, uma descoberta high ou critical dispara a contagem do prazo de correção, e o risco só pode ser reduzido com documentação. Para cada descoberta reavaliada, o Devin guarda o CVSS original e escreve uma justificativa em seis eixos:

• alcançabilidade — se a entrada não confiável pode chegar ao código; • autenticação — quais permissões são necessárias; • dados — o que pode ser exposto ou alterado; • fronteiras de confiança — qual fronteira precisa ser atravessada; • validação — o que foi tentado e o que foi observado, inclusive resultados inconclusivos; • origem — de onde veio a descoberta.

Uma pessoa aprova a conclusão e a exporta para o POA&M ou para um sistema de GRC. O Devin não reavalia vulnerabilidades do catálogo CISA KEV.

Por onde a equipe de segurança pode começar

O mínimo prático é juntar em um só lugar o backlog acumulado do Snyk, do Wiz e do bug bounty e reverificá-lo no código atual, sem confiar nas avaliações antigas. Em paralelo, vale formalizar o modelo de ameaças: sem ele, qualquer prioridade automática continua sendo palpite. Para os repositórios críticos, faz sentido rodar um scan com um modelo forte enquanto os scans gratuitos da Cognition estão disponíveis, deixando todas as correções para revisão humana. A Cognition espera que a “primeira milha” da resposta a incidentes logo seja feita sem humanos. O chefe de segurança da empresa, Alex Stamos, pretende falar sobre o cenário de ameaças em um encontro no dia 26 de outubro, às 10h30 no horário do Pacífico.