Il triage delle vulnerabilità non è più un servizio pubblico: chi risponde ora al board

Con il 263% di CVE in più in cinque anni, il modello centralizzato di analisi si ridimensiona — e la responsabilità ricade sulle singole organizzazioni

La fine del triage universale

Tra il 2020 e il 2025 il numero di CVE pubblicate è cresciuto del 263%. Una curva che ha reso insostenibile il modello su cui il mondo intero ha costruito i propri processi di gestione delle vulnerabilità. Dal 15 aprile 2025, il National Vulnerability Database ha ufficialmente ridotto il proprio perimetro di analisi: solo le vulnerabilità incluse nel catalogo KEV della CISA, quelle relative a software in uso presso il governo federale statunitense o classificate come critiche ai sensi dell'Executive Order 14028 riceveranno un arricchimento completo, punteggio CVSS, descrizione tecnica, contesto operativo. Tutto il resto viene catalogato, ma non analizzato. La marcatura è eloquente: "Not Scheduled". Non è un collasso, ma una ripriorizzazione dichiarata. Come ha osservato David Lindner, CISO di lungo corso nel settore della sicurezza applicativa, si chiude la stagione in cui i team di security potevano affidarsi a un singolo database governativo per ogni flaw conosciuta. Trey Ford, veterano della strategia di sicurezza, conferma: a questi volumi, il triage centralizzato non può reggere. Il punto non è chi ha ragione, ma chi ne subisce le conseguenze.

Un vuoto operativo con impatto diretto sul budget

Per anni, il NVD è stato l'infrastruttura informativa implicita su cui poggiavano processi di vulnerability management, policy di patching, workflow di audit e reportistica verso il board. I punteggi CVSS assegnati dal NIST erano il benchmark condiviso: una lingua franca tra team tecnici, auditor e risk officer. Se oggi quel benchmark copre solo un sottoinsieme, definito secondo priorità statunitensi, ogni organizzazione che lo utilizzava come input per la propria prioritizzazione si trova di fronte a un vuoto concreto. I team di sicurezza devono costruire o acquisire internamente capacità di triage che prima erano esternalizzate de facto a un ente pubblico. I budget devono assorbire fonti di threat intelligence alternative. I processi di audit che ancoravano la propria logica al CVSS score NIST perdono il riferimento. Per il board la questione non è tecnica: è economica e organizzativa. Quanto costa colmare questo gap? Chi ne risponde nella vostra struttura di governance? E soprattutto: qualcuno ha già iniziato a calcolarlo?

La contraddizione strutturale per le organizzazioni europee

La frizione più rilevante è di architettura normativa. NIS2 e DORA impongono alle organizzazioni europee una gestione sistematica e documentabile delle vulnerabilità. Nessuna deroga, nessun sottoinsieme. Copertura completa, tracciabilità dei processi, accountability dimostrabile. Ma la fonte centralizzata su cui molti di quei processi erano costruiti ora copre esplicitamente solo un perimetro calibrato su priorità federali americane. Il risultato è una condizione asimmetrica: responsabilità normativa piena, infrastruttura informativa ridotta. L'ownership del triage si sposta dall'ente pubblico globale all'organizzazione singola, senza che budget, team e competenze siano stati dimensionati per questo. Non si tratta di un rischio teorico. Si tratta di un disallineamento già in atto tra ciò che la regolamentazione europea richiede e ciò che l'ecosistema informativo globale è disposto a garantire. Chi siede nel board di un'organizzazione soggetta a NIS2 o DORA dovrebbe chiedersi se il proprio processo di vulnerability management è stato progettato per funzionare anche senza il NVD come stampella.

Il vincolo normativo: NIS2 e DORA non lasciano margini

Il quadro normativo europeo è esplicito. L'articolo 21, comma 2, lettera (e) della Direttiva NIS2 impone ai soggetti essenziali e importanti l'adozione di misure per la gestione delle vulnerabilità, inclusa la divulgazione coordinata. Non c'è clausola di esenzione legata alla disponibilità di fonti terze: l'obbligo di identificazione e prioritizzazione è in capo all'organizzazione. Il Regolamento DORA, agli articoli 7 e 8, richiede agli enti finanziari un framework di gestione del rischio ICT che includa l'identificazione e la gestione delle vulnerabilità come componente strutturale. Anche qui, la riduzione della copertura NVD non attenua l'obbligo, lo intensifica. Il collegamento è operativo, non interpretativo. Se il vostro processo di gestione delle vulnerabilità dipendeva interamente dall'arricchimento NIST, oggi siete in una posizione in cui l'obbligo normativo esiste, ma il presupposto informativo su cui il processo era costruito si è ridotto. Il gap non è di compliance formale. È di capacità reale.

La domanda che il board dovrebbe farsi oggi

Se domani il NVD smette di arricchire una CVE che colpisce un vostro sistema critico, il vostro processo di vulnerability management la intercetta lo stesso, o la scoprite solo dopo l'incidente? Questa non è una domanda per il team tecnico. È una domanda di governance. Perché la risposta rivela se la vostra organizzazione ha un processo di triage autonomo o se ha sempre operato in delega implicita verso un database pubblico che ora ha ridefinito le proprie priorità. Il triage delle vulnerabilità non è mai stato un servizio garantito. Era un bene comune di cui tutti usufruivano senza pagare il costo reale. Ora quel costo emerge, e qualcuno nella vostra organizzazione deve decidere chi lo sostiene, con quale budget e con quale mandato. Non è una questione di strumenti. È una questione di ownership.

Il vulnerability management autonomo non è un upgrade: è la condizione minima per chi ha obblighi normativi europei e opera in un ecosistema informativo che ha smesso di garantire copertura universale. La domanda non è se adeguarsi, ma se qualcuno nella vostra organizzazione se ne è già accorto.