L’AI che scrive exploit e la manutenzione che nessuno fa

Perché la classificazione “Critical” di un modello OpenAI è, per una PMI italiana, soprattutto una questione di calendario degli aggiornamenti.

All’inizio di settembre OpenAI ha comunicato che Astra, il suo nuovo modello, ha raggiunto la soglia “Critical” per le capacità di cybersecurity prevista dal Preparedness Framework. È il primo modello dell’azienda a ricevere questa classificazione e può trovare vulnerabilità sconosciute e costruire exploit funzionanti con un intervento umano limitato.

La formula descrive una capacità reale ma rischia di orientare la discussione verso lo scenario più spettacolare e meno utile per chi deve proteggere una piccola o media impresa. Per molte PMI italiane, infatti, la conseguenza più immediata non consiste nella probabilità di essere scelte come bersaglio da un sistema capace di scoprire una vulnerabilità mai vista prima, ma nella riduzione del tempo che intercorre tra la pubblicazione di una vulnerabilità, la disponibilità di informazioni tecniche sufficienti a sfruttarla e la comparsa di attacchi automatizzati contro i sistemi rimasti esposti. Per una PMI, la rilevanza concreta di questa evoluzione riguarda soprattutto i processi di manutenzione e i tempi di applicazione degli aggiornamenti.

Che cosa è successo

Nel Preparedness Framework di OpenAI, “Critical” è una soglia riferita a capacità specifiche, ovvero alla possibilità che un modello sviluppi exploit zero-day funzionanti contro numerosi sistemi reali e protetti senza intervento umano, oppure esegua strategie di attacco nuove e complete da un obiettivo formulato ad alto livello. Per zero-day si intende una vulnerabilità non ancora conosciuta e per la quale può non esistere una correzione.

Secondo i risultati pubblicati da OpenAI, Astra ha ottenuto il 100 per cento nel test ExploitBench progettato per valutare la capacità di sviluppare exploit da vulnerabilità note. Su un insieme interno di venti vulnerabilità recenti e gravi del motore JavaScript V8, il modello ne ha individuate e utilizzate due fino a quel momento sconosciute. In valutazioni condotte da esperti ha inoltre costruito catene di exploit contro un browser e un sistema operativo protetti.

Questi risultati derivano in parte da test interni e devono essere considerati come evidenze pubblicate dal produttore e integrate da valutazioni esterne, non come una misurazione definitiva di ogni impiego reale. OpenAI precisa inoltre che le prestazioni descritte corrispondono a Daybreak Blue e non alla configurazione ordinaria. Daybreak è il programma attraverso il quale l’azienda consente a soggetti verificati di utilizzare capacità avanzate per attività di cybersecurity difensiva. OpenAI ha rallentato sviluppo e rilascio, rafforzato i controlli e previsto che le capacità cyber più avanzate siano inizialmente accessibili soltanto a verificatori selezionati, per poi essere estese a soggetti approvati che svolgono attività difensive.

Il rischio che una PMI ha già davanti

Nulla di questo significa che da domani un modello pubblico inizierà autonomamente ad attaccare le PMI italiane, né che ogni aggressore disporrà delle capacità mostrate nei test. Significa però che la produzione di codice offensivo e l’analisi delle vulnerabilità stanno diventando più rapide, economiche e automatizzabili. Per comprendere l’effetto su un’impresa occorre partire dalla sua superficie d’attacco reale che, nella maggior parte dei casi, non è costituita da sistemi particolarmente protetti e vulnerabilità sconosciute, ma da apparati VPN, firewall, server di posta, applicazioni web, dispositivi di rete e accessi remoti già individuabili da Internet, talvolta configurati male, non più supportati oppure aggiornati con ritardo.

Anche il dato dei 33.300 attacchi rilevati contro le PMI tra gennaio e aprile 2026 richiede questa distinzione. La ricerca Kaspersky alla quale il numero si riferisce non descrive 33.300 imprese italiane compromesse e nemmeno 33.300 attacchi basati su capacità paragonabili a quelle di Astra. Si tratta di rilevamenti effettuati a livello internazionale dalle soluzioni del fornitore, relativi a software dannosi o indesiderati camuffati da servizi di intelligenza artificiale noti. Il numero è quasi cinque volte quello osservato nello stesso periodo del 2025. ChatGPT, Claude e DeepSeek erano le esche più utilizzate. Il fenomeno è molto più ordinario di un attacco zero-day poiché l’utente crede di scaricare uno strumento AI e installa un trojan.

La rilevanza del dato sta proprio qui. L’intelligenza artificiale modifica le minacce sia quando rende un attaccante più capace, sia quando diventa un marchio credibile con il quale distribuire malware già esistente. In entrambi i casi la difesa dipende meno dalla capacità di prevedere il prossimo attacco eccezionale che dalla qualità delle attività ordinarie.

La finestra tra la patch e l’exploit

Quando un produttore pubblica un aggiornamento, la correzione può essere confrontata con la versione precedente per comprendere quale controllo sia stato aggiunto e ricostruire la vulnerabilità. La patch stessa può quindi offrire a un ricercatore, e anche a un attaccante, gli elementi per sviluppare un exploit.

La possibilità di ricostruire una vulnerabilità a partire dalla patch non è nuova ma modelli più capaci consentono di automatizzare una parte crescente dell’analisi e di ridurre il tempo necessario per trasformare un bollettino, una modifica al codice o una descrizione tecnica in una prova di sfruttamento. L’effetto non è l’eliminazione del lavoro umano ma la compressione della finestra nella quale chi difende può aggiornare i sistemi prima che lo sfruttamento diventi accessibile a un numero più ampio di soggetti.

