Zero Day Clock: le vulnerabilità critiche sono sfruttate in appena 2 giorni

Il tempo disponibile per correggere le vulnerabilità si sta comprimendo più rapidamente del previsto. Il problema non è un’immaginaria “apocalisse causata dall’AI“, in grado di far emergere un numero tale di falle di sicurezza a elevata gravità da mettere in difficoltà aziende, sviluppatori e utenti finali. Il tema più importante ha a che fare con la crescente distanza tra disclosure pubblica, disponibilità delle patch e capacità operativa delle aziende di reagire prima che gli exploit entrino in circolazione.

Alcuni dati fotografano bene la situazione. IBM stima che circa il 40% dei data breach coinvolga vulnerabilità non corrette; Mandiant osserva finestre di sfruttamento sempre più ridotte; il progetto Zero Day Clock monitora invece il tempo che passa tra disclosure e disponibilità di exploit pubblici o attacchi osservati in rete. In molti casi si parla ormai di un paio di giorni!

Il patching tradizionale non regge più i ritmi di un tempo

Per anni molte aziende hanno lavorato con cicli relativamente prevedibili: scansione mensile, validazione interna, test e distribuzione durante le finestre di manutenzione. Quel modello oggi mostra limiti evidenti, soprattutto per i servizi esposti direttamente su Internet.

Firewall, VPN, appliance IAM (Identity and Access Management), reverse proxy, hypervisor e piattaforme edge rappresentano bersagli particolarmente appetibili. Quando emerge una vulnerabilità critica su questi componenti, gli attaccanti iniziano immediatamente ad analizzare patch diff, advisory e proof-of-concept. In pratica, la corsa allo sfruttamento di un problema di sicurezza parte spesso prima che molti team abbiano completato la fase di studio iniziale.

Mandiant sottolinea che diversi gruppi offensivi riescono a operare durante la finestra iniziale della disclosure, cioè quella fase in cui le organizzazioni stanno ancora cercando di capire esposizione reale, dipendenze e impatto operativo di ciascun aggiornamento.

L’aumento dei bollettini CVE non racconta tutta la storia

Il numero di CVE pubblicate continua a crescere. FIRST.org prevede anche per il 2026 volumi molto elevati rispetto agli anni precedenti ma interpretare questa crescita come la prova di un collasso imminente della sicurezza globale sarebbe fuorviante.

Una CVE non equivale automaticamente a un exploit affidabile: molte vulnerabilità richiedono accesso locale, configurazioni particolari oppure concatenazioni di più condizioni. Altre riguardano componenti non raggiungibili dall’esterno oppure funzioni mai utilizzate realmente nelle applicazioni (ad esempio da attivare su richieste e poco comuni).

Tuttavia, se il rumore aumenta molto più rapidamente rispetto alla capacita umana di analizzarlo, distinguere le vulnerabilità realmente sfruttabili – e quindi pericolose – diventa decisamente più complicato. È quanto sostiene Linus Torvalds che attacca frontalmente chi invia segnalazioni di sicurezza nel kernel Linux che sono la copia di altre segnalazioni già inviate in precedenza. È il risultato dell’ampio uso di modelli AI molto simili senza effettuare opportune verifiche.

AI offensiva e AI difensiva avanzano insieme

L’intelligenza artificiale accelera diverse attività offensive: analisi del codice, generazione di payload, studio delle patch, automazione del fuzzing e adattamento rapido dei proof-of-concept. Alcuni attori usano modelli generativi anche per creare campagne phishing più convincenti o velocizzare le attività di ricognizione.

La medesima tecnologia, tuttavia, aiuta anche chi difende. Gli strumenti di reachability analysis permettono di capire se una libreria vulnerabile sia davvero raggiungibile dal flusso esecutivo dell’applicazione. Sistemi EDR, SIEM e piattaforme di threat hunting integrano sempre più componenti AI per correlare eventi, ridurre il rumore e accelerare le analisi.

Una vulnerabilità critica perde gran parte del proprio impatto quando il sistema non è esposto direttamente, usa segmentazione rigorosa, autenticazione forte, allow-listing applicativo e monitoraggio comportamentale. Un server Linux vulnerabile non rappresenta automaticamente una compromissione totale dell’ambiente: se il servizio non e raggiungibile dall’esterno, se i movimenti laterali risultano limitati e se esistono controlli EDR efficaci, il rischio reale cambia drasticamente.

Negli ambienti business, la priorità non consiste nel patchare tutto immediatamente, ma nel ridurre la superficie attaccabile e concentrare gli sforzi sulle vulnerabilità realmente esposte.

Zero Day Clock mostra una tendenza precisa

Il progetto Zero Day Clock evidenzia un fenomeno ormai evidente anche nei report: il tempo medio tra disclosure pubblica e attività offensiva continua a diminuire. Il sito monitora disclosure recenti, exploit pubblici e finestre temporali di sfruttamento. Molte imprese, purtroppo, lavorano ancora con tempi pensati per un mercato software molto diverso da quello attuale.

Gli attaccanti automatizzano le scansioni della rete Internet, l’identificazione delle versioni dei software in uso e la diffusione degli exploit. Per difendersi è quindi necessario mantenere un inventario sempre aggiornato delle risorse digitali, stabilire in modo intelligente le priorità degli interventi e le strategie per poter isolare rapidamente i sistemi compromessi.

La narrativa apocalittica sull’AI rischia di distrarre dal problema reale: gran parte delle compromissioni continua a sfruttare credenziali deboli, segmentazione insufficiente, sistemi esposti e vulnerabilità note da anni. Molte intrusioni recenti non hanno richiesto tecniche futuristiche: in parecchi casi bastano ancora servizi RDP esposti, VPN obsolete, appliance non aggiornate o account senza autenticazione a due fattori.

Certo, l’AI rende alcune operazioni più veloci sia per gli attaccanti sia per i difensori ma il fattore decisivo resta operativo: sapere quali vulnerabilità contano davvero, intervenire rapidamente sugli asset critici e costruire più livelli di mitigazione prima che arrivi la prossima disclosure.