Gestione delle vulnerabilità: come funziona e come i team di sicurezza riducono i rischi di exploit

Le organizzazioni devono far fronte a un carico di vulnerabilità in costante aumento. Con 40.289 CVE pubblicati nel 2024, pari a un aumento del 39% rispetto al 2023 (Fortinet Global Threat Landscape Report 2025), e con una violazione dei dati che ora costa in media 4,88 milioni di dollari (IBM Cost of a Data Breach Report 2024), le compromissioni della catena di fornitura, i carichi di lavoro cloud e le infrastrutture a fine vita hanno cambiato radicalmente il calcolo del rischio, e i cicli periodici di patch non sono più una risposta strutturalmente adeguata.

Questa guida illustra il funzionamento della gestione delle vulnerabilità, come sviluppare e valutare un programma maturo e in che modo le moderne funzionalità di rilevamento consentono di individuare le vulnerabilità che suscitano l'interesse attivo degli aggressori. È rivolta ai team SOC, ai tecnici della sicurezza e ai CISO impegnati a sviluppare o perfezionare un programma di gestione delle vulnerabilità in ambienti aziendali ibridi.

Che cos'è la gestione delle vulnerabilità?

La gestione delle vulnerabilità è un processo strategico e continuo volto a identificare, valutare, classificare in ordine di priorità e correggere le falle di sicurezza presenti nell'infrastruttura tecnologica di un'organizzazione. A differenza delle valutazioni puntuali o dell'ambito più ristretto della gestione delle patch, la gestione delle vulnerabilità copre l'intero ciclo di vita dell'esposizione, dall'individuazione delle risorse alla verifica delle correzioni, consentendo una riduzione sistematica dei rischi di sfruttamento.

In che modo la gestione delle vulnerabilità si differenzia dalla valutazione delle vulnerabilità e dalla gestione delle patch?

Questi termini vengono spesso utilizzati in modo intercambiabile, ma descrivono attività diverse con ambiti di applicazione distinti. La gestione delle vulnerabilità è un programma continuativo: garantisce un monitoraggio costante dell’intero panorama delle esposizioni, definisce le priorità e tiene traccia dei progressi compiuti nel tempo nella risoluzione delle vulnerabilità. La valutazione delle vulnerabilità fornisce un’istantanea puntuale, utile per gli audit e le valutazioni mirate, ma non sostituisce il monitoraggio continuo. La gestione delle patch riguarda esclusivamente gli aggiornamenti software e rappresenta solo una parte delle attività di risoluzione delle vulnerabilità all’interno di un programma maturo di gestione delle vulnerabilità. 

Il CVE (Common Vulnerabilities and Exposures) fornisce identificatori standardizzati per le vulnerabilità note. Il CVSS (Common Vulnerability Scoring System) valuta la gravità da 0 a 10, sebbene questo approccio sia oggetto di critiche ben documentate per la creazione di una falsa urgenza: solo il 3% delle vulnerabilità comporta più frequentemente un'esposizione significativa, il che significa che la stragrande maggioranza dei risultati segnalati dal CVSS non rappresenta, in pratica, una minaccia operativa (Tenable Research 2024). L'Exploit Prediction Scoring System (EPSS) prevede la probabilità di sfruttamento entro 30 giorni utilizzando l'apprendimento automatico, offrendo una prioritizzazione più accurata dal punto di vista operativo. Il catalogo Known Exploited Vulnerabilities (KEV) della CISA tiene traccia delle falle confermate come attivamente sfruttate, rappresentando gli obiettivi di correzione con la massima priorità in qualsiasi programma (Catalogo KEV della CISA).

Qual è la differenza tra una vulnerabilità, un rischio e una minaccia?

Una vulnerabilità è un punto debole in un sistema, un'applicazione o una configurazione che può essere sfruttato. Una minaccia è un attore o una condizione che possiede la capacità e l'intenzione di sfruttare tale punto debole. Un rischio è il potenziale impatto sul business nel caso in cui la minaccia riesca a sfruttare la vulnerabilità, tenendo conto sia della probabilità che delle conseguenze. I programmi di gestione delle vulnerabilità affrontano direttamente le vulnerabilità, ma una definizione efficace delle priorità richiede tutti e tre questi elementi: un CVE ad alta gravità in un sistema isolato e air-gapped può comportare un rischio operativo minore rispetto a un difetto di media gravità attivamente preso di mira in un ambiente di produzione che si affaccia su servizi esposti a Internet.

Come funziona la gestione delle vulnerabilità?

La gestione delle vulnerabilità si articola in un ciclo continuo composto da sei fasi. Ogni fase alimenta quella successiva e il programma non si interrompe mai completamente: le risorse cambiano, ogni giorno vengono rese note nuove vulnerabilità e il panorama delle minacce è in continua evoluzione. Il ciclo continuo in sei fasi si articola come segue:

‍

1. Individuazione e inventario delle risorse — Identificare tutte le risorse, inclusi hardware, software, cloud , container e identità. Le organizzazioni non possono proteggere risorse di cui ignorano l'esistenza. Gli ambienti moderni richiedono un processo di individuazione continuo, integrato con i CMDB e le piattaforme cloud , per garantire una visibilità in tempo reale sull'intera infrastruttura ibrida.
   
2. Priorità delle risorse — Classificare le risorse in base alla criticità, alla sensibilità dei dati, alla funzione aziendale e al livello di esposizione. Le risorse esposte a Internet e i sistemi che ospitano dati sensibili sono sottoposti alla massima frequenza di scansione e a SLA di risoluzione più brevi. Le tecniche di gestione della superficie di attacco identificano le risorse che richiedono un intervento immediato.
   
3. Valutazione e scansione — Individua le vulnerabilità tramite scansioni autenticate e non autenticate, monitoraggio basato su agenti, SAST e DAST per le applicazioni e CSPM per cloud . Le scansioni autenticate offrono una visibilità più approfondita rispetto alle valutazioni esterne. La scansione basata su agenti consente il monitoraggio continuo dei carichi di lavoro dinamici.
   
