La scoperta di vulnerabilità, per decenni un processo manuale e lento, è diventata industriale. Il National Cyber Security Centre britannico lo ha detto esplicitamente nel suo post “Preparing for a ‘vulnerability patch wave’”: l’AI sta dissotterrando decenni di debito tecnico e il settore della sicurezza deve prepararsi a gestire un volume di patch mai visto. Il patch tsunami sicurezza AI non è una metafora, è una stima operativa.

Il problema con l’avviso del NCSC non è che abbia torto. È che mette a fuoco la parte sbagliata del problema.

Il debito tecnico ha trovato il suo esattore

Per anni il codice legacy è rimasto nei sistemi di produzione con le sue vulnerabilità sepolte, non per sciatteria ma per calcolo: trovarle richiedeva audit manuali costosi, e il debito rimaneva silenzioso. I sistemi vecchi non venivano attaccati perché attaccarli richiedeva quasi le stesse competenze che servivano per difenderli.

L’AI ha cambiato questo equilibrio. Strumenti di analisi statica potenziati da modelli linguistici possono scansionare milioni di righe di codice in ore, trovare pattern di vulnerabilità noti, correlare comportamenti di librerie non mantenute e produrre analisi di exploit che fino a ieri richiedevano un laboratorio di sicurezza dedicato. Come segnala il NCSC, questo processo si applica al debito tecnico “at scale and at pace across the technology ecosystem.”

Il debito tecnico ha finalmente un creditore con un processo automatizzato.

Lo stesso strumento, da entrambi i lati

Qui c’è il punto che l’avviso del NCSC tocca ma non sviluppa. L’AI che trova vulnerabilità per i difensori è la stessa disponibile agli attaccanti. Non è una capacità riservata ai centri di sicurezza statali o ai vendor con bilanci dedicati: chiunque abbia accesso a un modello specializzato nell’analisi del codice può condurre una ricognizione su codebase pubblici, dipendenze open source, API esposte.

Le vulnerabilità non vengono scoperte in modo simmetrico. Un team di difesa che trova un bug lo valuta, lo segnala al vendor, aspetta la patch, la testa, la deploya. Un attaccante che trova la stessa vulnerabilità in autonomia non segue nessuno di questi passi.

I numeri mostrano l’entità dell’asimmetria. Secondo i dati di CyberMindr sul 2025, gli attaccanti sfruttano una vulnerabilità entro 4,5 giorni dalla pubblicazione di un proof-of-concept. Secondo Infosecurity Magazine, le aziende impiegano in media tra i 100 e i 120 giorni per patchare. Il differenziale non è di giorni: è di due ordini di grandezza.

Quando l’AI accelera la scoperta di vulnerabilità, questo differenziale non si riduce. Peggiora, perché aumentano le vulnerabilità ma non la capacità dei team di tenerle sotto controllo.

Patch tsunami sicurezza AI: cosa cambia per i team di sviluppo

L’ondata non colpisce in modo uniforme. Alcune parti di ogni sistema sono molto più esposte di altre.

I tre vettori più a rischio sono le dipendenze di terze parti (librerie npm, PyPI, Maven mai revisionate), le immagini container base usate nelle pipeline CI/CD e le API pubbliche che poggiano su codice legacy. Tutti e tre sono analizzabili automaticamente da chiunque disponga di un tool di scanning moderno.

Se il tuo sistema dipende da librerie open source che non hanno un rilascio da 18 mesi, o usa immagini Docker base che non aggiorni da due trimestri, la superficie di attacco esposta all’analisi AI non è teorica. È misurabile oggi.

La risposta operativa non è aumentare la frequenza dei rilasci di patch. È sapere cosa gira in produzione prima di ricevere una notifica di CVE.

Il take di TechMonk: il collo di bottiglia è il processo, non la tecnologia

L’NCSC consiglia di “prepare to patch quickly, more often, and at scale.” È un consiglio tecnicamente corretto che la maggior parte delle organizzazioni non può seguire, non perché non voglia ma perché non ha l’infrastruttura di processo per farlo.

Un team che domani mattina riceve 30 CVE nel suo stack, alcune critiche, deve rispondere a una serie di domande per cui probabilmente non ha risposte pronte: quale vulnerabilità ha priorità rispetto alle altre? Chi gestisce il test di regressione? Quanto tempo serve per deployare una patch su tutti gli ambienti di produzione? Esiste una finestra di manutenzione concordata con i clienti? Chi approva un rollout di emergenza?

Senza queste risposte, la velocità di patching non è un problema di volontà o di strumenti. È un problema di governance, e nessun avviso governativo lo risolve.

La questione strutturale ha due strati. Il primo è l’automazione: DevSecOps esiste come termine da anni, ma pochissime organizzazioni hanno una pipeline che integra scanning delle dipendenze, testing automatico delle patch e rollout controllato senza intervento manuale pesante. Il secondo strato è la supply chain: il codice che scrivi è meno del 20% di quello che esegui in produzione. Dipendenze, container, runtime, librerie di sistema sono tutti vettori, tutti analizzabili automaticamente.

Quello che manca nell’avviso del NCSC è la risposta a “da dove comincio”. La risposta pratica: inizia dall’attack surface esterna. Tutto ciò che è raggiungibile da internet senza autenticazione ha priorità assoluta, non perché il backend interno sia irrilevante, ma perché il tempo di risposta di un attaccante esterno si misura in ore.

Il secondo passo è smettere di trattare il patching come un’attività separata dallo sviluppo. Il team che deploya nuove feature dovrebbe possedere anche gli aggiornamenti delle dipendenze che girano in quelle feature. Quando il patching è isolato in un “team di sicurezza” che opera in modo indipendente, il solo overhead di coordinamento può valere settimane di quel differenziale medio di 100 giorni.

Come abbiamo discusso nel post sul codice AI come debito di sicurezza, il costo di un bug cresce in modo non lineare più tardi viene trovato nel ciclo di vita del software. Vale per le vulnerabilità nel codice che scrivi, vale ancora di più per quelle nel codice di terzi che incorpori senza rivederlo.

La buona notizia, quella che l’avviso del NCSC non enfatizza abbastanza, è che la stessa AI che trova i bug può aiutare a gestire il processo di risposta: prioritizzare le CVE per severity e contesto, generare test di regressione per le patch, identificare le parti del codebase più esposte. L’accelerazione è reale su entrambi i fronti. Chi la usa per organizzare la difesa ha almeno una possibilità di comprimere quel differenziale.

Conclusione

L’NCSC ha ragione a nominare l’onda. Ma “brace for the patch tsunami” è la risposta di chi presuppone che il problema sia la velocità di reazione. Il problema vero viene prima: sapere cosa gira in produzione, dove è esposto e chi è responsabile di tenerlo aggiornato.

Se questa settimana non riesci a rispondere con precisione a queste tre domande, non è il tsunami che dovrebbe preoccuparti. È che la barca fa già acqua.