Cibersegurança em benchmark: 84,5% do GLM 5.3 dizem sobre código

Cibersegurança↳Segurança171 conteúdosCibersegurança no Brasil: 6 passos para sair da estagnaçãoDevSecOps · jul 2025O papel do CISO para transformar a cibersegurança em uma alavanca de reputação para as empresasDevSecOps · mar 2024Itaipu Parquetec e Exército Brasileiro realizam exercício de cibersegurança em BrasíliaDev (Back & Front) · set 2025Ver tudo em DevSecOps → virou o principal campo de disputa entre modelos de IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → nesta semana. A Z.ai colocou o GLM 5.3 no topo do CyberGym com 84,5% de aproveitamento. Logo atrás aparecem o Mythos 5, da Anthropic, com 83,8%, e o GPT 5.6 Sol, da OpenAI, com 83,6%. Portanto, o primeiro e o terceiro colocado cabem dentro de um ponto percentual. Ainda assim, o número isolado explica pouco sobre risco real. Vale abrir a configuração do teste antes de qualquer conclusão.

Cibersegurança medida em 1.507 tarefas: o que o CyberGym cobra do agente

O CyberGym reúne 1.507 tarefas voltadas à descoberta e à validação de vulnerabilidades. A Z.ai reporta Pass@1 em execução única, sem limite de tempo por tarefa. Além disso, o agente roda dentro do contêiner de cada tarefa. A empresa afirma ter removido informações de Git e aplicado uma lista de domínios permitidos. Assim, sobraram endereços como pypi.org e deb.debian.org, usados apenas para instalar ferramentas básicas. A avaliação usou o framework Claude Code 2.1.207, esforço máximo de raciocínio e nenhuma ferramenta web. Também entraram temperatura 1,0, top_p 1,0 e saída máxima de 128 mil tokens. Ou seja, o cenário tem acesso ao código, ambiente controlado e verificação definida. Na prática, isso fica bem distante da sua superfície de ataque em produção.

84,5% no placar e três lacunas que o relatório deixou em aberto

A Z.ai deixou de publicar três dados que interessam a qualquer time de segurança. Primeiro, faltam taxas de descoberta de vulnerabilidades em tempo real. Depois, faltam taxas de falsos positivos. Por fim, faltam resultados de correção. Enquanto isso, o placar circula como prova de capacidade ofensiva. Portanto, trate a pontuação como um recorte controlado de capacidade.

ExploitBench inverte o pódio e revela outro tipo de dificuldade

O ExploitBench avalia etapas posteriores, já com análise e exploração das falhas. Ali o GLM 5.3 marcou 54,4%, contra 24,4% do GLM 5.2. O salto entre as duas gerações impressiona à primeira vista. Contudo, o Mythos 5 chegou a 78% e o GPT 5.6 Sol a 76,5%. O teste usou 41 tarefas em três revisões, com limite de 300 rodadas de interação. O resultado sai como média de cobertura, somando o que cada revisão alcançou. Logo, a leitura muda conforme o estágio do ataque que você observa.

ExploitGym conta tarefas por hora, e o relógio recebe ajuste

O ExploitGym cobre 869 tarefas e mede conclusão dentro de orçamentos de tempo. O GLM 5.3 fechou 105 tarefas em duas horas e 130 em seis horas. O GLM 5.2 ficou em 29 e 39 no mesmo intervalo. Já o Mythos 5 alcançou 181 e 247, mantendo a liderança nesse corte. O Kimi K3, terceiro colocado, entregou 36 e 70. Aqui entra um detalhe técnico que muita gente ignora. Esses orçamentos combinam overhead fora da API com tempo de inferência reescalado. A Z.ai usou números de tokens por segundo da Artificial Analysis para esse ajuste. Foram 115 tokens por segundo no GLM 5.3, 40 no Kimi K3 e 47 no Qwen3.8 Max. Ou seja, velocidade de inferência entra direto na conta do resultado.

Cibersegurança entrou no treinamento posterior, e o placar respondeu

O GLM 5.3 parte do mesmo modelo base do GLM 5.2, segundo a Z.ai. A empresa atribui o avanço à etapa de treinamento posterior. Dados de descoberta de vulnerabilidades e ambientes de tarefa entraram nessa fase. Em seguida, a companhia diz ter observado ganhos adicionais conforme escalava o processo. Agentes de pesquisa geram ambientes executáveis a partir de padrões de tarefa. Depois, um agente juiz tenta resolver cada tarefa para checar se ela tem solução. Os verificadores nascem sem acesso à solução de referência, conforme a Z.ai. Além disso, passam por checagens de oráculo, de operação nula e de estado sem solução. Assim, a empresa afirma que o modelo passou a planejar cadeias completas de exploração.

2.436 falhas, 269 projetos e um bug plantado em 1981

A Z.ai mantém um registro público de divulgação com números altos. São 2.436 vulnerabilidades em 269 projetos, após revisão especializada e remoção de duplicatas. Desse total, 107 aparecem como críticas e 990 como de alta gravidade. O restante se divide em 1.286 médias e 53 baixas. Até agora, 53 descobertas saíram a público e 2.383 seguem sob embargo. As falhas atingem kernels, sistemas operacionais, motores de navegador e infraestrutura de código aberto↳Open source71 conteúdosComo o Open Source Está Liberando o Poder da Automação para TodosDev (Back & Front) · out 2025Código aberto: programadores criam software da NASA sem saberDev (Back & Front) · abr 2021N8N: O que é a ferramenta open source que está revolucionando a automação em TI?Dev (Back & Front) · dez 2025Ver tudo em Dev (Back & Front) →. Aplicações web e protocolos de rede também aparecem na lista. A mais antiga foi introduzida em 1981, segundo a empresa. Em média, cada falha sobreviveu 26,6 anos antes de alguém encontrar o problema. Portanto, dívida técnica antiga virou material de treino para agentes ofensivos.

Sua chamada de API quebra se você trocar apenas o ID do modelo

Esta versão muda a configuração de raciocínio. Cibersegurança e o campo reasoning_effort aceita low, high e max, com max como padrão. A Z.ai recomenda max para tarefas de codificação. O thinking desativado saiu de cena nesta geração. Portanto, aplicações que enviam thinking.type igual a disabled precisam de ajuste antes da migração. Primeiro, mude esse valor para enabled. Depois, escolha reasoning_effort igual a low, caso queira manter a latência baixa. Só então atualize o identificador do modelo. Caso contrário, a requisição falha. Uma chamada válida usa model glm 5.3, thinking type enabled e reasoning_effort max.

Cibersegurança na sua rotina: o que fazer com esse placar amanhã

Benchmark funciona como sinal, então use o sinal com contexto. Comece medindo o comportamento desses agentes no seu próprio repositório. Em seguida, registre falsos positivos, porque essa métrica define o custo de triagem. Depois, separe descoberta de correção, já que os dois estágios exigem garantias diferentes. Além disso, revise permissões de rede e de contêiner antes de soltar qualquer agente. A Z.ai promete liberar os pesos duas semanas após o lançamento, depois de avaliação de segurança. Enquanto isso, vale acompanhar como cada fornecedor descreve o próprio ambiente de teste. Afinal, a configuração explica o número tanto quanto o modelo.

Acompanhe nosso perfil no Instagram!