Il rapporto 2026 di Azul sul divario nelle vulnerabilità dell’IA rileva che le aziende applicano le patch in ritardo rispetto alle minacce dell’IA

Il Rapporto 2026 sul divario nelle vulnerabilità dell’IA di Azul rileva una discrepanza tra la velocità che i responsabili della sicurezza attribuiscono agli aggressori dotati di IA e il tempo necessario alle loro organizzazioni per distribuire le correzioni. In un sondaggio condotto su 300 responsabili della sicurezza statunitensi, il 69% ha dichiarato che gli aggressori potrebbero creare un exploit funzionante entro tre giorni, mentre il 44% ha affermato che la propria organizzazione impiega quattro giorni o più per applicare una patch a una vulnerabilità critica in produzione.

Il dato più significativo del rapporto riguarda l’esperienza che gli intervistati associano a questi ritardi: l’85% ha segnalato un incidente, un sospetto incidente o un quasi incidente attribuibile alla lentezza nell’applicazione delle patch. Questa cifra descrive le esperienze riferite dagli intervistati, non un tasso di violazioni verificato in modo indipendente, e non dimostra che quegli eventi siano stati causati dall’IA.

La ricerca, commissionata da Azul e condotta da Censuswide, si concentra su organizzazioni che utilizzano Java in misura significativa. Il messaggio più ampio è di natura operativa: individuare una vulnerabilità è solo il primo passo. Una correzione deve superare i test, raggiungere i sistemi interessati e ridurre l’esposizione in tutto il parco, che potrebbe non essere interamente visibile ai team.

Due orologi fuori sincrono

Il sondaggio distingue le aspettative dei responsabili sui tempi degli aggressori dalle capacità delle loro organizzazioni di distribuire le correzioni:

• Il 69% ritiene che gli aggressori dotati di IA possano creare un exploit in tre giorni o meno; il 22% pensa che possano farlo in meno di 24 ore.
• Il 56% afferma di poter distribuire una patch critica in produzione entro tre giorni: il 13% in meno di 24 ore e il 43% in uno o tre giorni.
• Il 44% impiega più tempo: il 32% ha bisogno di quattro-sei giorni e il 12% di un periodo ancora più lungo.

Questi dati rappresentano la distribuzione delle risposte al sondaggio, non misurazioni di aggressori che prendono di mira specifiche organizzazioni, sfruttando le stesse vulnerabilità. La differenza giustifica le preoccupazioni riguardo alla preparazione, ma non va interpretata come una finestra di esposizione precisa di tre giorni per ogni azienda.

La stessa disparità emerge considerando la soglia di un giorno: il 22% si aspetta che gli aggressori riescano a muoversi così rapidamente, contro il 13% che afferma che la propria organizzazione può distribuire una correzione entro tale finestra. Nel frattempo, il 59% riconosce una maggiore esposizione dovuta agli strumenti di attacco basati sull’IA, ma non ha modificato il proprio livello di sicurezza.

I test sono una delle cause principali dei ritardi

Per il 58% delle organizzazioni intervistate, i test degli aggiornamenti del runtime Java aggiungono almeno quattro giorni al ciclo di applicazione delle patch. Il dato comprende il 36% che segnala da quattro a sei giorni e il 22% che indica una settimana o più. Un altro 33% riferisce da uno a tre giorni e il 9% meno di 24 ore. Nessun intervistato ha dichiarato di aver saltato i test.

Le modifiche al runtime possono influire su molte applicazioni, quindi i test hanno una funzione pratica: un aggiornamento di sicurezza che interrompe un servizio critico crea un ulteriore problema operativo. Secondo il rapporto, l’ambito degli aggiornamenti contribuisce a questo carico, perché le versioni trimestrali complete di OpenJDK possono includere modifiche non legate alla sicurezza insieme alle correzioni delle vulnerabilità.

Separatamente, Azul ha valutato 26 aggiornamenti trimestrali di OpenJDK nell’arco di oltre sei anni e ne ha classificati sei come causa di una regressione grave. La cifra del 23% è la valutazione del fornitore sulle versioni, non una stima basata su un sondaggio della frequenza con cui l’applicazione di un singolo cliente potrebbe smettere di funzionare.

Tra i principali ostacoli segnalati all’applicazione più rapida delle patch, il 44% cita test approfonditi, il 40% la complessità o l’età dei sistemi interessati e il 36% la scarsa visibilità sulle vulnerabilità note. Il 25% indica i ritardi dei fornitori nel rilasciare le patch. Il quadro mostra che gran parte delle difficoltà di correzione si annida nei processi di distribuzione interni all’azienda.

