Il Patch Tuesday di settembre 2026 ha un numero che attira immediatamente l’attenzione: 974 vulnerabilità pubblicate da Microsoft, secondo il conteggio complessivo della release. Rapid7 rileva che 723 riguardano Windows e che, includendo anche CVE non Microsoft presenti nel ciclo di aggiornamento, il totale delle vulnerabilità “sul tavolo” arriva a 999.
È facile fermarsi al record. Secondo me, però, il dato più importante è un altro: sta cambiando la velocità con cui scopriamo le vulnerabilità. E i processi con cui le aziende le valutano, testano e correggono rischiano di non cambiare altrettanto velocemente.
Non è solo un Patch Tuesday più grande
Microsoft aveva già avvertito che le release di sicurezza sarebbero diventate più corpose. A maggio, MSRC spiegava che il volume delle segnalazioni era in crescita da anni e che automazione e AI stavano permettendo a ricercatori e team interni di esaminare il software con una scala prima impraticabile.
La stessa Microsoft ha descritto il proprio sistema agentico multi-modello per la security research: a maggio aveva contribuito a individuare 16 nuove vulnerabilità nello stack di networking e autenticazione di Windows, comprese quattro vulnerabilità critiche di remote code execution.
Quindi il punto non è che improvvisamente il software sia diventato centinaia di volte più insicuro. Una parte del fenomeno è che stiamo diventando molto più bravi a trovare ciò che prima rimaneva nascosto.
L’AI abbassa il costo della vulnerability discovery
La vulnerability research tradizionale richiede competenze elevate, tempo e una grande quantità di lavoro manuale. L’AI non elimina il ricercatore, ma può aumentare enormemente la quantità di codice, configurazioni e percorsi di esecuzione che è possibile analizzare.
Microsoft parla esplicitamente di modelli avanzati capaci di ragionare sui code path con velocità e consistenza non raggiungibili tramite sola revisione manuale. Il risultato è positivo: più vulnerabilità vengono individuate e corrette prima che possano essere sfruttate.
Ma la stessa capacità non appartiene esclusivamente ai defender.
Se l’AI riduce il tempo necessario per trovare una vulnerabilità, comprenderla e sviluppare tecniche di exploitation, si riduce anche il valore del tempo a disposizione di chi deve difendere l’infrastruttura.
Il vero problema diventa il patch gap
Nelle aziende il percorso di una patch raramente è “esce oggi, installata oggi”. Prima bisogna capire quali sistemi sono esposti, valutare criticità e dipendenze, creare gruppi pilota, testare le applicazioni, rispettare maintenance window e infine distribuire l’aggiornamento.
È un processo corretto. Ma è stato progettato in un contesto in cui il ritmo della vulnerability discovery era diverso.
Il rischio è che si allarghi una nuova asimmetria: la ricerca delle vulnerabilità accelera, mentre il processo operativo di remediation resta sostanzialmente umano e sequenziale.
Nel Patch Tuesday di settembre ci sono inoltre due vulnerabilità Windows già sfruttate attivamente. È il promemoria più concreto del fatto che non tutte le patch possono aspettare il normale ciclo mensile di change management.
974 CVE non significano 974 aggiornamenti da installare
Qui serve una precisazione importante. Microsoft stessa sottolinea che il numero di CVE non coincide con il numero di pacchetti che un amministratore deve distribuire: molti aggiornamenti sono cumulativi o raggruppano più correzioni.
Il problema operativo non è quindi installare “974 patch”. È capire rapidamente quali vulnerabilità riguardano davvero il proprio ambiente e quali meritano priorità.
Ed è significativo che proprio a settembre Microsoft abbia esteso la pubblicazione di dichiarazioni VEX machine-readable a tutti i CVE assegnati da Microsoft. VEX serve a rendere più automatizzabile l’analisi dell’esposizione e a ridurre parte del lavoro manuale necessario per interpretare gli advisory.
Il patch management deve diventare risk-based
Se il numero delle vulnerabilità continuerà a crescere, trattarle tutte allo stesso modo diventerà semplicemente impossibile.
CVSS da solo non basta. Servono almeno contesto sull’asset, esposizione, exploitability reale, presenza di exploitation in the wild, identità coinvolte, compensating control e criticità del servizio.
Per chi gestisce endpoint Windows questo significa sfruttare realmente gli strumenti che negli ultimi anni abbiamo introdotto: deployment ring, Windows Update for Business, Autopatch, vulnerability management, EDR/XDR, inventory affidabile e automazione della remediation.
Non per “patchare tutto più velocemente” in maniera indiscriminata, ma per decidere più velocemente cosa deve essere patchato subito.
Automazione sì, ma anche capacità di fermarsi
La risposta non può essere distribuire automaticamente qualsiasi aggiornamento su qualsiasi macchina. Un aggiornamento problematico può avere un impatto operativo importante quanto una vulnerabilità.
Il modello più sostenibile è quello dei ring: un piccolo gruppo di validazione, una platea progressivamente più ampia, controllo della telemetria e possibilità di sospendere rapidamente il rollout.
In altre parole, se la discovery diventa machine-speed, anche il patching deve diventare più automatizzato, senza perdere governance e controllo.
La metrica che dovrebbe interessare davvero
Per anni abbiamo contato vulnerabilità aperte, patch installate e percentuali di compliance. Sono metriche utili, ma rischiano di descrivere il passato.
La domanda più importante potrebbe diventare: quanto tempo passa tra la disponibilità di una correzione critica e la sua applicazione sugli asset realmente esposti?
È il Mean Time to Remediate, ma letto in un contesto nuovo. Se un attaccante può passare dalla disclosure all’exploitation più velocemente, ridurre quel tempo diventa parte della superficie di difesa.
Il mio punto di vista
L’AI applicata alla vulnerability discovery è una buona notizia. Preferisco sapere che una vulnerabilità esiste e poterla correggere piuttosto che lasciarla nascosta per anni.
Ma c’è un effetto collaterale che secondo me stiamo sottovalutando: stiamo aumentando la velocità della security research più rapidamente della velocità dei processi IT aziendali.
Il prossimo salto nel vulnerability management non sarà quindi trovare più CVE. Quello sta già accadendo.
Sarà costruire organizzazioni capaci di trasformare migliaia di segnali in poche decisioni corrette, rapidamente e con il minor rischio operativo possibile.
Se l’AI porta la vulnerability discovery alla velocità delle macchine, non possiamo continuare a gestire la remediation con processi pensati per la velocità degli esseri umani.