Vulnerability management: cos'è e come gestirlo nel tempo

La risposta breve: il vulnerability management, o gestione delle vulnerabilità, è il processo continuo con cui un'organizzazione sa quali vulnerabilità toccano i suoi asset, decide come rispondere a ciascuna, esegue la risposta e verifica che resti in piedi nel tempo. Non è una scansione e non è un prodotto: è un ciclo con un inventario, delle priorità, dei tempi, dei responsabili e delle prove.

Qui vediamo come funziona il ciclo, in cosa si distingue dal vulnerability assessment, come si decidono le priorità e cosa chiedono NIS2, DORA e ISO 27001.

Cos'è il vulnerability management

Il NIST Cybersecurity Framework 2.0 lo riassume in una riga, la sottocategoria ID.RA-01: le vulnerabilità degli asset sono identificate, convalidate e registrate. La sottocategoria ID.RA-08 aggiunge che devono esistere processi per ricevere, analizzare e rispondere alle segnalazioni di vulnerabilità. Sono le stesse due voci che l'ACN ha ripreso nelle misure di base per i soggetti NIS, come vedremo più avanti.

La parola che conta è processo. Ogni giorno escono vulnerabilità nuove, gli asset cambiano, una patch installata può sparire con un ripristino da backup. Un'organizzazione che fa una scansione l'anno ha una fotografia; un'organizzazione che fa vulnerability management ha un registro aggiornato di cosa è aperto, da quanto tempo e chi se ne occupa.

Il motivo per farlo bene è concreto. Nell'ENISA Threat Landscape 2025, che analizza quasi 4.900 incidenti selezionati nel panorama europeo tra luglio 2024 e giugno 2025, lo sfruttamento di vulnerabilità è il secondo vettore di accesso iniziale, con il 21,3% dei casi, dopo il phishing (circa 60%). Lo stesso rapporto osserva campagne che sfruttano le vulnerabilità a pochi giorni dalla loro divulgazione.

Vulnerability management e vulnerability assessment: la differenza

Le due espressioni vengono spesso usate come sinonimi, ma indicano cose diverse.

• Il vulnerability assessment è un'attività: una scansione o una serie di verifiche che produce l'elenco delle vulnerabilità presenti in un perimetro in un dato momento. Come si fa, con quali strumenti e come si legge il report lo spieghiamo nell'articolo sul vulnerability assessment.
• Il vulnerability management è il processo che usa quei risultati, insieme ad altre fonti, per decidere cosa correggere, entro quando e come, e per dimostrare che la correzione è avvenuta.

Lo stesso vale per gli altri pezzi del ciclo. Il penetration test verifica in profondità se una vulnerabilità è davvero sfruttabile; il patch management è una delle risposte possibili, l'aggiornamento del software. Il vulnerability management li tiene insieme e dà a ciascuno un posto e una cadenza.

Il ciclo, passo per passo

La NIST SP 800-40 Rev. 4 descrive un ciclo di vita della gestione delle vulnerabilità software che vale per qualsiasi tipo di risposta, non solo per le patch. Lo riprendiamo in quattro passi.

1. Sapere cosa si ha e cosa lo tocca

Il primo passo è sapere quando una vulnerabilità nuova riguarda i propri asset. Servono due cose. Un inventario che arrivi fino alle versioni del software, ai pacchetti e alle librerie, e un flusso di informazioni sulle vulnerabilità: avvisi dei produttori, la National Vulnerability Database del NIST, il catalogo KEV della CISA, la banca dati europea delle vulnerabilità (EUVD) che la direttiva NIS2 all'art. 12 affida all'ENISA, i canali del CSIRT Italia.

Le scansioni periodiche e i test servono a scoprire anche quello che l'inventario non dice: sistemi dimenticati, configurazioni deboli, versioni rimaste indietro.

2. Pianificare la risposta

Per ogni vulnerabilità si valuta il rischio per l'organizzazione e si sceglie una risposta. NIST ne indica quattro famiglie: accettare il rischio, mitigarlo (con una patch, un upgrade, un cambio di configurazione o un controllo aggiuntivo), trasferirlo, evitarlo togliendo il software o dismettendo l'asset. La scelta va scritta, con i tempi e il nome di chi la esegue.

3. Eseguire e verificare