Le segnalazioni di incidenti e le lacune nell’inventario vanno interpretate diversamente

Il 55% segnala un incidente confermato attribuibile alla lentezza nell’applicazione delle patch e il 53% un quasi incidente. Gli intervistati potevano selezionare più risposte, quindi queste percentuali si sovrappongono e non vanno sommate. Il dato complessivo dell’85% riportato nel titolo comprende anche i sospetti incidenti.

Il sondaggio non dimostra che tutti quegli eventi riguardassero vulnerabilità Java. I partecipanti lavorano in organizzazioni che utilizzano Java in misura significativa, ma la ricerca include sia domande sull’applicazione delle patch al software in generale, sia domande specifiche sui runtime Java.

Un’altra difficoltà riguarda l’inventario. Solo il 19% afferma che almeno il 90% del parco di runtime Java in produzione utilizza il livello più recente di patch di sicurezza. Ciò significa che l’81% è al di sotto di quella soglia, non che l’81% non disponga di runtime aggiornati. Circa un’organizzazione su cinque dichiara che metà o meno del proprio parco è aggiornato.

Separatamente, il 51% ammette di avere una visibilità parziale o limitata sui runtime Java critici, compresi quelli incorporati, legacy e non gestiti. Individuare un runtime vulnerabile all’interno di un’applicazione pacchettizzata o di un container può essere più difficile che identificare un’installazione gestita centralmente. Una patch non può ridurre l’esposizione su un sistema che il processo di distribuzione non raggiunge mai.

Il contributo della tecnologia di Azul alla discussione

L’offerta di aggiornamenti di sicurezza di Azul limita determinate release alle sole correzioni di sicurezza su una versione di OpenJDK già stabilizzata. L’azienda fornisce aggiornamenti trimestrali, mensili mirati e fuori ciclo, con l’obiettivo di ridurre la quantità di modifiche non correlate che le aziende devono valutare quando distribuiscono una correzione urgente.

Si tratta di un intervento tecnico più circoscritto rispetto all’eliminazione della necessità di gestire il controllo delle modifiche. Limitare le modifiche al codice può ridurre l’ambito della convalida, ma restano importanti i controlli specifici per ogni applicazione, la responsabilità della distribuzione e la preparazione al ripristino della versione precedente. Azul è lo sponsor del rapporto e vende prodotti che affrontano i problemi da esso misurati.

Gli strumenti di inventario Java e di gestione delle vulnerabilità dell’azienda affrontano l’altro versante del flusso di lavoro: identificare ambienti di esecuzione, versioni ed esposizione, in modo da poter ricondurre una nuova segnalazione ai sistemi interessati. Il rapporto non presenta un confronto controllato che dimostri in quale misura le organizzazioni intervistate migliorerebbero adottando tali prodotti.

«La nostra ricerca mostra che i responsabili della sicurezza comprendono la minaccia: la consapevolezza non è più il problema, lo è l’esecuzione», ha dichiarato Scott Sellers, cofondatore e CEO di Azul.

Trasformare l’intenzione di applicare le patch in un processo misurabile

Per il prossimo anno, il 32% indica nell’applicazione più rapida e frequente delle patch la strategia principale per ridurre l’esposizione, mentre il 26% punta su un inventario migliore di software e ambienti di esecuzione. Un altro 17% dà priorità al rilevamento e alla risposta anziché all’applicazione più rapida delle patch.

La ricerca suggerisce di monitorare l’intero percorso dalla segnalazione alla correzione: quali sistemi sono interessati, chi ne è responsabile, quali test sono necessari e se la correzione è effettivamente arrivata in produzione. Una scadenza è utile solo se i team possono verificare il completamento dell’intervento nell’intero ambiente interessato.

I risultati relativi agli Stati Uniti si basano su un’indagine sul campo condotta dal 3 al 7 agosto 2026 tra responsabili della sicurezza di organizzazioni con almeno 1.000 dipendenti e un uso significativo di Java/JVM in produzione. Si tratta di risposte autodichiarate provenienti da una popolazione definita, non di un censimento delle aziende né di una misurazione diretta dello sviluppo di exploit.

Il testo completo del Rapporto 2026 sul divario nelle vulnerabilità dell’IA illustra i risultati e la metodologia. La conclusione più chiara è che la rapidità nell’applicazione delle patch e la visibilità sugli ambienti di esecuzione devono migliorare insieme: una correzione rapida ha un’utilità limitata se l’organizzazione non è in grado di individuare ogni distribuzione interessata o di confermare che l’aggiornamento l’abbia raggiunta.