A novembre 2026 OpenAI ha presentato GPT-6 Cyber, un modello per la ricerca di vulnerabilità di sicurezza. La novità non è tanto la tecnica quanto la scala: nel kernel Linux attuale gli agenti hanno trovato circa 1.700 errori confermati, e ogni scoperta ha un prezzo. Per le aziende senza un proprio reparto di sviluppo, la situazione dipende da quanto rapidamente le correzioni arrivano sui dispositivi.
In primavera Anthropic ha annunciato un modello non pubblicato che avrebbe trovato migliaia di vulnerabilità finora sconosciute in sistemi operativi e browser. Poco dopo è arrivato Gemini 4 Carbon di Google, con valori nettamente migliori nei benchmark sugli exploit. Con l'annuncio di OpenAI, un'analisi di un intero kernel si può quantificare in costi e risultati.
Chi trova errori a un costo così basso genera inevitabilmente molte correzioni. Server, firewall, sistemi NAS e telecamere funzionano quasi tutti con Linux, e nella maggior parte delle aziende il kernel lo mantiene qualcun altro.
GPT-6 Cyber in sintesi
GPT-6 Cyber è una variante specializzata di GPT-6 Astra per attività di sicurezza autorizzate. Il modello cerca vulnerabilità, costruisce exploit adatti e propone correzioni. Nella Model Card OpenAI colloca le capacità cyber al livello più alto del proprio Preparedness Framework. Nel benchmark sugli exploit ExploitGym risolve circa il 48 % dei compiti, il modello di base circa il 42 %.
I benchmark più vecchi possono risultare gonfiati dai dati di addestramento, lo sfruttamento affidabile di vulnerabilità appena pubblicate resta difficile e i bersagli completamente protetti hanno resistito. Il modello indica una direzione chiara, ma non risolve ogni bersaglio.
L'accesso è inizialmente limitato a clienti selezionati e verificati. Avviene tramite API e Codex, con verifica dell'identità, autenticazione a più fattori e indirizzi IP autorizzati. OpenAI consiglia di utilizzare il modello in ambiente isolato e sotto supervisione umana. È annunciata un'estensione graduale, ma non c'è una data per il grande pubblico.
Errori nel kernel su larga scala
Il fulcro è un'analisi dell'attuale kernel Linux. Prima gli agenti hanno delimitato le aree rilevanti per la sicurezza, circa il 7 % del codice. Altri agenti vi hanno segnalato circa 2.300 punti sospetti, e in macchine virtuali isolate se ne sono potuti confermare circa 1.700. I test sono stati eseguiti su un Linux desktop non modificato con i consueti meccanismi di protezione, pensati per impedire agli aggressori di indovinare gli indirizzi di memoria.
Dagli errori confermati sono nate circa 1.200 escalation locali dei privilegi funzionanti, in cui un semplice account diventa amministratore. Dietro ci sono circa 950 patch separate. Centinaia di scoperte portano quindi a centinaia di correzioni. I maintainer del kernel hanno reagito rapidamente: entro dieci giorni oltre 100 escalation dei privilegi erano corrette o avevano patch in preparazione, e circa 300 altre erano in discussione pubblica.
Anche il prezzo è una novità. L'analisi è costata circa 1,2 milioni di dollari USA in costi API, grosso modo 1.300 dollari USA per risultato. Una scansione precedente in estate era arrivata a circa 170 escalation dei privilegi per poco più di 500.000 dollari USA; la nuova analisi fornisce un multiplo delle scoperte a circa il doppio dei costi. La ricerca di vulnerabilità diventa così una voce di costo pianificabile, paragonabile al tempo di calcolo nel cloud. In Firefox il modello ha inoltre trovato circa 80 gravi vulnerabilità finora sconosciute, che Mozilla ha corretto.
Centinaia di fix e i cicli di aggiornamento
Una scoperta da sola non protegge nessuno. Solo il fix nel kernel e poi la sua installazione sul dispositivo cambiano la situazione. Il numero di identificativi CVE per release del kernel cresce fortemente, con circa 40 milioni di righe di codice. Molti riguardano errori a bassa priorità, ma il ritmo con cui servono aggiornamenti di manutenzione aumenta in modo sensibile.
Il periodo critico è quello tra la pubblicazione del fix e l'installazione dell'aggiornamento. Non appena una patch è pubblica, mostra agli aggressori dove si trovava l'errore. Un modello aperto ha trasformato fix di Firefox noti ma non ancora distribuiti in attacchi funzionanti per circa 1.000 dollari USA per versione, anche se solo per leggere file su un Ubuntu standard. Ogni fix pubblico è quindi un progetto di costruzione per gli aggressori.
La risorsa scarsa non è più la scoperta degli errori, ma l'installazione tempestiva delle correzioni.
Un'escalation locale dei privilegi richiede un primo accesso, ad esempio una password rubata, una webshell o l'evasione da un container. Chi ce l'ha arriva fino a root con una simile vulnerabilità. Per questo gli errori locali del kernel contano anche sui server raggiungibili solo via web. Non ogni scoperta è sfruttabile e non ogni server è a rischio. Ma il secondo ostacolo dopo la prima intrusione si assottiglia.
Nella pratica quotidiana significa non trattare più gli aggiornamenti come un progetto trimestrale. Un ritmo fisso con brevi finestre di riavvio, ad esempio mensile e immediato per le vulnerabilità critiche, toglie alla singola segnalazione il suo effetto allarmante. Chi riavvia comunque regolarmente non deve, per un fix del kernel, mettere insieme prima approvazioni, finestre temporali e responsabili.
Le patch del kernel dei produttori
Un fix del kernel compie un lungo percorso. Compare prima nel ramo principale, viene ripreso nei rami a lungo termine e arriva nei kernel delle distribuzioni. Per i dispositivi si aggiungono kernel del produttore, build del firmware, approvazione e distribuzione. Solo allora l'azienda può installarlo.
A seconda del gruppo di dispositivi, la situazione è molto diversa. I server standard con una distribuzione mantenuta ricevono gli aggiornamenti del kernel di solito entro giorni o settimane. Con il live patching la finestra temporale per le vulnerabilità critiche si può accorciare ulteriormente, ma il riavvio resta la via più sicura.
Per le appliance come firewall, sistemi NAS e router è il produttore a dettare il ritmo. La finestra di aggiornamento fa parte della manutenzione del prodotto e l'azienda può influenzarla a malapena. La situazione peggiore riguarda i dispositivi embedded e IoT. Lì girano spesso kernel del produttore che sono indietro di molti mesi o di diverse versioni rispetto al ramo principale, e alcuni prodotti non ricevono mai fix del kernel.
Tre domande a produttori e fornitori fanno chiarezza. Quanti giorni dopo il fix upstream esce un aggiornamento? Quale linea di kernel c'è nel dispositivo? E fino a quando vale il supporto?
Cosa fanno le PMI con le patch in ritardo
All'inizio c'è un semplice inventario. Linux non si trova solo nei server, ma anche in router, NAS, telecamere, stampanti, firewall e sistemi di controllo. Per ogni dispositivo bastano la versione del kernel e del firmware e il nome del produttore.
Poi si stabiliscono le priorità. Che cosa è raggiungibile da Internet, che cosa elabora credenziali di accesso, che cosa offre accesso amministrativo? I dispositivi con più risposte affermative vengono per primi. Una correzione mancante si può compensare in parte con l'isolamento:
- Non rendere pubblicamente raggiungibili le interfacce di amministrazione, accesso solo tramite VPN con autenticazione a più fattori.
- Collocare i dispositivi in segmenti di rete propri, così che un dispositivo compromesso non apra l'intera rete.
- Ridurre al minimo i privilegi: nessun account amministratore condiviso, account di servizio separati, container con privilegi limitati.
- Monitorare i log, affinché accessi insoliti e cambi di privilegi saltino all'occhio.
La stessa OpenAI consiglia, nell'uso del modello, una difesa a più livelli e l'isolamento, ad esempio con Firecracker o gVisor. Questo vale per ogni azienda: un errore nel kernel non deve aprire automaticamente tutto il resto.
Cosa possono fare le PMI se il produttore fornisce le patch del kernel solo mesi dopo?
Una seconda leva è il contratto. Termini per le patch e fine del supporto vanno inseriti nei contratti di fornitura e di manutenzione, e le finestre di riavvio si possono concordare in anticipo. Chi rientra nella NIS2 dovrebbe estendere la gestione delle vulnerabilità anche ai fornitori. I fix critici vanno installati sui dispositivi entro pochi giorni, non nel trimestre successivo.
Anche il proprio sito web fa parte dell'inventario, perché è la parte che gli aggressori vedono per prima. Un controllo del sito web, che da qualche tempo include automaticamente anche controlli di sicurezza aggiuntivi, mostra che cosa è visibile dall'esterno e dove esistono vulnerabilità.
Benchmark a cadenza settimanale
La curva dei modelli di punta sale rapidamente. Gemini 4 Carbon è arrivato circa quattro settimane dopo il predecessore Argon e raggiunge in ExploitGym circa il 55 %, rispetto a circa il 42 % di Argon. In primavera Anthropic ha trattenuto il suo modello, perché non doveva diventare disponibile per tutti. La linea è simile per tutti i grandi fornitori: il modello più potente resta inizialmente in una cerchia ristretta.
I benchmark non sono la stessa cosa della pratica. Per la pianificazione contano direzione e velocità, non la singola percentuale. La vera notizia è che le distanze tra le generazioni di modelli si riducono a settimane o mesi. Ciò che in primavera, con migliaia di vulnerabilità trovate, era ancora un'eccezione, oggi sembra un presagio.
IA open source e distillazione
Nell'IA la conoscenza scende verso il basso. Nella distillazione un modello grande, l'insegnante, genera risposte e percorsi di soluzione, e un modello più piccolo, lo studente, impara da essi. Il risultato è spesso molto più piccolo e più economico, senza perdere tutte le capacità. Per le PMI è il punto decisivo: ciò che oggi gira nei data center scivola nel giro di pochi mesi su hardware che entra in un armadio server.
Modelli aperti come GLM-5.2 e DeepSeek V4-Pro sono, nelle capacità cyber, indietro di 4-7 mesi rispetto ai migliori modelli chiusi. Nel 2025 erano ancora 6-10 mesi. In media su tutte le capacità il distacco è di circa 4 mesi.
Per i modelli ad accesso limitato come GPT-6 Cyber ciò significa che la protezione dell'accesso dà ai difensori un vantaggio temporaneo. I pesi aperti, una volta pubblicati, non si possono né ritirare né sorvegliare. I mesi fino al recupero sono quindi la finestra per la protezione di base, aggiornamenti ordinati e una difesa supportata dall'IA. Allo stesso tempo i modelli aperti sono utili anche a ricercatori e difensori, perché gli strumenti di verifica non nascono solo dalla parte degli aggressori.
L'IA locale come risposta
I modelli di punta sono ad accesso limitato, verificati e sorvegliati. Chi li usa per attività di sicurezza trasmette codice sorgente, configurazioni e log a un fornitore che osserva le azioni. Un'elaborazione protetta senza visibilità da parte del fornitore esiste solo per i clienti con Zero Data Retention. Per la maggior parte delle PMI non è un'opzione realistica.
Un'alternativa chiara è l'IA locale con modelli aperti su hardware proprio. I dati restano in azienda e non c'è dipendenza da prezzi, regole di accesso o da uno spegnimento del servizio. È anche un vantaggio strategico, perché chi mantiene conoscenze e strumenti all'interno della propria azienda reagisce con più calma agli annunci dei singoli fornitori. Compiti tipici sono l'analisi dei log, la revisione delle proprie configurazioni, la sintesi degli avvisi di sicurezza e la documentazione.
I modelli eseguibili in locale sono sì nettamente indietro rispetto ai migliori modelli cloud, e nella ricerca di zero-day su larga scala questo è uno svantaggio. Per il lavoro quotidiano in azienda spesso bastano, ed è proprio lì che si decide la sicurezza dei dati.
Anche le installazioni locali richiedono disciplina. Le interfacce non vanno esposte su Internet, i modelli provengono da fonti affidabili e i privilegi degli agenti restano limitati, affinché contenuti esterni non possano introdurre comandi. Chi si avvicina all'IA offline trova qui un buon punto di partenza.
Conclusione
La ricerca di errori con gli agenti è economica, rapida e scalabile. Il campo d'azione non sta quindi nel trovare, ma nell'installare. Chi conosce i propri dispositivi, concorda le scadenze e prepara l'isolamento non viene travolto da centinaia di fix del kernel. E chi tiene dati e strumenti all'interno dell'azienda resta in grado di agire anche quando i prossimi modelli saranno ancora più veloci.
My name is Klaus Meffert. I have a doctorate in computer science and have been working professionally and practically with information technology for over 30 years. I also work as an expert in IT & data protection. I achieve my results by looking at technology and law. This seems absolutely essential to me when it comes to digital data protection. My company, IT Logic GmbH, also offers consulting and development of optimized and secure AI solutions.