Si prepara la risposta (per una patch: recuperarla, controllarne integrità e provenienza, provarla), la si attua coordinandosi con il change management, e poi si verifica. Verificare vuol dire controllare che la patch sia installata e attiva, che il controllo aggiuntivo funzioni, che l'asset dismesso sia davvero spento. Una vulnerabilità si chiude nel registro solo dopo la verifica, di solito con una nuova scansione.

4. Monitorare nel tempo

La risposta deve restare in piedi: nessuno disinstalla la patch, disattiva il controllo, lascia scadere la polizza o riaccende il server dismesso. Lungo tutto il ciclo NIST mette anche le attività amministrative: documentazione, log, report, e un change management solido, che definisce parte essenziale del processo.

Come si decidono le priorità

Le vulnerabilità aperte sono quasi sempre più di quelle che si riescono a correggere subito, quindi il cuore del processo è l'ordine in cui si affrontano.

• Gravità tecnica. Il punteggio CVSS dice quanto è grave una vulnerabilità in astratto, su una scala da 0 a 10. È un punto di partenza, non una misura del rischio: come si legge lo spieghiamo nell'articolo su CVE e CVSS.
• Sfruttamento reale. Il catalogo KEV della CISA raccoglie le vulnerabilità con prove affidabili di sfruttamento attivo e un'azione di rimedio chiara. Nella versione del 26 ottobre 2026 conta 1.758 voci, e per 361 CISA indica un uso noto in campagne ransomware. CISA raccomanda anche alle organizzazioni non federali di usarlo come input delle proprie priorità.
• Probabilità di sfruttamento. L'EPSS, mantenuto da un gruppo di lavoro di FIRST, stima ogni giorno per ogni CVE pubblicato la probabilità che venga sfruttato nei 30 giorni successivi.
• Contesto dell'asset. Lo stesso CVE pesa in modo diverso su un server esposto su Internet che regge la produzione e su una postazione di test isolata. Esposizione, importanza per il business e dati trattati sono informazioni che solo l'organizzazione ha.

Il risultato pratico è una matrice di tempi decisa in anticipo: per ogni combinazione di importanza dell'asset e gravità della vulnerabilità, entro quanti giorni si interviene e chi può approvare un'eccezione. Così una vulnerabilità nuova non richiede una riunione: trova già la sua fascia.

Cosa chiedono NIS2, DORA e ISO 27001

NIS2 e misure ACN

La direttiva NIS2, all'art. 21, par. 2, lett. e), mette la gestione e la divulgazione delle vulnerabilità tra gli elementi minimi delle misure di gestione del rischio. Il D.Lgs. 138/2024 che la recepisce lo riprende all'art. 24, comma 2, lettera e): "sicurezza dell'acquisizione, dello sviluppo e della manutenzione dei sistemi informativi e di rete, ivi comprese la gestione e la divulgazione delle vulnerabilità".

Il dettaglio operativo è nelle misure di sicurezza di base della determinazione ACN 379907/2025: allegato 1 per i soggetti importanti, allegato 2 per gli essenziali. La pagina ACN sulle modalità e specifiche di base fissa l'adozione entro 18 mesi dalla comunicazione di inserimento nell'elenco nazionale NIS, e indica ottobre 2026. Le misure che descrivono un processo di vulnerability management sono queste:

• ID.AM-01 e ID.AM-02: inventari aggiornati di hardware (inclusi dispositivi IoT, OT e mobili) e di servizi, sistemi e applicazioni, comprese quelle open-source e custom.
• ID.RA-01: "Le vulnerabilità negli asset sono identificate, confermate e registrate", usando le informazioni raccolte dai canali monitorati.
• ID.RA-08: monitoraggio almeno dei canali del CSIRT Italia e degli eventuali CERT e ISAC di settore; vulnerabilità "prontamente risolte" con aggiornamenti o mitigazioni, oppure con un rischio accettato e documentato nel piano di trattamento dei rischi; un piano di gestione delle vulnerabilità documentato, con modalità, ruoli e responsabilità, approvato dagli organi di amministrazione e direttivi.
• PR.PS-02: aggiornamenti di sicurezza installati "senza ingiustificato ritardo", in coerenza con quel piano.