4. Reportistica e analisi — Trasformiamo i dati grezzi delle scansioni in informazioni utili e gerarchizzate. I report efficaci mettono in evidenza i risultati critici, li contestualizzano rispetto alle esigenze aziendali e monitorano i progressi delle azioni correttive nel tempo. I dashboard esecutivi comunicano le tendenze relative ai rischi alla dirigenza. I report tecnici forniscono ai team di ingegneri indicazioni precise sulle azioni correttive da intraprendere.
   
5. Rimedio e mitigazione — Applicare le patch fornite dai produttori, implementare patch virtuali tramite regole WAF o IPS, isolare i sistemi vulnerabili o implementare controlli compensativi per i sistemi che non possono essere aggiornati. Le organizzazioni che raggiungono un tasso di rimedio dell'89% entro 30 giorni utilizzano l'automazione e l'orchestrazione per eliminare i ritardi dovuti al passaggio di consegne manuale tra l'identificazione e l'intervento.
   
6. Verifica e monitoraggio — Confermare l'applicazione delle misure correttive tramite nuove scansioni e test. Il monitoraggio continuo individua nuove vulnerabilità e scostamenti nella configurazione tra un ciclo di scansione programmato e l'altro. I risultati della verifica contribuiscono a definire le priorità future e a calibrare gli SLA durante l'intero ciclo di vita.
   

Vulnerabilità comuni gestite dai team di sicurezza

Le vulnerabilità non costituiscono una categoria omogenea; per garantire una copertura completa all'interno di una moderna infrastruttura ibrida, è fondamentale adottare approcci di scansione personalizzati. 

‍

La tabella seguente mette in relazione ciascun tipo di vulnerabilità con il relativo vettore di attacco, gli esempi più comuni e i principali indicatori di priorità

Vulnerabilità di rete

Le vulnerabilità di rete espongono superfici di attacco a livello dell'intera organizzazione che gli aggressori possono sondare senza l'interazione dell'utente. I protocolli non crittografati, le credenziali predefinite sui dispositivi di rete e i servizi di rete privi di patch sono tra le categorie più comunemente sfruttate. Gli scanner basati sulla rete identificano tali vulnerabilità dal punto di vista di un aggressore esterno, mentre le scansioni autenticate offrono una visibilità più approfondita sulle configurazioni errate interne, invisibili alle valutazioni limitate al perimetro.

Vulnerabilità delle applicazioni

Le vulnerabilità delle applicazioni richiedono approcci di test specializzati che vanno oltre la semplice scansione di rete standard. Il SAST individua i difetti a livello di codice durante la fase di sviluppo. Il DAST verifica le applicazioni in esecuzione alla ricerca di punti deboli sfruttabili, tra cui difetti di tipo injection, bypass dell'autenticazione e riferimenti diretti a oggetti non sicuri. L'analisi della composizione del software (SCA) individua le librerie di terze parti vulnerabili, una funzionalità fondamentale poiché le applicazioni moderne includono comunemente centinaia di dipendenze open source con cicli di vita delle vulnerabilità indipendenti.

Vulnerabilità Cloud dei container

I carichi di lavoro Cloud introducono categorie di vulnerabilità che gli strumenti di scansione tradizionali non rilevano. I bucket di archiviazione configurati in modo errato, i ruoli IAM con privilegi eccessivi e le immagini base dei container senza patch richiedono strumenti appositamente progettati: piattaforme CSPM per la valutazione della configurazione, CWPP per la protezione dei carichi di lavoro e la scansione delle immagini dei container integrata nelle pipeline CI/CD prima della distribuzione. Secondo Gartner, il 35% delle applicazioni sarà containerizzato entro il 2029, rendendo la copertura delle vulnerabilità cloud una priorità sempre più importante per i programmi.

Vulnerabilità relative all'identità e all'accesso

Le vulnerabilità relative alle identità vengono sempre più spesso sfruttate come vettori di accesso iniziale. Configurazioni MFA inadeguate, account di servizio con privilegi eccessivi e account vulnerabili al Kerberoast in Active Directory vengono regolarmente sfruttati negli attacchi alle aziende. La gestione delle vulnerabilità relative alle identità richiede l'integrazione tra gli strumenti tradizionali di scansione e quelli dedicati alla sicurezza delle identità, una lacuna che lascia molti programmi con punti ciechi nella loro superficie di attacco a più alto rischio.

La gestione delle vulnerabilità in cifre: statistiche 2024–2025

I dati riportati di seguito riflettono l'attuale portata del problema della vulnerabilità negli ambienti aziendali. Questi indicatori dovrebbero guidare le decisioni relative agli investimenti nei programmi, la definizione degli SLA e la rendicontazione a livello di consiglio di amministrazione sullo stato della sicurezza. Le fonti e gli anni di pubblicazione sono indicati a fini di verificabilità e citazione.

Casi di studio reali sulla gestione delle vulnerabilità aziendali

I casi seguenti illustrano come le carenze nella gestione delle vulnerabilità si traducano in un impatto operativo tangibile. Ciascuno di essi rappresenta una modalità di fallimento distinta — tempistica della divulgazione, esposizione di terze parti e zero-day — e offre un insegnamento diretto per la progettazione dei programmi e la definizione degli SLA.

Log4Shell — sfruttamento a livello globale poche ore dopo la divulgazione pubblica

Il 9 dicembre 2021 è stata resa pubblica una vulnerabilità critica che consente l'esecuzione di codice da remoto (CVE-2021-44228, CVSS 10.0) nella libreria di log Apache Log4j. Nel giro di 72 ore, Checkpoint Research ha identificato oltre 100 diversi gruppi di autori di minacce che sfruttavano attivamente la vulnerabilità su obiettivi esposti a Internet. La CISA ha emesso la Direttiva di Emergenza 22-02 che imponeva a tutte le agenzie civili federali di applicare immediatamente la patch. La vulnerabilità ha colpito centinaia di milioni di dispositivi in tutto il mondo, tra cloud , applicazioni aziendali e sistemi embedded.

La libreria Log4j era integrata in prodotti software di centinaia di fornitori, molti dei quali non disponevano di una visione completa delle loro catene di dipendenze tramite SBOM. Le organizzazioni che effettuavano cicli di scansione trimestrali sono rimaste esposte al rischio per settimane, mentre le patch dei fornitori venivano valutate e testate prima della distribuzione.

