Diecimila CVE al mese e una dashboard verde (ma la velocity era il KPI sbagliato)

Il numero preferito dal comitato rischi, quando si parla di vulnerabilità, è una percentuale. Sistemi aggiornati entro trenta giorni: novantadue per cento (il numero me lo invento io, ma chi ha seduto in un comitato ne ha visto uno identico). Casella verde. Il CFO chiede se il dato è in linea con il trimestre precedente, qualcuno annuisce, si passa al punto successivo. Nessuno chiede quali siano i sistemi dell'otto per cento mancante. Tanto meno chi abbia deciso che potevano aspettare.

L'8 settembre Microsoft rilascia, in un solo Patch Tuesday, le correzioni per 972 vulnerabilità, 113 delle quali critiche: più del doppio delle 415 di agosto, un record secondo l'analisi di CrowdStrike. Il mese dopo la percentuale scende. Il team non ha lavorato peggio: è cambiato il denominatore. E il denominatore non lo governa più nessuno.

Con questi volumi, chi misura il patch management in velocità e in percentuale di copertura misura il rumore. La decisione che conta è un'altra, e va portata al board con una firma sotto: che cosa scegliamo, per iscritto, di non aggiornare e di non esporre.

Diecimila vulnerabilità al mese, poche decine sfruttate

Il 30 settembre il Google Threat Intelligence Group ha messo i numeri in fila nel rapporto "Vulnerability Discovery and Exploitation Trends in the AI Era". Le vulnerabilità divulgate ogni mese sono passate da 5.045 a gennaio a 10.740 ad agosto. Più che raddoppiate in sette mesi.

Quelle sfruttate davvero sono lo 0,23% del totale, circa una su 431: "decine contro migliaia al mese", scrive il rapporto. Quel numero va letto per quello che è. Dice quante vulnerabilità gli attaccanti usano, non quante aziende colpiscono: una sola falla sfruttata può bastare per entrare in migliaia di reti.

E la frazione cresce. La media mensile delle vulnerabilità sfruttate è salita da 10,5 nel 2025 a 18 nei primi otto mesi del 2026; quelle classificate ad alto rischio sono passate da 28 in tutto il 2025 a 75 tra gennaio e agosto. Si muovono anche più in fretta: una falla di BeyondTrust (CVE-2026-1731, se volete cercarla) è stata usata da un primo gruppo di attaccanti quattro giorni dopo la pubblicazione, e da altri cinque entro una settimana.

Poi c'è l'AI. Metà delle vulnerabilità trovate con l'AI permette di eseguire codice da remoto (la famigerata RCE: qualcuno, da fuori, fa girare i suoi programmi sui vostri server); nel resto del catalogo la quota è del 26%. Secondo The Record, il 14% delle falle sfruttate quest'anno colpiva apparati di frontiera e di sicurezza: proprio le scatole che dovrebbero tenere fuori gli altri. A maggio, a proposito di Mythos e della lista di sicurezza del kernel, lo raccontavo come un caso; quattro mesi dopo è nelle statistiche.

Una precisazione da pedante (vizio di categoria): il rapporto è di Google, che nella stessa pagina consiglia il proprio agente per correggere il codice. Ci torno più avanti.

Le due curve vanno lette insieme. Immaginate una segreteria che riceve diecimila lettere al mese, sapendo che quattro o cinque contengono una diffida con scadenza a quattro giorni. Ha senso misurarla sulla percentuale di buste aperte? Soprattutto se le buste sono tutte uguali, e la segreteria, per far salire il numero, apre prima le più leggere...

La velocity che predicavo nel 2020

Qui devo fare autocritica. Nel maggio 2020 scrivevo su questo blog che un processo di patching efficace copre "nel minor tempo possibile" le vulnerabilità segnalate dagli strumenti di scansione, e proponevo le CVE con il loro punteggio CVSS come lingua comune tra IT Operations e sicurezza, perché "squisitamente misurabili e quantificabili" (Patching management, migliorare la velocity). Funzionava con un denominatore a misura d'uomo.

Da allora il denominatore è esploso, e il punteggio ha smesso di arrivare. Dal 15 aprile 2026 il NIST, che gestisce il database pubblico americano delle vulnerabilità (con 21 dipendenti, secondo The Record), analizza e assegna punteggio solo alle CVE del catalogo delle vulnerabilità sfruttate della CISA, a quelle del software federale e a quelle del software classificato "critico". Le altre restano in elenco, senza analisi (The Record). L'agenzia lo ha messo per iscritto: "this increased productivity is not enough to keep up with growing submissions". Per la gran parte delle CVE, il punteggio su cui nel 2020 costruivo le priorità è una metrica che semplicemente non esiste.

