Sommario
Cybersecurity
Consulenza CISO-as-a-service: postura, roadmap di remediation, supporto continuativo.
Scopri →
Servizi & Sistemi Linux
Domini, hosting, PEC, infrastruttura email, servizi di rete e sistemi Linux. Assistenza e gestione dell'infrastruttura Open Source.
Scopri →
Z.ai ha pubblicato il 14 agosto 2026 un annuncio intitolato “GLM-5.3: Frontier Coding with Emergent Cyber Capabilities”. La frase che regge il pezzo dal punto di vista tecnico è questa: “Scaling post-training is all we did for GLM-5.3”, seguita da “It uses the same base model as GLM-5.2, every gain comes from post-training”.
È lo stesso schema che avevamo visto il primo agosto con DeepSeek V4 Flash, architettura invariata e post-training nuovo. Il predecessore lo avevamo raccontato a giugno, quando GLM 5.2 arrivò alla frontiera dei pesi aperti sotto licenza MIT.
I pesi non sono ancora pubblici. Al 18 agosto l’organizzazione zai-org su HuggingFace si ferma a GLM-5.2, e su ModelScope ZhipuAI/GLM-5.3 risponde 404 con record not found. L’annuncio dice “We will release the weights in two weeks after launch”, quindi la scadenza cade verso il 28 agosto e non è ancora maturata.
Il modello, per quello che se ne sa
Se la dichiarazione sulla stessa base regge, valgono i parametri di GLM-5.2, che sono pubblici e verificabili nel suo config.json.
| GLM-5.2 | |
|---|---|
| Parametri totali | 753.329.940.480, dai metadati safetensors |
| Architettura | MoE, model_type glm_moe_dsa |
| Layer | 78, di cui 3 densi e 75 MoE |
| Esperti | 256 routed più 1 condiviso, 8 attivi per token |
| Contesto | 1M token (max_position_embeddings 1048576) |
| Licenza | MIT |
L’attenzione è DeepSeek Sparse Attention, e sopra ci sta un meccanismo che il model card chiama IndexShare, descritto nel paper arXiv 2603.12201 (che su arXiv si intitola IndexCache): riusa lo stesso indexer ogni quattro layer di attenzione sparsa, “reducing per-token FLOPs by 2.9x at a 1M context length”. C’è anche un layer MTP per il decoding speculativo in stile EAGLE.
Sono numeri di architettura, e non dicono niente sulle capacità. Hanno però una conseguenza pratica sul dove farlo girare, con una precisazione che viene da un pezzo che abbiamo scritto a luglio: 753 miliardi di parametri non impongono per forza un cluster, perché colibri fa girare GLM 5.2 su circa 25 GB di RAM tenendo in memoria i componenti densi e streammando gli esperti dal disco. Quella strada paga in velocità, quindi la scelta fra cluster e macchina singola dipende da quanti token al secondo servono, e le ricette misurate su hardware reale le abbiamo raccolte per DGX Spark.
Cosa misura CyberGym
CyberGym è un benchmark di UC Berkeley, descritto nel paper arXiv 2506.02548 (CyberGym: Evaluating AI Agents’ Real-World Cybersecurity Capabilities at Scale). Conta 1.507 istanze su 188 progetti, costruite a partire da vulnerabilità reali trovate da OSS-Fuzz e divulgate fra il 1 gennaio 2017 e il 21 aprile 2025.
Il compito non è trovare una vulnerabilità. È produrre un input che inneschi un bug noto, in un progetto C o C++, in modo rilevabile da un sanitizer: il benchmark riconosce 28 tipi distinti di crash.
Il benchmark ha quattro livelli di difficoltà, che si distinguono per quanto contesto viene dato all’agente. Sulla stessa coppia agente e modello, OpenHands con GPT-4.1, il paper riporta questi tassi di successo:
| Livello | Successo |
|---|---|
| Level 0 | 3,45% |
| Level 1 | 9,36% |
| Level 2 | 13,07% |
| Level 3 | 17,12% |
Cinque volte di differenza fra il livello con meno contesto e quello con più contesto, a modello invariato. Quando si legge un punteggio su CyberGym, il livello conta quanto il modello.
Sulla classifica pubblica di cybergym.io, il Level 1 raccoglie 50 voci. GLM-5.3 non compare, alla lettura del 18 agosto. Ci sono GLM-5.1 al 68,7%, GLM-5 al 43,2% e GLM-4.7 al 23,5%, tutte inviate da Zhipu AI usando Claude Code come harness. Il numero che Z.ai rivendica sta nel proprio annuncio, non nella leaderboard di chi mantiene il benchmark.
Il numero che serve a chi fa triage
Il paper di CyberGym riporta anche i risultati di una campagna di scoperta aperta: 759 crash post-patch su 60 progetti, di cui 35 ancora attivi sull’ultima versione, e alla fine 9 zero-day unici confermati dopo triage manuale.
Sono circa 84 crash grezzi per ogni zero-day confermato.
Chi valuta di mettere un modello a monte di una pipeline di ricerca vulnerabilità deve dimensionare quel rapporto, perché è lì che finisce il tempo delle persone. Il costo dell’inferenza è quello che si vede in fattura, il costo del triage è quello che si vede nel calendario del team.
La scala dell’exploitation, e quanto è allineata
Sopra la scoperta c’è l’exploitation, e lì i benchmark cambiano natura. ExploitBench descrive il problema come “a ladder of 16 capability flags arranged in five tiers, ordered by impact”, applicata a 41 bug del motore V8, con un budget di 300 turni. I flag hanno nomi che descrivono passaggi reali di una catena: crash, addrof, fakeobj, caged_read, caged_write, infoleak.
Il dato che va letto con attenzione è un altro. Il paper misura quanto la cattura di una flag corrisponda all’uso della vulnerabilità che il task intendeva, e riporta un allineamento che varia dal 36,4% all’83,1% a seconda del modello. Nel caso peggiore, quasi due catture su tre passano da un bug diverso da quello previsto.
Per un benchmark è rumore da correggere. Per chi legge il risultato come misura di capacità offensiva, è la differenza fra “ha sfruttato quella vulnerabilità” e “ha trovato una strada qualsiasi verso la flag”.
Su ExploitGym, 869 task fra userspace, V8 e kernel Linux, i numeri che Z.ai pubblica danno GLM-5.3 a 105 task risolti con budget di due ore, contro i 29 di GLM-5.2. Nella stessa tabella compaiono però GPT-5.6 Sol a 216 e Fable 5 a 181. Il salto rispetto alla versione precedente è reale, il primato no.
Il ledger delle divulgazioni
L’annuncio rimanda a un registro pubblico su cvd.z.ai, che alla lettura del 18 agosto conta 2.436 finding, di cui 53 divulgati e 2.383 ancora sotto embargo, con 1.097 fra critical e high su 269 progetti open source.
Il registro riporta anche chi ha segnalato cosa, ed è un elenco multi-parte: Clouditera Security con 1.364 finding, cioè il 56%, il laboratorio NASP dell’Università Tsinghua con 325, il laboratorio AOSP dell’Università Nankai con 212, nsfocus con 205. Sono numeri di un programma di divulgazione coordinata, non di un modello.
Cosa si può fare oggi
Finché i pesi non escono, GLM-5.3 si usa via API, e questo esclude gli scenari in cui il codice non può uscire dal perimetro. È la differenza che conta di più per un CISO fra un modello a pesi aperti e uno accessibile solo come servizio, e in questo momento GLM-5.3 sta nella seconda categoria.
Due dettagli operativi dalla documentazione. Su GLM-5.3 il thinking non si può disattivare: thinking.type accetta il solo valore enabled. E reasoning_effort accetta tre valori, low, high e max, mentre lo schema OpenAPI pubblicato ne elenca sette: quattro valori passano la validazione dello schema e vengono rifiutati dal modello. Chi migra da una configurazione che spegneva il ragionamento riscrive la chiamata prima di cambiare l’ID del modello.
Il contesto da 1M token permette di tenere in una sola sessione una base di codice intera invece di frammenti.
Cosa ne pensiamo
Il salto su ExploitGym, da 29 a 105 task risolti, viene dal solo post-training su una base che non è cambiata. Dice che su questi compiti c’è ancora spazio senza toccare l’architettura.
Per chi lavora in sicurezza il modo di leggere questi annunci sta in tre domande, e valgono per qualunque fornitore. Cosa misura esattamente il benchmark, perché innescare un bug noto e trovarne uno nuovo sono compiti diversi e CyberGym misura il primo. A quale livello di contesto è misurato, visto che sullo stesso modello si passa dal 3,45% al 17,12%. E chi ha fatto la misura, perché un numero nell’annuncio del fornitore e un numero nella leaderboard del benchmark hanno un peso diverso.
Sul lavoro quotidiano il rapporto da tenere a mente resta quello del paper di CyberGym: 759 crash per 9 zero-day. Un modello che alza la produzione di candidati sposta il collo di bottiglia sul triage, e quel collo di bottiglia è fatto di ore di persone competenti. Chi introduce questi strumenti senza dimensionare la coda di verifica ottiene più segnalazioni, non più sicurezza.
Questa classe di modelli cambia quattro cose concrete per chi costruisce un agente di sicurezza come CyberAgent, e sono tutte leggibili nei numeri di sopra.
Il contesto vale più della taglia. Il salto dal 3,45% al 17,12% su CyberGym arriva a modello invariato, cambiando solo quanto l’agente sa del bersaglio. Un agente che presidia una superficie in continuo ha proprio quello che al benchmark manca: l’inventario dei servizi esposti, le versioni, la topologia e le verifiche precedenti. La finestra da 1M token permette di tenerli in una sola sessione invece che a frammenti, e su quel dislivello si gioca la differenza fra un candidato plausibile e uno verificato nel sistema reale.
Il costo per inferenza non segue i parametri totali. In un MoE da 753 miliardi sono attivi 8 esperti su 256 per token, quindi il conto di una scansione continua si calcola sui parametri attivi. È la condizione che rende sostenibile eseguire molte verifiche al giorno invece di una campagna al trimestre.
I pesi aperti spostano il perimetro. GLM-5.2 sta su HuggingFace con licenza MIT, e per GLM-5.3 Z.ai promette lo stesso entro fine agosto. Un modello che si esegue dentro l’infrastruttura del cliente permette di analizzare configurazioni, codice e finding senza che escano, che è il vincolo con cui si scontra ogni analisi via endpoint remoto.
La capacità si aggiorna senza riscrivere l’agente. Il salto su ExploitGym viene dal solo post-training, con la stessa base. Chi tiene il modello dietro un’interfaccia, come descrivevamo parlando di forme da dare a un ciclo, eredita questi miglioramenti cambiando una configurazione, e conserva la parte che non si aggiorna da sola: la validazione, la riproducibilità di un finding e le evidenze che servono a un audit.