Conclusione: nel caso di vulnerabilità ad alto rischio, gli attacchi iniziano già poche ore dopo la loro divulgazione pubblica; i programmi privi di scansioni continue e di avvisi automatici KEV non sono in grado di reagire con la rapidità richiesta dall'evoluzione delle minacce.

MOVEit Transfer — Una violazione a catena causata da terze parti che ha colpito oltre 2.700 organizzazioni

Nel maggio 2023, il gruppo di ransomware Cl0p ha sfruttato una vulnerabilità di tipo SQL injection (CVE-2023-34362) nella piattaforma di trasferimento file MOVEit Transfer di Progress Software prima che il fornitore rendesse pubblica la falla. La violazione ha interessato a catena oltre 2.700 organizzazioni — tra cui agenzie governative, istituzioni finanziarie e sistemi sanitari — esponendo i dati personali di oltre 93 milioni di individui. I costi totali stimati hanno superato i 12 miliardi di dollari (Emsisoft 2024).

L'attacco ha messo in luce i limiti dei programmi di scansione incentrati sul perimetro. Le organizzazioni che non avevano incluso le piattaforme SaaS di terze parti e i servizi di trasferimento file gestito nel proprio ambito di gestione delle vulnerabilità non hanno avuto alcuna visibilità sulla falla fino a quando i dati non erano già stati sottratti.

Conclusione: i software di terze parti e quelli relativi alla catena di approvvigionamento devono essere sottoposti allo stesso rigoroso processo di verifica dei sistemi gestiti internamente; le piattaforme SaaS e i servizi di trasferimento file gestito non sono risorse escluse da tale processo.

Ivanti Connect Secure — zero-day perpetrati da Stati-nazione su oltre 1.700 dispositivi VPN aziendali

Nel gennaio 2024, alcuni attori malintenzionati legati a Stati nazionali hanno sfruttato in sequenza due zero-day presenti negli apparati Ivanti Connect Secure VPN (CVE-2023-46805 e CVE-2024-21887) per ottenere l’esecuzione di codice remoto prima dell’autenticazione. La CISA ha emesso la Direttiva di Emergenza 24-01 pochi giorni dopo la divulgazione della notizia. Prima che fossero disponibili le patch, sono stati compromessi oltre 1.700 dispositivi in tutto il mondo. L'attacco è stato attribuito a UNC5221, un gruppo di hacker legato alla Cina che prende di mira organizzazioni governative e infrastrutture critiche.

La concatenazione di vulnerabilità — una che consentiva di aggirare l'autenticazione e l'altra di eseguire l'iniezione di comandi — ha prodotto un esito di gravità nettamente superiore rispetto a quella di ciascuna delle due vulnerabilità prese singolarmente. Il punteggio CVSS standard attribuito alle singole vulnerabilità non avrebbe segnalato il rischio di sfruttamento combinato prima che l'attività dell'autore dell'attacco lo mettesse in luce.

Conclusione: Zero-day richiede l'adozione di misure di controllo compensative — segmentazione della rete, monitoraggio avanzato e patch virtuali IPS — da attivare immediatamente al momento della segnalazione, non dopo che è stata programmata una finestra di aggiornamento.

Gestione delle vulnerabilità vs. test di penetrazione

La gestione delle vulnerabilità e i test di penetrazione hanno finalità diverse e non dovrebbero sostituirsi a vicenda; si tratta infatti di discipline complementari all'interno di un programma di sicurezza ben consolidato.

La gestione delle vulnerabilità è un processo continuo: identifica e monitora i punti deboli noti su tutte le risorse, stabilisce le priorità degli interventi correttivi in base alla vulnerabilità e al contesto aziendale e misura le prestazioni del programma nel tempo. I test di penetrazione sono periodici e mirati: si tratta di una simulazione strutturata del comportamento di un aggressore, pensata per verificare se le vulnerabilità individuate siano effettivamente sfruttabili, individuare difetti logici che sfuggono agli scanner automatici e testare l'efficacia dei controlli esistenti.

Un programma ben consolidato prevede entrambe le attività. La gestione delle vulnerabilità identifica il perimetro di esposizione. I test di penetrazione verificano se le difese reggono di fronte a un aggressore che agisce attivamente all'interno di tale perimetro.

Perché la gestione delle vulnerabilità è più difficile che mai

Il panorama delle minacce è cambiato in modi che rendono i tradizionali programmi di scansione periodica strutturalmente inadeguati. Tre fattori determinanti definiscono la sfida attuale.

La velocità di sfruttamento ha superato quella dei cicli di ripristino.

Il catalogo KEV della CISA mostra che il 23,6% delle vulnerabilità note oggetto di exploit viene sfruttato già al momento della divulgazione pubblica o prima (CISA KEV 2024), senza lasciare ai responsabili della sicurezza alcun margine di tempo significativo. Gli attacchi moderni combinano sempre più spesso più punti deboli: una configurazione errata di bassa gravità, unita a una vulnerabilità di escalation dei privilegi, può portare alle stesse conseguenze critiche per l'azienda di una singola vulnerabilità classificata come critica.

Le superfici di attacco si sono estese ben oltre la scansione basata sul perimetro. Le violazioni della catena di fornitura introducono vulnerabilità al di fuori del controllo diretto dell'organizzazione. I carichi di lavoro Cloud, i container e le risorse di calcolo effimere aggiungono risorse che gli scanner tradizionali basati su agenti spesso non rilevano. Cloud ha reso l'inventario completo delle risorse un requisito operativo continuo, non più un'attività trimestrale.

Le infrastrutture legacy creano punti di vulnerabilità permanenti. La fine del ciclo di vita di Windows 10, prevista per ottobre 2025, ha lasciato i sistemi privi di aggiornamenti di sicurezza, esponendo in modo permanente le vulnerabilità note per le organizzazioni che non sono in grado di effettuare la migrazione. I sistemi che non possono essere aggiornati richiedono misure di controllo compensative, segmentazione della rete, monitoraggio avanzato e controllo delle applicazioni, al fine di limitare il potenziale di sfruttamento delle vulnerabilità. Si tratta di soluzioni provvisorie, non definitive, che richiedono una gestione attiva e continua.