E il KPI? Quando la percentuale di sistemi aggiornati diventa l'obiettivo, ogni patch vale uno. Mille browser aggiornati con un clic valgono mille; il gestionale "legacy" che chiede un fermo concordato con la produzione (e una telefonata che nessuno vuole fare), o la VPN che non si può riavviare in settimana, valgono uno a testa. Chi deve far salire il numero sa bene da dove partire. Un dato che lo dimostri non ce l'ho: lo deduco da come è costruita la metrica, e da quel 14% di apparati di frontiera nelle statistiche di Google. Lo stesso meccanismo l'ho visto lavorare sugli incidenti taciuti al board: la misura diventata obiettivo smette di misurare, e il verde della dashboard rassicura proprio chi dovrebbe fare domande.

E se lo 0,23% fosse solo quello che vediamo?

In qualunque comitato l'obiezione arriverebbe subito, ed è seria. Lo 0,23% è lo sfruttamento osservato: Google vede ciò che gli mostrano i suoi sensori e i suoi clienti, e ciò che nessuno ha visto non è per questo innocuo. Sui ransomware ho sostenuto questa tesi. Se poi tra la pubblicazione e il primo attacco passano quattro giorni, nessun comitato di triage fa in tempo a riunirsi. Quindi aggiornare tutto, sempre, il più in fretta possibile: il triage è una scommessa, e in sicurezza le scommesse si perdono.

Che il triage sia una scommessa è vero (e chi lo vende come una scienza esatta mente). Ma "aggiornare tutto" non è un'opzione disponibile. Con 972 correzioni in un mese da un solo fornitore, quale squadra chiude tutto entro trenta giorni senza fermare qualcosa che fattura? Se esiste, vorrei conoscerla. Una selezione, quindi, la state già facendo; la differenza è se la fate per iscritto o per inerzia. Chi dichiara di "patchare tutto" decide ogni venerdì pomeriggio che cosa rimandare, sistemista per sistemista, e quella scelta non sale mai di un piano. La scommessa c'è comunque. Cambia chi la firma... ammesso che qualcuno la firmi.

Il governo americano questa scelta l'ha fatta nel 2021. Con la direttiva vincolante BOD 22-01 del 3 novembre di quell'anno, la CISA ha imposto alle agenzie civili federali di correggere le vulnerabilità del suo catalogo di quelle sfruttate entro scadenze precise (due settimane per le CVE del 2021, sei mesi per le più vecchie), puntando su quelle "most likely to result in a damaging intrusion" invece che sui punteggi di gravità (SecurityWeek). Lì è una regola scritta. Da noi, quante aziende ne hanno una equivalente, approvata da qualcuno?

Chi firma il "no"?

Torniamo a Google. Il rapporto raccomanda di passare dal "mass-patching" a un triage guidato dall'intelligence sulle minacce, "combining targeted edge-defense with automated, agentic remediation". Per la parte agentica il prodotto è nella stessa pagina: CodeMender, dentro la piattaforma di difesa AI di Google. Chi pubblica le statistiche sui furti vende anche l'antifurto (nulla di illecito, ma un CFO leggerebbe la raccomandazione due volte). Help Net Security l'ha ripresa così com'era: dal patching di massa al triage.

Sul triage sono d'accordo. Ma il triage, da solo, sposta la decisione senza assegnarla. Se l'elenco delle priorità lo calcola il modello del fornitore, e la correzione la applica un agente dello stesso fornitore, chi ha deciso quale rischio resta in casa? Il rischio residuo non ha più un proprietario con nome e cognome: ha un algoritmo, e un contratto di licenza (con la limitazione di responsabilità scritta molto bene, immagino). Per chi decide è una perdita di autonomia che non compare in nessun preventivo. Vale anche per i punteggi che arrivano già pronti: comodi, finché non scoprite che a stabilire che cosa per voi è "critico" è qualcun altro.

Quello che serve costa poco in tecnologia e molto in responsabilità. Un registro breve, leggibile da un consigliere, di ciò che non si aggiorna: quali sistemi, perché, con quale compensazione (toglierli da Internet, per esempio, oppure isolarli), fino a quando, e chi ha firmato. Una riga per eccezione, con una scadenza che obbliga qualcuno a rifirmare oppure a chiudere. Accanto, una misura diversa dalla percentuale: per quanti giorni restano aperte le vulnerabilità già sfruttate sui sistemi esposti, quante eccezioni sono scadute senza che nessuno se ne accorgesse. Numeri scomodi, ma con un responsabile.

La NIS2 chiede già che l'organo di gestione approvi le misure di sicurezza e ne risponda. Approvare una percentuale verde è facile; approvare l'elenco dei rischi che si è scelto di tenere costringe a leggerlo.

Le domande per il prossimo consiglio

Quante vulnerabilità già sfruttate abbiamo oggi sui sistemi esposti a Internet, e da quanti giorni sono aperte?
Chi ha deciso che cosa non aggiornare il mese scorso, e dove sta scritto?
Quante eccezioni sono scadute senza essere né rinnovate né chiuse?
Se domani un agente del fornitore scegliesse che cosa correggere, chi firmerebbe il rischio che resta?

La percentuale, intanto, resterà verde. E continuerà a rispondere con puntualità a una domanda che nessuno ha più bisogno di fare...

freeuser.org