Trentasettemila vulnerabilità in sei mesi: il problema non è più scoprirle, è chiuderle in tempo

L’alert del CSIRT Italia arriva in casella un martedì mattina: un servizio esposto della vostra rete espone una vulnerabilità nota. Si va a controllare e si scopre la parte più scomoda della storia — il vendor aveva pubblicato la correzione settimane prima. Nessuno l’ha applicata, non per negligenza, ma perché in quelle stesse settimane erano arrivate altre duecento segnalazioni e qualcuno ha dovuto decidere cosa guardare per primo.

È la fotografia che emerge dall’ultimo rapporto dell’Agenzia per la Cybersicurezza Nazionale, ed è un cambio di baricentro che vale la pena leggere con attenzione.

Il numero che cambia la scala del problema

Nel primo semestre del 2026 sono state pubblicate 37.032 nuove CVE, il 54% in più rispetto alle 24.098 dello stesso periodo del 2025. Il dato arriva dall’Operational Summary semestrale dell’ACN, e non è una curiosità statistica: significa che ogni giorno lavorativo entrano nel mondo oltre duecento nuove vulnerabilità documentate, ciascuna potenzialmente rilevante per qualche pezzo dell’infrastruttura aziendale.

L’Agenzia indica anche una causa, e vale la pena riportarla senza addolcirla: l’accelerazione è «verosimilmente ascrivibile al crescente utilizzo di modelli AI di frontiera», che stanno abbattendo i tempi dell’analisi del codice, della ricerca di vulnerabilità e della generazione dei Proof of Concept. La stessa tecnologia che i team di sicurezza stanno valutando per difendersi sta moltiplicando, dall’altro lato, il volume di ciò da cui difendersi.

Due numeri aiutano a dare profondità al dato grezzo:

• 5.722 CVE del semestre avevano già almeno un Proof of Concept disponibile pubblicamente;
• 69 CVE hanno mostrato uno sfruttamento attivo confermato.

Sono, rispettivamente, il 15% e lo 0,2% del totale. È esattamente questa asimmetria il punto: la stragrande maggioranza delle vulnerabilità pubblicate non verrà mai usata contro di voi, e una minoranza sottile può fermarvi la produzione.

La scoperta non è il collo di bottiglia

Sul fronte del monitoraggio, il quadro nazionale è tutt’altro che passivo. Nel semestre il CSIRT Italia ha rilevato 24.303 tra dispositivi e servizi esposti a rischi potenziali e 1.560 con comportamenti riconducibili a una compromissione, avvisando i soggetti interessati. La macchina di allertamento funziona, e in molti casi arriva prima dell’attaccante.

Il problema si sposta a valle. Nelle segnalazioni ricorre una formula che dovrebbe far riflettere ogni direzione IT: la vulnerabilità era già sanata dal vendor. La correzione esisteva. Quello che mancava era il processo per portarla in produzione — la finestra tra «la patch è disponibile» e «la patch è installata sui nostri sistemi».

Nel 2026 la sicurezza non si perde perché non si sapeva. Si perde nella finestra tra la patch pubblicata e la patch applicata.

Quella finestra, per molte aziende, non è governata da una decisione: è il residuo di ciò che avanza dopo i progetti, i ticket e le manutenzioni ordinarie. E si allarga proprio mentre il volume delle CVE cresce del 54% l’anno.

Come si sceglie cosa correggere prima

Con questi numeri, l’idea di «applicare tutte le patch» non è una strategia: è una dichiarazione d’intenti che nessun team può mantenere. La priorità va costruita su criteri di esposizione reale, e le indicazioni dell’ACN sono pragmatiche. Vanno in cima alla lista le vulnerabilità che:

• riguardano sistemi esposti su Internet, cioè raggiungibili senza passare da un accesso interno;
• hanno un Proof of Concept pubblico, perché la distanza tra teoria e attacco automatizzato si accorcia a giorni;
• mostrano segnali di scansione o sfruttamento attivo, i 69 casi che contano davvero.

È un criterio diverso dal punteggio CVSS usato da solo. Un 9.8 su un sistema segmentato, non esposto e senza exploit pubblici può ragionevolmente aspettare la finestra di manutenzione; un 7.5 su un portale pubblico con PoC in circolazione, no. Il punteggio misura la gravità teorica, non la probabilità che tocchi a voi.

Perché questo funzioni servono due presupposti che molte aziende scoprono di non avere: un inventario aggiornato di ciò che è esposto — inclusi gli apparati perimetrali e i servizi accesi anni fa e mai dismessi — e qualcuno che legga gli alert ogni giorno, non quando c’è tempo.

Non è più solo buona pratica: è una misura verificabile

C’è anche un lato normativo che nel 2026 smette di essere teorico. La gestione delle vulnerabilità è tra le misure di sicurezza di base che i soggetti nel perimetro NIS2 devono avere operative, e dal 31 ottobre l’ACN può entrare nel merito e verificarle. In sede di controllo non conta aver scritto una policy di patching: conta poter mostrare le evidenze — quando è stata rilevata la vulnerabilità, con quale criterio è stata classificata, in quanto tempo è stata chiusa e chi ha deciso di rinviarla, se è stata rinviata.

Detto altrimenti: la stessa disciplina che riduce il rischio è anche ciò che dimostra la conformità. Non sono due progetti separati.

Il nostro punto di vista

Un numero come 37.032 non si affronta con uno sforzo straordinario una tantum, ma con una cadenza. Il vulnerability assessment periodico serve a sapere che cosa avete davvero esposto e in che stato è — è la mappa senza cui ogni priorità è un’ipotesi. Il presidio continuo del SOC · Smart Care serve al resto dell’anno: correlare gli alert, riconoscere i segnali di scansione sui vostri indirizzi e trasformare una segnalazione in un intervento con una data, invece che in una mail archiviata.

Il resto è governo del ciclo di patching: finestre di manutenzione concordate, priorità decise con criteri espliciti, tracciamento delle eccezioni. Non è la parte affascinante della cybersecurity, ma è quella che, negli ultimi sei mesi, ha separato le aziende che hanno ricevuto un alert da quelle che hanno subito un incidente.