Quali sono le principali sfide nella gestione della vulnerabilità?

Anche i team dotati di risorse adeguate devono affrontare ostacoli strutturali che si aggravano col passare del tempo. Si tratta di sfide di natura sistemica, non di casi isolati, e non si risolvono semplicemente aggiungendo altri scanner.

Volume degli avvisi e falsa urgenza generata dal CVSS. Solo circa il 16% delle vulnerabilità classificate come "critiche" secondo il CVSS è effettivamente oggetto di attacchi nel mondo reale. Considerare ogni punteggio CVSS "critico" come urgente crea arretrati nella risoluzione dei problemi che finiscono per nascondere le esposizioni realmente ad alto rischio e esauriscono le risorse degli analisti su minacce puramente teoriche.

Lacune di copertura nelle infrastrutture moderne. I carichi di lavoro Cloud, le applicazioni containerizzate e le risorse effimere spesso non vengono rilevati dagli scanner progettati per ambienti statici. Le infrastrutture ibride richiedono strategie di scansione ibride: basate su agenti per i carichi di lavoro dinamici, senza agenti per le risorse statiche e integrate tramite API per cloud .

Coordinamento delle misure correttive su larga scala. La gestione delle vulnerabilità va oltre i confini dei singoli team: il reparto sicurezza individua i problemi, l'IT applica le patch e il reparto tecnico risolve le falle a livello di codice. Senza SLA definiti e senza un'integrazione dei flussi di lavoro, si accumulano arretrati indipendentemente dall'efficacia con cui le vulnerabilità vengono classificate per priorità a monte.

Oneri amministrativi legati ai processi manuali. Il triage manuale, la creazione dei ticket e la generazione dei report assorbono risorse degli analisti che dovrebbero invece concentrarsi sulle indagini e sulla risoluzione dei problemi. I programmi che si basano su processi manuali su larga scala non riescono a chiudere le finestre di vulnerabilità prima che si aprano quelle di sfruttamento.

Come funziona l'automazione della gestione delle vulnerabilità?

L'automazione della gestione delle vulnerabilità riduce il carico di lavoro manuale lungo l'intero ciclo, dall'individuazione alla correzione. La scansione automatizzata identifica continuamente nuove vulnerabilità man mano che le risorse cambiano, senza richiedere finestre di scansione programmate. Le pipeline di arricchimento dei dati mettono in correlazione i risultati delle scansioni con i punteggi EPSS, i feed di intelligence sulle minacce e i dati relativi alla criticità delle risorse, per generare code di correzione ordinate per priorità senza l'intervento di un analista.

Le integrazioni SOAR trasformano i risultati classificati per priorità in ticket inoltrati al team competente in base alla titolarità delle risorse e alle soglie SLA. Le nuove scansioni automatiche verificano l'attuazione delle misure correttive senza necessità di pianificazione manuale. I flussi di reporting generano la documentazione di conformità con cadenza prestabilita.

L'obiettivo non è quello di escludere gli analisti dal processo, bensì di concentrare il loro giudizio sulle decisioni che richiedono competenze umane: valutare i controlli compensativi per i sistemi che non possono essere aggiornati, indagare sui segnali di rilevamento che indicano uno sfruttamento attivo e segnalare i risultati che superano le soglie di rischio aziendali.

Requisiti normativi e di conformità

La gestione delle vulnerabilità garantisce la conformità ai principali quadri normativi, ciascuno dei quali prevede requisiti specifici e obblighi di documentazione. Le organizzazioni devono comprendere tali requisiti per evitare sanzioni e mantenere le certificazioni.

La norma ISO 27001 (A.12.6) richiede processi di gestione delle vulnerabilità tecniche caratterizzati da ruoli ben definiti, valutazioni periodiche e interventi correttivi tempestivi. Le organizzazioni devono documentare le procedure di gestione delle vulnerabilità, rispettare le tempistiche previste per gli interventi correttivi e dimostrare un miglioramento continuo attraverso approcci basati sul rischio in linea con gli obiettivi aziendali.

Le misure tecniche di sicurezza previste dall'HIPAA impongono la gestione delle vulnerabilità al fine di proteggere le informazioni sanitarie protette in formato elettronico (ePHI). I soggetti interessati devono effettuare valutazioni periodiche delle vulnerabilità, applicare tempestivamente le patch e documentare tutte le attività di correzione. La Norma sulla sicurezza richiede una valutazione continua dell'efficacia dei controlli tecnici.

Il requisito 6 dello standard PCI DSS riguarda specificatamente la gestione delle vulnerabilità per le organizzazioni che trattano dati relativi alle carte di pagamento. È obbligatorio effettuare scansioni trimestrali interne ed esterne delle vulnerabilità da parte di fornitori di servizi di scansione approvati (ASV). Le vulnerabilità ad alto rischio devono essere risolte entro un mese, con una nuova scansione per verificare l'efficacia delle correzioni.

Il NIST CSF integra la gestione delle vulnerabilità in diverse funzioni. La funzione "Identify" (ID.RA) prevede l'identificazione delle vulnerabilità, mentre la funzione "Protect" (PR.IP) comprende le attività di correzione. Le organizzazioni che adottano le linee guida del NIST implementano solitamente scansioni automatizzate, monitoraggio continuo e programmi di miglioramento basati su metriche.

Rilevamento e prevenzione delle vulnerabilità

Un rilevamento efficace richiede la combinazione di scansioni continue e monitoraggio comportamentale: gli scanner individuano le vulnerabilità note, mentre i segnali di rilevamento attivo rivelano quali vulnerabilità sono attualmente sotto attacco. Il modello in sette fasi riportato di seguito copre entrambe le dimensioni di un programma completo di rilevamento e prevenzione.

