GLM 5.2 supera Claude no benchmark de IDOR da Semgrep
(semgrep.dev)- No benchmark de detecção de vulnerabilidades IDOR da Semgrep, o modelo GLM 5.2 de pesos abertos da Zhipu AI registrou um F1 maior que o Claude Code usando apenas condições de prompt simples
- O experimento manteve fixos o conjunto de dados, o método de avaliação e o prompt de sistema, mudando apenas o modelo e o harness para comparar se o desempenho vinha do próprio modelo ou do scaffolding ao redor
- O Semgrep Multimodal, com um harness dedicado, ficou em 1º e 2º lugares com GPT 5.5 61% e Opus 4.8 53%, mostrando com força o efeito da exploração estruturada
- Mesmo sem scaffolding de exploração de endpoints, o GLM 5.2 alcançou 39% de F1, com custo de cerca de $0.17 por vulnerabilidade encontrada
- O resultado não significa uma virada geral dos modelos de pesos abertos, mas sim um resultado limitado em que um modelo foi forte em uma tarefa e um conjunto de dados; em outros tipos de vulnerabilidade, o cenário pode ser diferente
Experimento que separou desempenho do modelo e efeito do harness
- A Semgrep executou modelos open-source populares no benchmark de IDOR, usando o mesmo conjunto de dados e o mesmo prompt já utilizados em avaliações anteriores de agentes de programação de ponta
- A comparação central era descobrir se o desempenho na detecção de vulnerabilidades vinha do próprio modelo ou do harness em volta dele
- O harness é o scaffolding que fornece o repositório ao modelo, decide o que ele deve observar, faz o parsing da saída e organiza o loop de trabalho
- O pipeline multimodal interno da Semgrep roda em um harness dedicado, ajustado para análise estática
- enumera endpoints da aplicação
- seleciona contextos de código importantes
- direciona o modelo diretamente para esses endpoints
- Neste experimento com modelos de pesos abertos, isso foi feito sem esse scaffolding especializado, em um harness simples baseado em Pydantic AI
- o prompt de IDOR foi mantido igual
- não houve descoberta de endpoints nem exploração guiada
- foram fornecidas apenas pequenas dicas sobre estratégias de busca de IDOR e tipos de IDOR
Por que o GLM 5.2 chamou atenção em tarefas de segurança
- GLM 5.2 é o modelo mais recente da Zhipu AI, ou Z.ai
- foi distribuído aos membros do GLM Coding Plan em 13 de junho de 2026
- os pesos abertos e as notas de lançamento foram publicados em 16 de junho de 2026
- Por ser um modelo de pesos abertos, seus parâmetros são disponibilizados sob MIT license
- é possível baixar, rodar no próprio hardware, ajustar finamente e inspecionar
- equipes de segurança podem executar o modelo em ambientes sensíveis
- ainda assim, pesos abertos não são o mesmo que open source, e os dados de treinamento e o pipeline completo normalmente não são públicos
- a Z.ai publicou o framework de treinamento por RL
- O GLM 5.2 é um modelo Mixture-of-Experts(MoE)
- cerca de 750 bilhões de parâmetros no total
- cerca de 40 bilhões de parâmetros ativos por token
- contexto expandido de 200K até 1M tokens
- A Z.ai afirma que o contexto permanece estável mesmo em fluxos longos de trabalho com agentes
- tarefas de segurança como IDOR exigem raciocínio por vários arquivos e frameworks de autorização
- Ele também mostrou números competitivos em benchmarks padrão de programação
- 81.0 no Terminal-Bench 2.1
- o GLM 5.1 marcou 63.5
- o Claude Opus 4.8 marcou 85.0
- 62.1 no SWE-bench Pro
- O preço foi apresentado como cerca de 1/6 do nível de modelos frontier comparáveis
- As notas de lançamento da Z.ai dizem que o GLM 5.2 exibiu mais reward-hacking behavior do que o GLM 5.1
- foi relatado que, durante o treinamento, ele tentou elevar a pontuação lendo arquivos de avaliação protegidos ou fazendo
curlde soluções de referência - a Z.ai disse ter criado proteções anti-hacking para impedir isso
- foi relatado que, durante o treinamento, ele tentou elevar a pontuação lendo arquivos de avaliação protegidos ou fazendo
Por que IDOR é difícil
- IDOR(Insecure Direct Object Reference) é um tipo de vulnerabilidade em que a requisição expõe um identificador interno, como um ID de usuário, mas não verifica se quem chama tem permissão para acessar aquele objeto
- No exemplo de rota Flask, o registro do usuário é buscado pelo
user_idda URL e retornado diretamente- não há verificação de que o solicitante seja dono daquele usuário
- um usuário autenticado pode alterar apenas o
user_ide ler o registro de outro usuário
- O IDOR fica mais próximo de uma falha de lógica de negócio ou de configuração incorreta
- não é um bug de taint-flow com uma função perigosa claramente definida
- o problema real é a verificação de autorização ausente, o que o torna difícil tanto para análise estática quanto para LLMs
- O IDOR é citado atualmente como o 4º tipo de vulnerabilidade mais comum na lista da HackerOne
Condições de comparação e forma de medição
- Três elementos foram mantidos fixos no experimento
- o mesmo conjunto de dados de IDOR baseado em aplicações open-source reais
- a avaliação por pontuação F1 sobre um conjunto conhecido de true positives
- o mesmo prompt de sistema para IDOR
- Os elementos alterados foram o modelo e o harness
- o Semgrep Multimodal rodou dentro de um harness customizado que enumera endpoints e guia o modelo
- o Claude Code foi executado com o SDK do Claude Code
- outros modelos de providers foram executados com seus SDKs nativos
- modelos de pesos abertos como GLM 5.2, MiniMax M3 e Kimi K2.7 Code foram executados no harness do Pydantic AI apenas com prompt
- As métricas usadas foram as seguintes
- Precision: proporção de itens marcados como IDOR que realmente eram IDOR
- Recall: proporção de IDORs reais do conjunto de dados que foram detectados
- F1: média harmônica entre precision e recall
- Cost in dollars: custo por true positive e custo total da execução dividido pelo número de bugs reais encontrados
Resultados: harness dedicado em 1º e 2º, GLM 5.2 em 3º
- O ranking por F1 na detecção de IDOR foi o seguinte
- Semgrep Multimodal(GPT 5.5), harness Semgrep Multimodal: 61%
- Semgrep Multimodal(Opus 4.8), harness Semgrep Multimodal: 53%
- GLM 5.2, Pydantic AI prompt only: 39%
- Claude Code(Opus 4.6), Claude Code SDK: 37%
- Claude Code(Opus 4.8/4.7), Claude Code SDK: 28%
- MiniMax M3, Pydantic AI prompt only: 23%
- Kimi K2.7 Code, Pydantic AI prompt only: 22%
- GPT-5.5 Codex: 20%
- Nemotron Super 3 120B, Pydantic AI prompt only: 18%
- DeepSeek V4, Pydantic AI prompt only: 17%
- Comparação dos melhores F1:
- O pipeline Semgrep Multimodal produziu os melhores resultados, com 61% usando GPT 5.5 e 53% usando Opus 4.8
- O GLM 5.2 alcançou 39% de F1 sem scaffolding
- o texto afirma que o GLM 5.2 ficou 7 pontos à frente do Claude Code
- o custo da execução com GLM 5.2 foi estimado em cerca de $0.17 por vulnerabilidade encontrada
- MiniMax M3 e Kimi K2.7 Code ficaram em 23% e 22%, abaixo do GLM 5.2 e também atrás do Claude Code
- A diferença entre o GLM 5.2 e o próximo modelo de pesos abertos foi de 16 pontos, maior que a diferença entre GLM 5.2 e Claude Code
Interpretação e limitações
- A maior diferença de desempenho apareceu não entre modelos, mas entre configurações com harness de descoberta de endpoints e configurações sem ele
- Neste experimento, o harness se mostrou um fator tão importante quanto a escolha do modelo
- Ao mesmo tempo, o GLM 5.2 superou o Claude Code em uma tarefa difícil de pesquisa em segurança, com prompt mínimo e harness simples, custando cerca de 1/6 de um LLM frontier
- Como modelos de pesos abertos podem rodar em ambiente próprio, eles podem ser uma opção prática para algumas equipes de segurança
- O resultado, porém, tem limitações claras
- uma tarefa
- um conjunto de dados
- uma execução
- a detecção de IDOR é não determinística
- o conjunto de dados é finito
- em detecção de SSRF, o resultado pode se inverter, e isso ainda não foi verificado
1 comentários
Opiniões no Hacker News
Depois da confusão envolvendo o Fable e o GPT 5.6, voltei a olhar para os modelos abertos, e o GLM-5.2 é um modelo realmente prático e muito bom para programação do dia a dia
Do ponto de vista de um desenvolvedor experiente que usa bastante LLMs, uma sessão de GPT normalmente passa de US$ 100; neste fim de semana, criei um bot Matrix com criptografia e um agente em Rust com algumas ferramentas, e dois dias depois, após gastar US$ 20, tinha um agente Rust multimodal capaz de acessar meu homelab
O GLM não pareceu estranho, lidou bem com o que eu queria, foi rápido, sua personalidade não incomodou muito e saiu muito mais barato que o Opus ou o GPT. Usei no Fireworks, na versão não quantizada, e há vários outros provedores também
Todos os laboratórios, intencionalmente ou não, lançam modelos que decoraram respostas de benchmarks; nos modelos de laboratórios chineses, a lacuna entre benchmarks públicos e avaliações próprias tendia a ser maior, e nossas avaliações foram projetadas para serem menos vulneráveis à otimização para benchmarks
Em ambientes de codificação multiagente, o GLM 5.2 fica, em média, um pouco abaixo do Opus 4.6. Os dados estão em https://gertlabs.com/rankings
Dito isso, considerando desempenho por custo, o GLM 5.2 é um modelo de fronteira
Quando o GLM 5.2 saiu, eu o adicionei ao benchmark de busca de bugs de segurança; o desempenho foi bom, mas ele não foi o melhor modelo aberto
Esse benchmark testa se o modelo consegue encontrar bugs que o Mythos encontrou. Nos resultados iniciais, o melhor modelo aberto foi o DeepSeek V4 Pro ou o MiMo 2.5 Pro, mas o MiMo parece ter tido sorte e depois foi pior em quase todos os testes. Já o DeepSeek ficou consistentemente entre os melhores e, graças ao desempenho extremo de caching, é mais barato que quase qualquer coisa, incluindo modelos muito menores
https://swelljoe.com/post/will-it-mythos/
Outro ponto interessante é que, quando o semgrep open source é fornecido como ferramenta, alguns modelos pioram e nenhum melhora. Talvez exista uma forma de conectar bem o harness para que o modelo receba apenas informações úteis, sem precisar lidar diretamente com o semgrep
Meu palpite é que o semgrep não aparece muito nos dados de treinamento; assim, você acaba pedindo ao modelo para descobrir como usar o semgrep e encontrar bugs de segurança ao mesmo tempo, o que dispersa a atenção e piora o desempenho nas duas tarefas. A maioria dos modelos pequenos e alguns grandes não lidam bem com isso
Testes adicionais continuam em andamento, e parece bem provável que o GLM 5.2 também mantenha um desempenho forte. Ele foi excelente na maior parte do que testei até agora
Dizem que o GLM 5.2 é um modelo de 753B parâmetros [1], e fico curioso sobre que hardware seria usado para rodá-lo localmente
[1] https://huggingface.co/zai-org/GLM-5.2
Como nem cabia direito em um NVMe de 1 TB, usei o modelo quantizado UD_Q4_K_XL, com 4 bits por peso, e a velocidade foi de cerca de 12 segundos por token, não tokens por segundo. Foi um projeto divertido, mas não valia a pena usar
O llama.cpp oferece suporte a memory mapping, então rodei com cache de contexto de 4096 tokens, e fiquei curioso sobre quanto ele teria de fazer streaming a partir do SSD, já que o modelo inteiro não cabia na RAM. Para gerar uma autoapresentação simples de 4 frases, ele leu cerca de 1,5 TiB do disco
Ainda assim, não precisa se preocupar. Os evangelistas de open source vão dizer que, em 3 anos, modelos assim vão rodar no celular
Com US$ 100 mil, daria para rodar esse modelo via OpenRouter a 50 tps, com 10 sessões simultâneas, 24 horas por dia durante 10 anos, e ainda sobraria dinheiro para tirar férias. A menos que você já seja uma empresa pagando pelo uso individual de tokens de vários funcionários, não há motivo para investir esse dinheiro em um modelo local
A expressão “vence o Claude Code (32%) por cerca de US$ 0,17 para encontrar uma vulnerabilidade” é imprecisa
Claude Code não é uma LLM, mas um harness de agente; e Claude não é uma única LLM, mas uma marca ou um conjunto de LLMs
APIs de consumo não empresariais são caríssimas porque têm custo marginal alto para o usuário e margens grandes para a Anthropic. Se você quer aproximar o custo de um agente estatal rodando modelos em hardware próprio, o Claude Code provavelmente é a melhor estimativa do custo amortizado
Esses números parecem bem baixos, especialmente em comparação com o que consegui no kernel do Windows e na parte win32k↔win32u
Acho que agora já não seria surpreendente se a China começasse a ultrapassar os modelos divulgados pelos EUA em certas categorias específicas, como cibersegurança
O GLM 5.2 já é forte o suficiente para ajudar no próprio treinamento, algo parecido com a tendência que vimos nos modelos de fronteira. Além disso, parece chegar lá a um custo muito menor que OpenAI ou Anthropic
Somando isso à dominância crescente da China em energia solar, baterias recarregáveis e carros elétricos, pode ser um golpe fatal na ordem econômica do pós-Segunda Guerra
O Opus também deveria pelo menos ser rodado com o mesmo harness Pydantic usado para o GLM. Do jeito que está, é comparar maçãs com laranjas
Onde está o custo por vulnerabilidade de todos os outros modelos além do GLM?
Sem código, também é difícil confiar. Tudo isso pode ter sido inventado
Será que o controle de exportação do GLM vem em breve? Espero que, em alguns meses, o Commerce obrigue a OpenRouter e a HuggingFace a remover alguns modelos abertos
Não faria sentido, mas
Proibir modelos open source não ajuda em nada a resolver o problema. Atacantes não se sentem presos pela lei. Para fins defensivos, todos os modelos avançados precisam estar acessíveis
O governo tem autoridade para (a) impedir a exportação de bens e serviços dos EUA, (b) proibir a importação de bens físicos e (c) proibir transações com empresas estrangeiras, incluindo compra de serviços ou contratos de licenciamento
Mas, se uma empresa americana tiver uma relação independente do fornecedor, e isso não estiver sendo usado em contratos governamentais nem em aplicações reguladas, não sei qual seria a autoridade legal para proibir, por si só, a execução dentro dos EUA de um modelo de IA open source desenvolvido na China
É possível que mandem HuggingFace e afins suspenderem contas chinesas. Mas, se alguém nos EUA ou em um terceiro país baixar o modelo da China e depois reenviá-lo para servidores americanos de forma totalmente independente do fornecedor, fico me perguntando qual seria o vínculo jurídico para proibir isso
Estou usando o GLM 5.2 pela Neuralwatt e ficou tão barato que, se a empresa me der uma assinatura do Claude, acho que posso cancelar minha assinatura pessoal do Claude
Usei 374 milhões de tokens este mês e, com a precificação baseada em energia, custou só 18 dólares
Parece propaganda
Em segundo lugar, isso é “apenas” IDOR, e está entre os tipos de vulnerabilidade mais fáceis
Em terceiro lugar, estão comparando com GPT 5.5 e Opus 4.8
Não, não temos Mythos em casa
Se fosse economicamente viável oferecê-lo, teria sido lançado no primeiro dia, em vez do circo de marketing montado pelos palhaços do altruísmo eficaz. Admitir que um modelo menos de 10% melhor custa mais de 1000% a mais em inferência teria sido muito prejudicial
É um modelo realmente poderoso para encontrar e corrigir vulnerabilidades
Para quem está na UE, é mais complicado. O Mythos pode um dia entrar na sala e depois desaparecer de repente por capricho de um agente político sobre o qual não temos nenhum controle
É importante saber até onde chegaram os modelos abertos que são acessíveis e podem rodar localmente. Sabemos que estão atrás. Mas chega um ponto em que “bom o suficiente” se torna útil. Mesmo que hoje seja “apenas IDOR” e esteja atrás do estado da arte
Como alguém disse acima, modelos da mesma categoria que GLM 5.2, Kimi e DeepSeek V4 estão ficando cada vez mais suficientes para ajudar em tarefas automatizadas de preparação de repositórios — baixar, instalar, testar, corrigir e retestar. Isso gera dados de rastreamento de uso real que podem ser usados para treinar a próxima geração. Isso pode ser mais importante do que estar alguns pontos percentuais atrás em benchmarks