apex-flash-1 di Cantina: il modello open-weights che cerca vulnerabilità a un costo ridotto
Cantina e Yeta rilasciano apex-flash-1, modello MIT da 321B che risolve 40 compiti di sicurezza su 60, vicino a Opus 5 High ma molto più economico.

Un modello open-weights da oltre 320 miliardi di parametri, addestrato per cercare vulnerabilità nel software, che costa una frazione di un modello commerciale di punta e ci va vicino nei test. È apex-flash-1, il modello rilasciato da Cantina Security insieme a Yeta Labs e pubblicato con licenza MIT su Hugging Face. Per chi si occupa di sicurezza informatica e di agenti AI, è una di quelle uscite che spostano un po’ gli equilibri tra modelli chiusi e aperti.
Il dato che ha fatto più rumore è semplice: su 60 compiti di sicurezza mai visti in fase di addestramento, il modello ne risolve 40, cioè il 66,7%. Il confronto è con Claude Opus 5 High, che arriva al 71,7%, ma con un costo per esecuzione molto più alto. Vediamo i numeri con calma, perché il contesto conta più del titolo.
Cos’è apex-flash-1 e come è fatto
Secondo la scheda ufficiale su Hugging Face, apex-flash-1 parte da GLM-5.3-Flash, il modello di Z.ai che usa un’architettura Mixture-of-Experts con circa 18 miliardi di parametri attivi su un totale di 321,3 miliardi. Cantina e Yeta lo hanno ottimizzato con apprendimento per rinforzo, in ambienti che somigliano a quelli di produzione e con l’harness dell’agente Codex.
Il modello è multimodale in ingresso, ma la valutazione riguarda solo compiti testuali: sulla capacità di lavorare con immagini e video, per ora, non ci sono misure.
Come è stato addestrato
Il team racconta di aver usato GRPO con LoRA di rango 256 e un addestramento selettivo a parametri pieni, su 150 compiti ricavati da 50 casi reali di vulnerabilità. Ogni caso è stato declinato in tre varianti: whitebox guidato, whitebox mirato e blackbox mirato. Nel set di addestramento pesano soprattutto i difetti di autorizzazione e identità, circa il 72%, seguiti dai bug contabili e numerici, intorno al 18%.
È un dettaglio importante: il modello non nasce come tuttofare, ma come specialista allenato su una famiglia precisa di errori.
I numeri del benchmark, letti con attenzione
La prova usa 60 compiti derivati da 20 casi di vulnerabilità tenuti fuori dall’addestramento. Secondo quanto riportato da MarkTechPost, apex-flash-1 risolve 40 compiti su 60 con un costo stimato di 2,38 dollari per esecuzione completa. Il modello di partenza, GLM-5.3-Flash, ne risolve 36 (60%) spendendo circa 4,56 dollari. Claude Opus 5 High ne risolve 43 (71,7%), ma con circa 74,68 dollari a esecuzione.
Tradotto in costo per compito risolto, si parla di circa 0,06 dollari contro 1,74: un rapporto di circa 31 volte.
Il confronto con il modello di base è forse il dato più interessante. Lo stesso scheletro, con un addestramento mirato, passa da 36 a 40 compiti e costa meno della metà. Non è una rivoluzione, ma mostra che la specializzazione per rinforzo su un dominio stretto paga, anche con poche centinaia di esempi.
Cosa non dicono i numeri
Sessanta compiti sono un campione piccolo, tratti da venti casi, e un singolo punteggio pass@1 non racconta la varianza tra esecuzioni. Le stime di costo dipendono poi dai prezzi e dall’infrastruttura usati dagli autori. Prima di trarre conclusioni definitive servono repliche indipendenti, e finora la fonte principale resta la documentazione degli stessi sviluppatori.
Perché conta per sicurezza e agenti AI
Cantina descrive apex-flash-1 come un lavoratore specializzato che opera sotto la direzione di un agente più grande: legge codice, usa strumenti, prova exploit e verifica gli effetti. È la logica dei sistemi multi-agente, in cui un modello costoso pianifica e uno più economico esegue il lavoro ripetitivo.
Se funziona, cambia l’economia della ricerca di vulnerabilità. Un team di sicurezza, o un singolo freelance che fa audit, può far girare molte più prove per lo stesso budget. Lo stesso vale per chi deve controllare codice generato da assistenti AI, un tema che abbiamo già affrontato parlando di slopsquatting e pacchetti inventati dagli assistenti di codice.
Il rovescio della medaglia è evidente, ed è il motivo per cui il tema è delicato.
Il rischio dual use
Un modello che trova bug a basso costo e con pesi liberi lo può usare chi difende, ma anche chi attacca. La stessa scheda su Hugging Face segnala l’esistenza di una versione sperimentale derivata con comportamento di rifiuto modificato, un elemento che riaccende il dibattito sui modelli aperti ad alta capacità offensiva.
Non è un caso isolato. Poche ore prima avevamo raccontato il report di Anthropic sugli exploit dei modelli open-weight costruiti proprio sulla famiglia GLM-5.3, e il quadro che emerge è coerente: la distanza tra modelli chiusi e aperti, sui compiti di cybersicurezza, si sta riducendo.
Per i difensori la risposta pratica è ragionare in termini di costo: se l’analisi automatica del codice diventa economica, conviene metterla in pipeline prima che lo faccia qualcun altro dall’esterno.
Open-weights contro modelli di frontiera: dove sta il vantaggio
Negli ultimi mesi il mercato dei modelli aperti si è mosso in fretta. Ne è un esempio il debutto del primo modello a pesi aperti di Reflection AI, che abbiamo seguito in questo approfondimento sulla sfida a DeepSeek e Qwen. apex-flash-1 si inserisce nello stesso filone, ma con un obiettivo molto più verticale.
Il vantaggio dei modelli di frontiera resta la generalità: Opus 5 High supera ancora apex-flash-1 sul benchmark, e su compiti diversi dalla sicurezza il divario sarebbe probabilmente più ampio. Il vantaggio dei modelli aperti è il controllo. Puoi eseguirli sulla tua infrastruttura, ispezionarli, ottimizzarli sui tuoi dati e non dipendere da un fornitore.
Ci sono però dei costi nascosti. La versione BF16 richiede circa 640 GB di memoria GPU, quindi non è un modello da portatile. Per molti professionisti il caso d’uso realistico sarà usarlo tramite un provider che lo ospita, non installarlo in locale.
Come potresti usarlo, in concreto
Se lavori con codice e sicurezza, ci sono tre scenari plausibili. Il primo è l’audit preliminare di un repository, con il modello che segnala sospetti da far verificare a un umano. Il secondo è la verifica automatica di patch e pull request nei casi di autorizzazione e logica di business, che sono proprio i difetti su cui è stato allenato. Il terzo è l’uso come sotto-agente, guidato da un modello più grande, nelle pipeline di sviluppo basate su agenti come quelle di Codex Cloud.
In tutti i casi vale la regola di sempre: l’output di un modello è un suggerimento, non una prova.
Cosa osservare nelle prossime settimane
Le cose da guardare sono tre. Prima di tutto, le repliche indipendenti del benchmark, che diranno se il 66,7% regge su compiti diversi da quelli scelti dagli autori. Poi la reazione della comunità della sicurezza alla variante con rifiuti modificati e alle eventuali politiche di distribuzione dei pesi. Infine i prezzi dei provider che decideranno di ospitarlo, perché è lì che il rapporto costo prestazioni si misura davvero.
Se fai SEO, sviluppo o consulenza tecnica e ti occupi di siti, plugin o app, tieni d’occhio questa categoria di strumenti: tra poco gli audit automatici di sicurezza potrebbero diventare una voce standard, a basso costo, nei flussi di lavoro quotidiani.
Conclusioni
apex-flash-1 non detronizza i modelli di frontiera, ma mostra una strada concreta: partire da un modello aperto, specializzarlo con rinforzo su un problema stretto e ottenere prestazioni vicine a quelle dei migliori a un costo molto più basso. Il dato va letto con prudenza, per il campione ridotto e perché arriva dagli stessi autori, ma la direzione è chiara.
Ora tocca a te: se lavori nel software, prova a verificare quanto costa oggi un’analisi di sicurezza automatica sul tuo codice e a confrontarla con quello che fai a mano. Seguici per i prossimi aggiornamenti sui modelli di sicurezza e sugli agenti AI.