1. Garantire una visibilità continua delle risorse — Mantenere un inventario delle risorse in tempo reale che tenga conto delle infrastrutture cloud, ibride ed effimere. Integrarsi con i CMDB, le API cloud e i sistemi di gestione delle identità. Uno scanner non può valutare ciò che non vede. Le risorse non individuate rappresentano punti ciechi sistematici, non lacune accettabili nel programma.
   
2. Implementare scansioni autenticate su tutte le classi di risorse: le scansioni autenticate offrono una copertura delle vulnerabilità notevolmente più approfondita rispetto alle scansioni non autenticate effettuate dal punto di vista della rete. Configurare le credenziali di scansione per server, workstation, dispositivi di rete e cloud . Integrare il tutto con scansioni basate su agenti per le risorse non raggiungibili dagli scanner di rete tra un ciclo pianificato e l'altro.
   
3. Integra i feed di intelligence sulle minacce e i feed KEV della CISA — Automatizza l'acquisizione degli aggiornamenti KEV della CISA e dei feed di intelligence sulle minacce nella tua pipeline di prioritizzazione. Quando viene pubblicata una voce KEV relativa a una vulnerabilità presente nel tuo ambiente, tale segnalazione dovrebbe essere automaticamente inoltrata al livello SLA più elevato, indipendentemente dal punteggio CVSS. Uno sfruttamento zero-click richiede un inoltro immediato.
   
4. Applicare la prioritizzazione dei rischi basata sull'EPSS — Sostituire o integrare la valutazione iniziale basata esclusivamente sul CVSS con i punteggi EPSS filtrati in base alla criticità delle risorse e al contesto ambientale. Una vulnerabilità con CVSS 7,0 e un EPSS di 0,85 richiede un intervento più urgente rispetto a una con CVSS 9,5 e un EPSS di 0,001. Molti programmi fissano a 0,10 la soglia minima per una risposta prioritaria, calibrata in base al profilo di esposizione delle risorse.
   
5. Automatizza i flussi di lavoro di correzione e l'applicazione degli SLA — Collega i risultati delle analisi delle vulnerabilità, ordinati per priorità, ai sistemi di gestione dei ticket tramite SOAR o integrazione diretta tramite API. Indirizza i ticket in base alla titolarità delle risorse, anziché a una classificazione manuale. Definisci e applica gli SLA per livello: vulnerabilità critiche e attivamente sfruttate entro 24–72 ore, vulnerabilità ad alta gravità entro 7 giorni, vulnerabilità a media gravità entro 30 giorni. Monitora la conformità agli SLA come parametro principale del programma.
   
6. Implementare controlli compensativi per i sistemi che non possono essere aggiornati — Per i sistemi che non possono essere aggiornati immediatamente, implementare la segmentazione della rete, regole WAF e patch virtuali IPS. Documentare formalmente ogni decisione relativa ai controlli compensativi ai fini della conformità. Considerarle misure temporanee con cicli di revisione definiti, non soluzioni permanenti.
   
7. Monitorare i segnali comportamentali indicativi di uno sfruttamento attivo — Integrare i dati relativi alla gestione delle vulnerabilità con gli strumenti di rilevamento e risposta per identificare quali vulnerabilità sono oggetto di uno sfruttamento attivo nel proprio ambiente. Connessioni di rete insolite a servizi vulnerabili, tentativi di escalation dei privilegi a seguito di attività di ricognizione e movimenti laterali da sistemi interessati da CVE sono tutti indicatori di un interesse attivo da parte degli aggressori e dovrebbero determinare una ridefinizione delle priorità delle code di correzione in tempo reale.
   

MITRE ATT&CK per lo sfruttamento delle vulnerabilità

Lo sfruttamento delle vulnerabilità corrisponde direttamente a diverse MITRE ATT&CK . Comprendere quali tecniche utilizzano gli aggressori per sfruttare specifiche categorie di vulnerabilità aiuta i team a configurare la copertura di rilevamento e a verificare che i programmi di scansione coprano le superfici di attacco a più alto rischio. La tabella seguente mette in relazione le tecniche comuni di sfruttamento delle vulnerabilità con i relativi identificatori ATT&CK e gli approcci di rilevamento raccomandati.

In che modo i team di sicurezza verificano quali vulnerabilità sono oggetto di attacchi attivi

La gestione tradizionale delle vulnerabilità individua ciò che potrebbe essere sfruttato. Il rilevamento comportamentale rivela invece ciò che gli aggressori stanno attivamente prendendo di mira nel vostro ambiente in questo preciso momento — e questa distinzione determina dove concentrare gli sforzi di risoluzione.

Attack Signal Intelligence™Vectra AI individua in tempo reale i modelli di exploit negli ambienti di rete, cloud, identità e SaaS, mettendo in correlazione i segnali presenti nell'intera superficie di attacco per rivelare quali vulnerabilità del vostro specifico ambiente siano attualmente nel mirino degli hacker. Secondo IDC, le organizzazioni che utilizzano Vectra AI il 52% in più di potenziali minacce e riducono del 50% il tempo dedicato all'analisi degli avvisi.

Scopri come il rilevamento comportamentale integra il tuo programma di gestione delle vulnerabilità → Scopri la Vectra AI

Priorità basate sul rischio ed EPSS

La tradizionale definizione delle priorità basata sul CVSS spesso genera un sovraccarico di avvisi. Molte vulnerabilità classificate come critiche non vengono mai effettivamente sfruttate, costringendo i team di sicurezza a dedicare risorse di correzione a vulnerabilità che comportano un rischio operativo limitato. La gestione delle vulnerabilità basata sul rischio integra le informazioni sulle minacce, il contesto aziendale e la probabilità di sfruttamento per dare priorità alle vulnerabilità più rilevanti.

La metodologia EPSS prevede la probabilità di sfruttamento tramite modelli di apprendimento automatico che analizzano la disponibilità degli exploit, le caratteristiche delle vulnerabilità e le informazioni fornite dai produttori. L'EPSS viene aggiornato quotidianamente, fornendo previsioni aggiornate sullo sfruttamento con una probabilità compresa tra lo 0 e il 100%. A differenza del CVSS, i punteggi EPSS riflettono il comportamento osservato degli autori degli attacchi e i modelli di sfruttamento previsti, piuttosto che valutazioni teoriche della gravità.