Un ciclo di patching trimestrale presuppone implicitamente che una vulnerabilità possa restare aperta per settimane senza che il rischio cambi in modo sostanziale. Per un sistema esposto su Internet questo presupposto era già fragile mentre ora, con l’accelerazione dello sviluppo degli exploit, diventa difficilmente sostenibile. Ciò non significa applicare ogni aggiornamento in modo immediato e indiscriminato, perché una patch può interferire con applicazioni, dispositivi o processi produttivi e deve essere verificata. Significa distinguere la manutenzione ordinaria dalla gestione urgente delle vulnerabilità critiche, soprattutto quando riguardano sistemi esposti o risultano già sfruttate. Un calendario unico per tutti gli aggiornamenti non è più una procedura ma equivale alla rinuncia a stabilire delle priorità.

L’asimmetria tra chi attacca e chi difende

OpenAI tenta di governare la natura duale di queste capacità separando l’accesso ordinario da quello concesso a soggetti verificati per attività difensive. Daybreak utilizza controlli sull’identità, sicurezza degli account, monitoraggio, limitazioni sugli usi autorizzati e attestazioni legali. La logica è comprensibile, ossia consentire a chi difende di cercare e correggere vulnerabilità senza distribuire indistintamente le stesse capacità a chiunque voglia impiegarle in modo offensivo.

Questa asimmetria non garantisce che le capacità offensive rimangano confinate. Modelli diversi, tecniche pubblicate e strumenti tradizionali continuano a circolare e non serve una capacità al livello di Astra per sfruttare più rapidamente una vulnerabilità nota. Una PMI priva di un Security Operations Center, cioè di una struttura dedicata al monitoraggio e alla risposta, non può replicare mezzi e competenze di un grande operatore. Può però sapere quali sistemi espone, ricevere gli avvisi dei produttori, stabilire chi deve valutarli e pretendere che le correzioni urgenti non attendano la successiva visita del tecnico.

Cosa fare il prima possibile

Il primo passo è costruire un inventario attendibile degli asset raggiungibili da Internet, comprendendo il sito web, la VPN, il firewall, la posta elettronica, la teleassistenza, i pannelli di amministrazione e le applicazioni pubblicate. Per ciascuno devono essere noti prodotto, versione, responsabile, fornitore e stato del supporto. Un inventario esteso ma non aggiornato serve meno di un elenco essenziale verificato periodicamente.

Occorre poi formalizzare una cadenza che distingua manutenzione ordinaria, vulnerabilità critiche di sistemi esposti e vulnerabilità già sfruttate. A ogni categoria devono corrispondere un tempo massimo, una procedura per le eccezioni e un responsabile con nome e cognome. Se una patch viene rinviata, devono risultare la ragione, la misura temporanea e la data della nuova valutazione.

Sugli accessi remoti deve essere attivata l’autenticazione a più fattori, perché una password sottratta non consenta da sola l’ingresso nei sistemi aziendali. I servizi non necessari devono essere rimossi dall’esposizione pubblica e i prodotti fuori supporto devono avere un piano di dismissione, non una permanenza indefinita giustificata dal fatto che continuano a funzionare. Il supporto del produttore non è un dettaglio contrattuale ma la condizione che rende possibile ricevere una correzione quando viene scoperta una vulnerabilità.

Le due domande da fare al fornitore IT

Molti contratti di assistenza indicano ore comprese, fasce di supporto e costi straordinari, ma non entro quanto tempo debba essere applicata una patch critica. La prima clausola deve quindi definire tempi misurabili in base alla gravità, all’esposizione del sistema e all’esistenza di sfruttamento attivo; deve inoltre chiarire chi monitora gli avvisi, chi autorizza l’intervento e come vengono gestite le patch non immediatamente applicabili.

La seconda clausola dovrebbe disciplinare la reportistica prevedendo che, con una periodicità concordata, il fornitore consegni l’elenco degli asset gestiti, degli aggiornamenti applicati, di quelli non riusciti o rinviati, delle vulnerabilità ancora aperte e dei sistemi prossimi alla fine del supporto. Il report non deve essere un documento tecnico incomprensibile né una dichiarazione generica secondo cui “è tutto aggiornato” e deve invece consentire all’impresa di conoscere le eccezioni, le responsabilità e le scadenze sulle quali è necessario decidere.

La classificazione di Astra segna certamente un passaggio nelle capacità dei modelli di intelligenza artificiale applicati alla cybersecurity, ma per una PMI la risposta non consiste nell’acquistare subito un altro prodotto AI. Consiste nel verificare se un bollettino critico viene letto, da chi, entro quanto tempo produce un intervento e come l’impresa può sapere che quell’intervento è stato realmente eseguito. Quando il tempo necessario a costruire un exploit si riduce, la sicurezza dipende sempre più dal tempo necessario a prendere una decisione. E quel tempo, prima ancora che dalla tecnologia, dipende dall’organizzazione.

Fonti

• OpenAI, Path to Astra: critical capabilities and frontier safeguards, settembre 2026.
• OpenAI, GPT-6 Astra System Card, settembre 2026.
• OpenAI, Expanding Daybreak as the Cyber Defense Window Narrows, agosto 2026.
• AGI, Astra, il nuovo modello di OpenAI classificato “Critical”, settembre 2026.
• Kaspersky, AI hype as a trap: new threats targeting SMEs, giugno 2026.
• Confindustria e Generali, Rapporto Cyber Index PMI 2025, gennaio 2026.
• CISA, Internet Exposure Reduction Guidance, giugno 2025.
• ENISA, Cybersecurity for SMEs: Challenges and Recommendations, giugno 2021.