Per i soggetti essenziali l'allegato 2 aggiunge due punti. Almeno sui sistemi rilevanti si eseguono periodicamente, e comunque prima della messa in esercizio, attività di identificazione delle vulnerabilità che comprendano almeno vulnerability assessment e/o penetration test, documentate in relazioni con attività svolte, esiti, vulnerabilità rilevate e livello di impatto (ID.RA-01, punti 2 e 3). E si monitorano anche i canali dei fornitori del software ritenuto critico (ID.RA-08, punto 5).

DORA

Per le entità finanziarie il riferimento è il Regolamento delegato (UE) 2024/1774, le norme tecniche sulla gestione dei rischi informatici previste dal DORA. L'art. 10, che attua l'art. 15 del DORA (le entità ammesse al quadro semplificato dell'art. 16 seguono un titolo a parte), chiede procedure documentate di gestione delle vulnerabilità e delle patch, con fonti di informazione affidabili, scansioni automatiche, verifica di come i fornitori ICT gestiscono le vulnerabilità dei servizi forniti, tracciamento delle librerie di terze parti comprese quelle open-source, registrazione di ogni vulnerabilità rilevata e monitoraggio della sua risoluzione. Per le risorse ICT che supportano funzioni essenziali o importanti la scansione si esegue "con cadenza almeno settimanale". Per le patch servono scadenze e procedure di escalation quando le scadenze non si rispettano.

ISO/IEC 27001:2022

Nell'Annex A il tema è il controllo 8.8, gestione delle vulnerabilità tecniche. In audit le domande sono quelle del ciclo: da dove arrivano le informazioni, come si decidono le priorità, entro quanto si chiude, dove sono le prove e come sono motivate le eccezioni.

Le metriche che servono davvero

La SP 800-40 Rev. 4 avverte che le metriche troppo semplici non portano a nessuna decisione. Sapere che il 10% degli asset non è aggiornato non dice niente se non si sa quali: è grave se sono i più importanti, può essere una scelta ragionevole se sono i meno importanti.

NIST suggerisce di incrociare l'importanza degli asset con la gravità delle vulnerabilità e di misurare, per ogni casella, la quota corretta entro la scadenza del piano e il tempo medio e mediano di correzione. A queste noi aggiungiamo due indicatori utili per il board: le vulnerabilità del catalogo KEV aperte sugli asset esposti, e le eccezioni attive con la loro data di revisione.

Da dove si parte in un'azienda mid-market

1. Inventario. Prima i sistemi esposti su Internet e quelli che reggono i servizi critici, poi il resto. Senza inventario ogni scansione lascia fuori qualcosa.
2. Policy e piano scritti. Chi riceve le informazioni sulle vulnerabilità, chi decide le priorità, chi corregge, chi approva le eccezioni. Per un soggetto NIS il piano va approvato dagli organi di amministrazione e direttivi.
3. Cadenza delle scansioni. Più frequente sugli asset esposti e critici, autenticata dove possibile, e ripetuta dopo ogni correzione.
4. Matrice dei tempi. Fasce decise in anticipo su gravità, sfruttamento reale ed esposizione, con un percorso d'emergenza per le vulnerabilità sfruttate attivamente.
5. Eccezioni tracciate. Ogni vulnerabilità non corretta ha una motivazione, una misura compensativa, un responsabile e una data di revisione.
6. Report periodico. Poche metriche, sempre le stesse, portate a chi decide.

L'errore più comune è fermarsi al primo passo utile: comprare uno scanner e trattare il suo report come il processo. Lo scanner produce l'elenco; il vulnerability management decide cosa farne, e lascia le prove che lo dimostrano.

In sintesi

Il vulnerability management è un ciclo continuo: conoscere asset e vulnerabilità, decidere la risposta, eseguirla, verificarla e controllare che resti. Le priorità si decidono incrociando gravità tecnica, sfruttamento reale (KEV, EPSS) e contesto dell'asset. NIS2 e misure ACN chiedono un piano approvato dai vertici e vulnerabilità risolte prontamente, il DORA scansioni almeno settimanali sulle risorse che supportano funzioni essenziali o importanti, la ISO 27001 il controllo 8.8.

Se vuoi capire quanto restano aperte le vulnerabilità sui tuoi sistemi e come costruire un processo che regga un audit NIS2 o DORA, puoi partire dai nostri servizi di cybersecurity.