I fattori legati al contesto ambientale incidono in modo significativo sul rischio effettivo. Una vulnerabilità in un sistema di sviluppo isolato comporta un rischio operativo minore rispetto allo stesso difetto in un server di produzione connesso a Internet. La criticità delle risorse, la sensibilità dei dati e i controlli compensativi influenzano tutti le decisioni relative alla definizione delle priorità. Il MITRE ATT&CK aiuta a mappare le vulnerabilità alle tecniche degli aggressori per una definizione delle priorità basata sulle minacce.

‍

Zero-day richiede un flusso di lavoro dedicato. In assenza di patch disponibili, le organizzazioni devono implementare misure di protezione alternative: la segmentazione della rete limita il potenziale impatto, un monitoraggio avanzato rileva i tentativi di sfruttamento e l'applicazione di patch virtuali tramite regole IPS o WAF blocca i modelli di attacco noti.

La tabella seguente illustra il miglioramento della precisione in ciascuna fase della maturità del processo di definizione delle priorità. Questi dati relativi all'accuratezza riflettono le medie calcolate su un ampio insieme di vulnerabilità e possono variare a seconda dell'ambiente, della composizione delle risorse e del profilo delle minacce. Utilizzateli come parametri di riferimento per la calibrazione, non come soglie fisse.

Implementazione di EPSS nel programma VM

L'implementazione dell'EPSS inizia con l'integrazione dei dati. È necessario collegare gli scanner di vulnerabilità agli endpoint API dell'EPSS per ottenere una valutazione automatica. Le vulnerabilità esistenti devono essere associate agli identificatori CVE per consentire la ricerca nell'EPSS. È necessario stabilire delle soglie in base alla tolleranza al rischio dell'organizzazione; molti programmi danno priorità alle vulnerabilità con punteggi EPSS superiori al 10%, sebbene la calibrazione delle soglie debba riflettere la criticità delle risorse e il profilo di esposizione del settore.

Configurare gli strumenti di scansione in modo da includere i punteggi EPSS nei report insieme a quelli CVSS. Modificare i flussi di lavoro di correzione per tenere conto della probabilità EPSS nella definizione degli SLA. Gli analisti devono comprendere che un punteggio EPSS pari a 0,85 indica una probabilità dell'85% che la vulnerabilità venga sfruttata entro 30 giorni, il che è nettamente diverso da un punteggio CVSS pari a 9,0 assegnato a una vulnerabilità per la quale non esistono exploit pubblici. Documentare la metodologia di definizione delle priorità ai fini della conformità e degli audit.

Monitorare l'efficacia dell'EPSS attraverso il monitoraggio degli indicatori. Confrontare i tassi di falsi positivi e il tempo medio necessario per la risoluzione dei problemi prima e dopo l'adozione dell'EPSS. Adeguare le soglie in base all'accuratezza osservata nel proprio ambiente specifico.

Strumenti e tecnologie per la gestione delle vulnerabilità

Le moderne piattaforme di gestione delle vulnerabilità integrano diverse funzionalità per garantire una copertura completa. Valutare le diverse categorie di strumenti aiuta le organizzazioni a scegliere soluzioni in linea con il proprio ambiente e con il livello di maturità del proprio programma.

L'architettura dello scanner influisce in modo significativo sull'implementazione e sull'efficacia. Gli scanner basati su agenti garantiscono una visibilità continua e funzionano bene in ambienti dinamici. Le soluzioni senza agenti riducono la complessità dell'implementazione, ma potrebbero non rilevare le risorse transitorie. La maggior parte delle organizzazioni adotta approcci ibridi che combinano entrambi i metodi. Gli scanner basati sulla rete identificano le vulnerabilità visibili dal punto di vista di un aggressore esterno.

La sicurezza delle applicazioni richiede approcci di test specializzati. Il SAST analizza il codice sorgente alla ricerca di vulnerabilità durante la fase di sviluppo. Il DAST verifica la presenza di falle di sicurezza nelle applicazioni in esecuzione. L'IAST combina entrambi gli approcci per garantire una copertura completa. L'SCA identifica i componenti vulnerabili nelle librerie di terze parti, una funzionalità fondamentale dato che le catene di dipendenze open source sono cresciute in modo sostanziale negli stack applicativi moderni.

La sicurezzaCloud e dei container costituisce un ambito specifico. Le piattaforme CNAPP unificano le funzionalità cloud , compresa la gestione delle vulnerabilità. Il CSPM monitora costantemente cloud alla ricerca di rischi per la sicurezza. Il CWPP protegge i carichi di lavoro negli ambienti ibridi. La scansione dei container identifica le vulnerabilità nelle immagini e nei registri dei container prima della distribuzione.

L'integrazione dell'ecosistema moltiplica l'efficacia dei programmi. Le piattaforme SIEM integrano i dati sulle vulnerabilità con altri eventi di sicurezza per effettuare correlazioni. Le piattaforme SOAR automatizzano i flussi di lavoro di correzione sulla base dei risultati relativi alle vulnerabilità. Gli strumenti ITSM coordinano l'applicazione delle patch con i processi di gestione delle modifiche a livello di team.

Selezionare la piattaforma VM giusta

I criteri decisionali variano in base alle dimensioni dell'organizzazione, alla complessità dell'infrastruttura e al livello di maturità in materia di sicurezza. Le piccole organizzazioni spesso iniziano con una gestione integrata delle vulnerabilità all'interno delle piattaforme endpoint . Le aziende di medie dimensioni richiedono in genere piattaforme dedicate alla gestione delle vulnerabilità dotate di funzionalità di automazione. Le grandi imprese necessitano invece di piattaforme complete in grado di supportare ambienti eterogenei e requisiti di conformità.

La tabella seguente mette a confronto le architetture di scansione più diffuse in base al caso d'uso. La maggior parte dei programmi più consolidati adotta implementazioni ibride, piuttosto che optare per un unico approccio di scansione.

Metriche e KPI per la gestione delle vulnerabilità

