Cycode acertou seis CVEs reais e expôs limite estrutural das regras SAST
A Cycode anunciou o Agentic Code Scanning em setembro de 2026. O sistema decide qual mecanismo revisa cada trecho de código.

A Cycode anunciou o Agentic Code Scanning em setembro de 2026. O sistema decide qual mecanismo revisa cada trecho de código. Além disso, ele define quanto aquela revisão pode custar. Para quem escreve código todos os dias, a pergunta muda de lugar. Antes o time discutia qual modelo usar. Agora o time discute quem decide isso a cada commit.
Lior Levy, cofundador e CEO da Cycode, resumiu o incômodo: “Ninguém entrou na área de segurança de aplicações para se tornar um economista modelador”.
Cycode organiza a leitura de código em quatro dimensões sobre o mesmo commit
A empresa executa quatro tipos de análise no mesmo código. Depois, reconcilia tudo em uma visão única de risco.
A primeira dimensão é o SAST determinístico. Ela combina padrões e regras de detecção de mudança. Roda dentro da IDE, no MCP↳MCP7 conteúdosArquitetura de Sistemas Cognitivos: Integração de RAG, MCP e LLMs no Ecossistema .NETDev (Back & Front) · abr 2026MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025Agentes de IA com LLMs de Código Aberto: Integração Prática com o Model Context Protocol (MCP)AI · ago 2025Ver tudo em AI →, nos ganchos antes do commit e no bloqueio de pull requests. O retorno vem em menos de um segundo sobre um diff. Como o resultado é sempre idêntico, essa é a única dimensão rápida o bastante para barrar um merge.
A segunda dimensão é o SAST com IA. Nela, um LLM gera, atualiza e personaliza as configurações do SAST determinístico. Ou seja, a varredura por regras melhora a cada execução. Ainda assim, a saída continua reproduzível.
A terceira dimensão junta regras e avaliação de explorabilidade. Primeiro, o motor de regras encontra candidatos. Em seguida, um LLM faz a triagem, ranqueia e argumenta a explorabilidade. Só então o achado chega à fila do desenvolvedor.
A quarta dimensão parte de um modelo de ameaças e tenta refutar o próprio achado
O Agentic Code Scanning fica acima das outras três. Ele define o que roda, em que ordem e sob qual orçamento. O planejamento parte de um modelo de ameaças. Depois, o agente ranqueia o que precisa ler por classe de vulnerabilidade. Por fim, ele tenta derrubar cada achado que produziu.
As dimensões mais baratas resolvem primeiro as classes já conhecidas. Assim, o gasto com modelo vai apenas para onde as regras não alcançam. Com isso, nenhuma classe de vulnerabilidade fica de fora porque o orçamento acabou.
Cadeias de ataque valem mais que listas de achados
Os achados recebem pontuação um a um. Na prática, porém, ninguém explora um achado isolado. O Agentic Code Scanning liga achados relacionados entre arquivos. O resultado é um caminho de ataque com várias etapas. Esse caminho carrega o fluxo de dados desde a origem não confiável até o ponto perigoso.
O Context Intelligence Graph sustenta cada caminho. Ele usa relações de chamada, propriedade do código e alcançabilidade. Dessa forma, o caminho deixa de depender de especulação do modelo. Como a cadeia só existe enquanto todos os elos existem, a correção mira o elo mais barato de quebrar.
Depois, os achados qualificados alimentam os Agentic Workflows como fluxo de eventos. O time define o fluxo uma vez. Nessa definição entram eventos de disparo, sequência de ações do agente, limites de confiança e controles. Quando um evento qualificado acontece, o fluxo roda sozinho. O achado vai para quem escreveu o código. A correção volta como pull request validado contra o achado original. Além disso, cada execução gera trilha de auditoria.
Dez repositórios, seis linguagens e um commit vulnerável fixado
A Cycode testou a abordagem em dez repositórios. Eles cobrem seis linguagens e cada um foi fixado em um commit vulnerável exato. Seis eram aplicações reais paradas em uma CVE publicada. As outras quatro eram aplicações vulneráveis de propósito, com gabarito. Segundo a empresa, o motor nunca foi ajustado contra elas.
Nas seis CVEs publicadas, os outros fornecedores testados não retornaram nenhuma captura válida. A primeira dimensão da própria Cycode pegou três das seis. Todas as três eram falhas de injeção ou de travessia de caminho. Já o Agentic Code Scanning pegou as seis, de acordo com a empresa.
As duas CVEs que nenhum motor de regras pegou, inclusive o da Cycode
Duas das seis envolviam falhas de autorização. Uma era controle de acesso quebrado no Gitea. A outra era desvio de autenticação no middleware do Next.js↳Next.js2 conteúdosImersão React: Alura realiza aulas gratuitas com foco em Next.JSGestão Dev & TI · jan 2021Criando sua primeira aplicação com RemixDev (Back & Front) · set 2024Ver tudo em Dev (Back & Front) →. Nenhum motor de regras testado pegou qualquer uma delas. Isso inclui o motor da própria Cycode.
A explicação é estrutural. Uma falha de autorização aparece como ausência de checagem. Regras procuram padrões presentes no código. Portanto, a ausência escapa por definição. É por isso que o controle de acesso quebrado segue como risco número um da OWASP.
573 disparos no MLflow e apenas dois dentro do arquivo CVE
A regra que revelou a leitura arbitrária de arquivos no MLflow disparou 573 vezes naquele repositório. Apenas duas ocorrências estavam registradas no arquivo CVE. As demais se espalhavam entre 173 e 701 ocorrências por repositório. Nenhuma delas era classificada, validada ou rastreada até a causa raiz. Já o Agentic Code Scanning devolveu uma ocorrência validada e com causa raiz por CVE.
Esse contraste importa mais que o placar. Volume de detecção e causa raiz validada são coisas diferentes. Além disso, volume alto consome tempo de engenharia toda semana.
O que dá para testar nos seus próprios repositórios
A Cycode diz que vai publicar o corpus e as configurações do teste. Com isso, o resultado pode ser reproduzido de forma independente. Essa publicação separa o benchmark de uma alegação fechada de fornecedor. Ainda assim, restam perguntas em aberto. Não se sabe se a mesma taxa se mantém em mais repositórios, linguagens ou classes de CVE.
Para o time de desenvolvimento, três verificações são práticas. Primeiro, meça quantas vezes suas regras disparam por repositório. Depois, veja quantos desses disparos viraram correção de fato. Por fim, teste uma classe de autorização de propósito e observe o que passa.
Enquanto a discussão pública gira em torno de qual modelo é melhor, o custo real aparece na roteirização. Quem decide o que roda define a conta no fim do mês.
Acompanhe nosso perfil no Instagram!








