Modelos de ponta encontraram as vulnerabilidades. Só o atacante encontrou as cadeias.

Os invasores não leem seu repositório: eles acessam sua URL e encadeiam tudo o que encontram. Em uma era em que a IA ofensiva ataca aplicações em produção na velocidade das máquinas, suas ferramentas de segurança precisam ir além de encontrar vulnerabilidades: precisam comprovar a explorabilidade, inclusive se elas podem ser combinadas para causar uma violação.

Então, fizemos um teste. Direcionamos o Evo Continuous Offensive Security (COS) e o Claude Security com Mythos para a mesma aplicação: TaintedPort. É um aplicativo web intencionalmente vulnerável que reproduz classes de bugs do mundo real e um conjunto de cadeias de exploração conhecidas. São ferramentas de tipos diferentes: o COS ataca a aplicação em execução, enquanto os dois produtos Claude analisam o código-fonte. Usamos o mesmo alvo para descobrir o que cada abordagem consegue comprovar.

O Evo COS confirmou 10 das 15 cadeias de exploração.

Isto não é uma crítica aos modelos — nós os usamos

O Claude Security com Mythos representa um avanço real na descoberta de vulnerabilidades com IA. Ele analisa o código-fonte como um bom revisor humano e detecta classes de falhas que ferramentas baseadas em correspondência de padrões deixam passar. Mas encontrar uma falha no código e comprovar que um invasor pode explorar essas vulnerabilidades são tarefas diferentes.

O caminho de ataque comprovado pelo COS

Todas as ferramentas deste teste encontraram a falha de falsificação de solicitação do lado do servidor (SSRF) e identificaram que o segredo de assinatura JWT da aplicação estava codificado diretamente no código. O Evo COS foi além: usou a SSRF para acessar e recuperar o segredo de assinatura da aplicação em execução. Em seguida, usou esse segredo para criar um token de administrador válido e assumir o controle da área administrativa. Duas descobertas, conectadas em um caminho completo de tomada de conta, foram demonstradas contra a aplicação em produção com uma prova de conceito executável.

Acima: CHAIN-004 conforme pontuada para o COS. Todas as ferramentas deste teste relataram individualmente as duas descobertas que a compõem: a falha de SSRF e o segredo codificado diretamente no código. O Evo COS confirmou que elas podem ser combinadas para forjar um token de administrador.

É assim que um ataque autônomo acontece na prática: conquistar um ponto de acesso e, a partir dele, encadear outros ataques. O Evo COS mostra o caminho e inclui uma prova de conceito executável para cada cadeia confirmada.

Resultados

TaintedPort v1.35, avaliado com base em um gabarito fixo de 57 vulnerabilidades conhecidas e 15 cadeias de exploração conhecidas, em uma escala ponderada por gravidade (Baixa 1, Média 3, Alta 9, Crítica 27; cada cadeia confirmada foi pontuada com sua própria gravidade, além das descobertas que a compõem). A detecção ponderada é calculada por pontos encontrados ÷ 938 pontos disponíveis: 587 das 57 vulnerabilidades e 351 das 15 cadeias.

O Claude Security encontrou mais uma vulnerabilidade de gravidade crítica (10 contra 9). O Evo COS encontrou o maior número de vulnerabilidades, teve a maior precisão (96,2% contra 90,2%), com menos falsos positivos, e conseguiu identificar e comprovar cadeias de exploração.

Por que atacar a aplicação em produção?

O Evo COS é um sistema dinâmico: seu alvo é sempre uma URL ativa, e o código-fonte é uma entrada opcional que transforma uma execução de caixa-preta em caixa-cinza. Ele nunca atua apenas sobre o código. O Claude Security foi executado em modo caixa-branca (somente código).

Essa é uma comparação entre disciplinas diferentes: o Evo COS é um teste de intrusão ofensivo que investiga e explora a aplicação em execução, um processo fundamentalmente mais intensivo do que uma única análise de código. É a mesma divisão complementar que sempre existiu no setor entre DAST e SAST. Aqui, mostramos o que testar a aplicação em produção comprova — e o que analisar apenas o código não consegue: que essas vulnerabilidades são reais e podem ser encadeadas.

As descobertas relatadas apenas pelo Evo COS são, em sua maioria, comportamentos em tempo de execução: respostas refletidas e mal configuradas, ausência de proteções de transporte, tokens que continuam válidos após o logout e gerenciamento fraco de sessões. O Evo COS conseguiu confirmar várias falhas de lógica de negócios dependentes do contexto: autorização quebrada em nível de objeto em atualizações de perfil, escalonamento de privilégios por meio de declarações JWT forjadas e uma falha crítica em que uma única leitura de um segredo TOTP armazenado anula a autenticação de dois fatores. As cadeias exigem chegar a cada etapa pela aplicação em execução e confirmar que a próxima etapa pode ser realmente alcançada. Um modelo que analisa o código precisa inferir se uma vulnerabilidade é executada — e deixa passar a cadeia.

Você pode criar um harness, mas não pode criar o contexto

O debate deste ano sobre benchmarks chegou a uma conclusão válida: o sistema ao redor de um modelo importa mais do que o próprio modelo. Vamos além. “Qual harness?” não é uma pergunta neutra — e a resposta é onde está a verdadeira vantagem.

O Evo COS orquestra vários modelos, incluindo os modelos Claude de ponta, cada um direcionado à tarefa que executa melhor. Portanto, esse resultado não é uma história sobre a qualidade dos modelos. A mesma classe de modelo que impulsiona uma revisão de código de ponta faz parte do Evo COS. O que muda é o sistema ao redor: o Evo COS parte do que a plataforma Snyk já sabe sobre o alvo, em vez de começar do zero; reúne um grupo de agentes, cada um orquestrado para uma finalidade específica, e cada descoberta passa por uma etapa independente de validação antes de ser apresentada, porque o sistema que gera uma descoberta não deve ser o mesmo que a avalia.

Qualquer pessoa pode conectar um modelo de ponta a um agente de programação hoje à noite e direcioná-lo a um repositório. Mas essa configuração não consegue reproduzir o contexto acumulado e validado com que o Evo COS começa, o validador independente nem os testes contra a aplicação em produção.

Testes dinâmicos e estáticos são complementares

O Claude Security detectou várias vulnerabilidades que o Evo COS não encontrou, principalmente falhas de lógica e criptografia visíveis no código-fonte que nem sempre aparecem na aplicação em execução. Nenhuma das abordagens é completa por si só; esse é o argumento a favor de uma plataforma em vez de uma ferramenta pontual. Analisar o código e atacar a aplicação em execução permite que cada abordagem encontre o que a outra não encontra.

Metodologia

TaintedPort é uma aplicação intencionalmente vulnerável da própria Snyk, criada e mantida pela nossa equipe e disponível publicamente. O Evo COS não foi ajustado para ela.

Alvo: TaintedPort: 57 vulnerabilidades conhecidas (34 comuns, 23 de lógica de negócios) e 15 cadeias de exploração conhecidas.

Ferramentas e entradas:

• Evo COS: caixa-cinza (URL ativa + código-fonte), 18 de setembro.

• Claude Security: caixa-branca (código-fonte), Mythos com raciocínio estendido, 18 de setembro.

Execuções: uma por ferramenta. Os resultados são os dados de uma única execução, não medianas.

Detecção por categoria

Detecção por gravidade (encontradas/conhecidas)

Falsos positivos e F1

Reproduza: TaintedPort está disponível em taintedport.com.

Quer saber quais descobertas nas suas próprias aplicações podem ser encadeadas para causar uma violação? Veja como o Evo Continuous Offensive Security testa sua URL ativa.