Una misurazione efficace favorisce il miglioramento continuo. I quattro indicatori chiave riportati di seguito offrono una panoramica dell'efficacia del programma e costituiscono il punto di riferimento per dimostrare i progressi compiuti alla dirigenza e ai revisori.

Il tempo medio di rilevamento (MTTD) misura il tempo medio che intercorre tra la divulgazione di una vulnerabilità e il suo rilevamento nel proprio ambiente. I programmi più all'avanguardia raggiungono un MTTD inferiore a 24 ore per le risorse critiche grazie alla scansione continua e all'integrazione delle informazioni sulle minacce. Per calcolare l'MTTD, occorre dividere la somma dei tempi di rilevamento per il numero di vulnerabilità rilevate.

Il tempo medio di risoluzione (MTTR) misura il tempo medio che intercorre tra l'individuazione di una vulnerabilità e la sua risoluzione. I valori di riferimento del settore variano in modo significativo: secondo il Tenable Exposure Management Index (2025), le piccole imprese che utilizzano l'automazione registrano un MTTR di 14 giorni, mentre le grandi aziende hanno una media di 30 giorni. L'MTTR si calcola dividendo il tempo totale impiegato per la risoluzione delle vulnerabilità per il numero di vulnerabilità risolte.

Il tasso di copertura garantisce una protezione completa dell’intera infrastruttura. I programmi leader mantengono una copertura delle risorse superiore al 95% grazie al rilevamento automatico e alla scansione continua.

La riduzione del punteggio di rischio dimostra l'impatto del programma sul livello complessivo di sicurezza. È possibile monitorare l'andamento dei punteggi di rischio aggregati nel tempo, misurando la riduzione percentuale su base trimestrale. I programmi efficaci raggiungono una riduzione trimestrale del rischio pari o superiore al 20% rispetto al valore di riferimento iniziale.

Valutazione della maturità del programma VM

I modelli di maturità per la gestione delle vulnerabilità aiutano le organizzazioni a valutare le proprie capacità attuali e a definire piani di miglioramento. Il modello a cinque livelli riportato di seguito illustra percorsi chiari di evoluzione da programmi reattivi a programmi ottimizzati, utilizzando l'MTTR come principale parametro di valutazione.

Livello 1 — Iniziale: i programmi funzionano in modo reattivo, con processi manuali e una copertura non uniforme. Le scansioni vengono eseguite sporadicamente, spesso solo a fini di conformità. Non esiste un processo formale di gestione delle vulnerabilità. Il tempo medio di risoluzione (MTTR) supera i 90 giorni per la maggior parte delle vulnerabilità.

Livello 2 — In fase di sviluppo: sono state definite procedure di automazione di base e pianificazioni regolari delle scansioni. Esiste un inventario delle risorse, ma potrebbe essere incompleto. La definizione delle priorità si basa sui punteggi CVSS. Il tempo medio di risoluzione (MTTR) varia da 60 a 90 giorni. Sono in atto alcune procedure e è presente una certa documentazione.

Livello 3 — Definito: sono stati definiti processi completi e ne viene garantita un'esecuzione coerente. È presente un inventario completo delle risorse con relativa classificazione. La definizione delle priorità tiene conto del contesto aziendale. MTTR compreso tra 30 e 60 giorni. È stata implementata l'integrazione con i processi di gestione delle modifiche.

Livello 4 — Gestito: le metriche e l'automazione guidano l'ottimizzazione dell'intero programma. Scansione continua di tutte le risorse. Definizione avanzata delle priorità tramite EPSS e intelligence sulle minacce. MTTR inferiore a 30 giorni per le vulnerabilità critiche. L'analisi predittiva identifica le tendenze emergenti.

Livello 5 — Ottimizzato: programmi completamente automatizzati e in grado di auto-migliorarsi, con rilevamento delle vulnerabilità in tempo reale e correzione automatica. Definizione delle priorità e risposta basate sull'intelligenza artificiale. MTTR costantemente inferiore a 14 giorni. Miglioramento continuo basato su metriche e sull'evoluzione del panorama delle minacce.

Parametri di riferimento del settore per i programmi VM

I benchmark settoriali forniscono un quadro di riferimento per valutare le prestazioni dei programmi. Le organizzazioni del settore dei servizi finanziari raggiungono in genere un MTTR di 15 giorni, grazie alle pressioni normative e alla disponibilità di risorse. Il settore sanitario registra una media di 25 giorni, trovando un equilibrio tra i requisiti di sicurezza e quelli di disponibilità del sistema. Le organizzazioni del settore retail registrano una media di 30-35 giorni, con variazioni stagionali che influenzano i tempi di risoluzione dei problemi.

Anche le variazioni geografiche incidono sui parametri di riferimento. Le organizzazioni europee dimostrano spesso tempi di risoluzione più rapidi grazie ai requisiti del GDPR. Le organizzazioni nordamericane sono all’avanguardia nell’adozione degli EPSS, ma presentano notevoli differenze nella velocità di risoluzione, il che riflette le differenze nella maturità dei programmi e negli investimenti in strumenti.

Approcci moderni alla gestione delle vulnerabilità

La gestione tradizionale delle vulnerabilità si sta evolvendo verso una riduzione globale dell'esposizione attraverso i modelli di gestione continua dell'esposizione alle minacce (CTEM). Secondo una ricerca di Gartner sul CTEM, entro il 2026 si prevede una significativa riduzione delle violazioni per le organizzazioni che implementeranno programmi CTEM completi.

Il CTEM va oltre la tradizionale analisi delle vulnerabilità per coprire tutti i tipi di esposizione: gestione della superficie di attacco esterna, protezione dai rischi digitali e simulazione di violazioni e attacchi. Il quadro di riferimento pone l'accento sulla convalida continua attraverso esercitazioni basate sull'ipotesi di una violazione e il purple teaming. Le organizzazioni che implementano il CTEM registrano tassi di risoluzione dell'89% entro 30 giorni, superando nettamente i tradizionali approcci periodici.

Il Vulnerability Management as a Service (VMaaS) risolve i problemi legati alla scarsità di risorse attraverso servizi di sicurezza gestiti. I fornitori di VMaaS offrono monitoraggio 24 ore su 24, 7 giorni su 7, analisi da parte di esperti e coordinamento gestito delle misure correttive. Le piccole e medie imprese possono così usufruire di funzionalità di livello aziendale senza dover costituire team interni. I modelli di costo variano da tariffe basate sul singolo asset a servizi gestiti completi.

L'intelligenza artificiale e l'apprendimento automatico migliorano l'accuratezza nella definizione delle priorità analizzando i modelli storici di sfruttamento delle vulnerabilità. L'elaborazione del linguaggio naturale estrae informazioni utili dalle descrizioni delle vulnerabilità e dai rapporti sulle minacce. L'orchestrazione automatizzata delle misure correttive riduce il tempo medio di risoluzione (MTTR) e minimizza gli errori umani nel flusso di lavoro che va dalla valutazione iniziale alla creazione del ticket.

Le architetture Cloud richiedono approcci alla gestione delle vulnerabilità che vanno oltre la tradizionale applicazione di patch al sistema operativo. L'analisi delle immagini dei container identifica le vulnerabilità prima della distribuzione. La protezione in fase di esecuzione monitora il comportamento dei container per individuare eventuali tentativi di exploit. I controller di ammissione di Kubernetes applicano le politiche di sicurezza durante la distribuzione. La gestione dello stato Cloud valuta continuamente cloud incloud .

Vectra AI alla gestione delle vulnerabilità

La gestione tradizionale delle vulnerabilità individua ciò che potrebbe essere sfruttato. Vectra AI invece ciò che viene effettivamente sfruttato: una differenza che cambia il punto su cui concentrare gli sforzi di risoluzione.

Vectra AI la gestione delle vulnerabilità attraverso l'Attack Signal Intelligence™, che rileva in tempo reale i comportamenti di sfruttamento delle vulnerabilità negli ambienti di rete, cloud, identità e SaaS. Quando gli aggressori tentano di ottenere l'accesso, elevano i propri privilegi o si spostano lateralmente, tali comportamenti generano segnali rilevabili. Vectra AI questi segnali all'interno della rete moderna per individuare quali vulnerabilità sono oggetto di attacchi attivi.

L'integrazione con gli strumenti esistenti di gestione delle vulnerabilità amplia ulteriormente queste funzionalità. Grazie alla correlazione tra i risultati delle scansioni e i comportamenti degli aggressori rilevati, i team di sicurezza concentrano gli interventi correttivi sulle vulnerabilità attualmente oggetto di attacchi: meno patch sprecate, un contenimento più rapido e tempi medi di risoluzione più brevi per le vulnerabilità che contano davvero.

Vectra AI la posizione più alta per quanto riguarda la "Capacità di esecuzione" e quella più lontana per quanto riguarda la "Completezza della visione", ed è l'unico fornitore nel rapporto ad essere stato nominato leader nel Magic Quadrant 2025 di Gartner per il Network Detection and Response (NDR), con 35 brevetti nel campo dell'intelligenza artificiale applicata alla sicurezza informatica. Secondo IDC, le organizzazioni che utilizzano Vectra AI il 52% in più di potenziali minacce e riducono del 50% i tempi di analisi degli avvisi.

Per scoprire in che modo il rilevamento comportamentale integra il tuo programma di gestione delle vulnerabilità, esplora la Vectra AI o richiedi una dimostrazione.

Conclusione

La gestione delle vulnerabilità è passata dall'essere una semplice funzione di conformità a diventare un imperativo operativo. Con 40.289 CVE pubblicati nel 2024 e tempi di sfruttamento delle vulnerabilità ridotti a poche ore nei casi più gravi, i programmi basati su scansioni periodiche e sulla sola classificazione CVSS sono strutturalmente incapaci di stare al passo con il panorama delle minacce.

I programmi di sicurezza maturi presentano tre caratteristiche comuni: visibilità continua su tutte le categorie di risorse, inclusi cloud, identità e software di terze parti; definizione delle priorità basata sul rischio, che privilegia la probabilità di sfruttamento e il contesto aziendale rispetto ai punteggi teorici di gravità; e una disciplina di misurazione che monitora MTTD, MTTR, copertura e riduzione del rischio rispetto ai benchmark di settore. I casi reali citati in questa guida — Log4Shell, MOVEit, Ivanti — hanno tutti fallito in almeno una di queste dimensioni.

L'evoluzione verso il CTEM e il rilevamento potenziato dall'intelligenza artificiale offre miglioramenti significativi in termini di capacità, ma i principi fondamentali rimangono immutati: non è possibile proteggere ciò che non si vede, non è possibile stabilire le priorità senza un contesto e non è possibile migliorare senza misurare. La creazione di un programma resiliente di gestione delle vulnerabilità richiede un impegno simultaneo su tutte e tre queste dimensioni.

I team di sicurezza che integrano i dati delle scansioni delle vulnerabilità con i segnali di rilevamento comportamentale — comprendendo non solo quali punti deboli esistono, ma anche quali sono quelli attualmente presi di mira — prendono decisioni di correzione nettamente migliori. È proprio in questa integrazione che la gestione tradizionale delle vulnerabilità e il rilevamento moderno delle minacce trovano un punto di incontro.

Fonti e metodologia

Le statistiche e gli esempi citati nella presente guida sono tratti da rapporti di ricerca di settore, indagini su violazioni della sicurezza e set di dati pubblici relativi alla sicurezza informatica.

• Catalogo VulnCheck KEV (2024)
• Rapporto di Fortinet sul panorama globale delle minacce (2025)
• Rapporto IBM sul costo delle violazioni dei dati (2024)
• Catalogo delle vulnerabilità note e sfruttate (KEV) della CISA
• NVD — Banca dati nazionale delle vulnerabilità (2024)
• Tenable Research (2024)
• Rapporto Mandiant M-Trends (2024)
• Rapporto sulle minacce di Emsisoft (2024)
• Direttiva di emergenza CISA n. 22-02
• Direttiva di emergenza CISA 24-01
• White paper IDC sul valore aziendale, sponsorizzato da Vectra AI 2024)
• Magic Quadrant di Gartner per il rilevamento e la risposta di rete (2025)