Quale patch installare per prima? SSVC, il metodo per decidere le priorità sulle vulnerabilità, con esempi pratici

Quando le vulnerabilità da correggere sono dieci, si correggono tutte. Quando sono cento e la finestra di manutenzione è una sola, bisogna scegliere. Con l'AI che aiuta a trovarne di nuove, come racconta la valutazione dell'NCSC britannico sugli attacchi informatici fino al 2028, scegliere diventa la regola, non l'eccezione.

SSVC è un metodo per fare questa scelta in modo ripetibile. Il nome sta per Stakeholder-Specific Vulnerability Categorization: classificazione delle vulnerabilità in base a chi le deve gestire. L'ha sviluppato nel 2019 il Software Engineering Institute della Carnegie Mellon, dove ha sede il CERT/CC, insieme alla CISA, l'agenzia statunitense per la sicurezza informatica. L'NCSC lo cita come esempio di metodo basato sul rischio per decidere l'ordine in cui installare gli aggiornamenti.

La risposta che SSVC dà non è un punteggio ma una decisione. Nel modello per chi installa le patch, che il CERT/CC chiama deployer, le decisioni possibili sono quattro:

• Rinviare (Defer): per ora non si fa nulla;
• Nella manutenzione programmata (Scheduled): si corregge alla prossima finestra prevista;
• Fuori ciclo (Out-of-Cycle): si corregge, o si mitiga, alla prima occasione utile, prima della prossima finestra, anche con straordinari se serve;
• Subito (Immediate): si concentrano tutte le risorse sulla correzione, il prima possibile, anche fermando le attività normali se serve.

Perché non basta il punteggio CVSS

Il CVSS, il punteggio da 0 a 10 che accompagna ogni vulnerabilità pubblicata, descrive le caratteristiche tecniche della vulnerabilità. Non sa niente della vostra azienda: non sa se il sistema vulnerabile è raggiungibile da Internet o chiuso in una rete interna, né se, quando si ferma, si ferma la produzione o solo una stampante. Due vulnerabilità con lo stesso 9,8 possono richiedere una l'intervento nella notte e l'altra la manutenzione del mese prossimo. SSVC mette nel conto proprio queste informazioni.

Le quattro domande

1. La vulnerabilità è già sfruttata? (Exploitation)

• Nessuna evidenza (None): nessuna prova di attacchi reali e nessun codice dimostrativo pubblico.
• Codice dimostrativo pubblico (Public PoC): esiste un esempio pubblico di come sfruttarla, per esempio in Metasploit o su ExploitDB, oppure il modo di sfruttarla è ben noto.
• Sfruttata attivamente (Active): ci sono prove affidabili e condivise che attaccanti reali la stanno usando.

Questa risposta si trova fuori dall'azienda. La fonte più usata è il catalogo KEV (Known Exploited Vulnerabilities) della CISA: alla versione del 9 novembre 2026 elenca 1.773 vulnerabilità sfruttate attivamente. Se una vulnerabilità è nel KEV, la risposta è sfruttata attivamente. Il contrario non vale: il KEV è curato dalla CISA, arriva con un certo ritardo e non elenca tutto.

2. Il sistema è esposto? (System Exposure)

• Poco (Small): servizio o programma locale, rete molto controllata.
• Con accesso limitato (Controlled): servizio di rete con restrizioni o mitigazioni già in atto. Contano però solo se fermano davvero un attacco, e quindi solo se l'attacco viene rilevato in modo affidabile e in tempo per reagire: una rete interna piatta, dove tutti raggiungono tutto, non basta.
• Aperto (Open): raggiungibile da Internet o da una rete ampia, dove l'accesso non si può limitare.

Questa risposta la può dare solo l'azienda: la stessa vulnerabilità può stare su un firewall esposto e su un server interno.

3. L'attacco si può automatizzare? (Automatable)

Sì se un attaccante può automatizzare in modo affidabile i primi quattro passi di un attacco: ricognizione, preparazione dell'exploit, consegna e sfruttamento. Per il CERT/CC, una vulnerabilità che permette di eseguire codice da remoto o di iniettare comandi va considerata in linea di massima automatizzabile. Se non si sa, la risposta prudente è sì. Per molte vulnerabilità recenti la CISA pubblica questa risposta nelle schede CVE, insieme a quella sullo sfruttamento, attraverso il programma Vulnrichment. È la stessa domanda dell'elemento Automatable del CVSS 4.0, sviluppato insieme a SSVC: il CERT/CC li considera intercambiabili.

4. Che danno farebbe? (Human Impact)

È la combinazione di due valutazioni, anche queste solo dell'azienda.

• Impatto sulla sicurezza delle persone (Safety Impact), su quattro livelli: trascurabile (al massimo ferite lievi), marginale (ferite gravi o un rischio significativo per chi lavora), critico (perdita di vite), catastrofico (più vite perse).
• Impatto sulle attività (Mission Impact), su quattro livelli: degradate solo funzioni non essenziali; bloccate le attività che sostengono una funzione essenziale; una funzione essenziale si ferma più a lungo di quanto si possa accettare; si fermano più funzioni essenziali e l'azienda non riesce più a lavorare.

Le due valutazioni danno quattro livelli di impatto:

• basso: sicurezza trascurabile o marginale, e attività al massimo con il supporto alle funzioni essenziali bloccato;
• medio: sicurezza trascurabile o marginale con una funzione essenziale ferma, oppure sicurezza critica con attività solo degradate;
• alto: sicurezza critica con il supporto alle funzioni essenziali bloccato o una funzione essenziale ferma;
• molto alto: sicurezza catastrofica, oppure azienda ferma.

Se l'impatto sulle attività non si conosce, il CERT/CC suggerisce di partire dal presupposto che, se il sistema viene compromesso, si blocchino le attività che sostengono una funzione essenziale: un software installato in azienda, di solito, serve a qualcosa.

La tabella

Le quattro risposte formano 72 combinazioni, e per ciascuna il CERT/CC indica la decisione. Non serve impararle: il CERT/CC pubblica un calcolatore La CISA ne ha uno per la propria versione, pensata per chi coordina la risposta e con decisioni diverse (Track, Attend, Act): a un'azienda che installa patch serve il modello deployer descritto qui. La logica però si legge in poche righe:

• subito solo in tre casi: vulnerabilità sfruttata, sistema aperto, impatto alto o molto alto (con impatto alto serve anche che l'attacco sia automatizzabile);
• rinviare in 7 casi su 72, solo quando la vulnerabilità non è sfruttata attivamente e l'impatto è basso, con un'unica eccezione a impatto medio su un sistema poco esposto;
• fuori ciclo nella maggior parte dei casi in cui la vulnerabilità è già sfruttata (15 su 24); senza sfruttamento attivo solo in cinque casi estremi, quasi tutti con impatto molto alto e sistema aperto o attacco automatizzabile;
• nella manutenzione programmata in tutti gli altri casi, che sono la maggioranza.

Tre esempi in un'azienda manifatturiera

Il firewall con la VPN per il lavoro da remoto. Esce una vulnerabilità del firewall che permette di eseguire codice da remoto, e qualche giorno dopo entra nel catalogo KEV. Le risposte: sfruttata attivamente, sistema aperto perché la VPN è raggiungibile da Internet, attacco automatizzabile. Chi entra dal firewall arriva a tutta la rete: un ransomware può fermare produzione, amministrazione e spedizioni insieme, cioè impatto molto alto. Decisione: subito. Stimare un impatto più basso porterebbe a fuori ciclo, ma per un apparato che dà accesso a tutta la rete quella stima è quasi sempre ottimista.

Il file server interno. Stesso punteggio CVSS, ma su un file server raggiungibile solo dai PC dell'ufficio, separato dalla rete di produzione, con accessi controllati e registrati. Esiste codice dimostrativo pubblico, ma la vulnerabilità non risulta sfruttata. Le risposte: codice pubblico, esposizione con accesso limitato, attacco automatizzabile. Se si ferma il file server, si ferma l'ufficio amministrativo: una funzione essenziale, impatto medio. Decisione: nella manutenzione programmata. Se però sul file server ci sono anche i disegni e i programmi delle macchine, e fermarlo ferma anche la produzione, l'impatto è molto alto e la decisione diventa fuori ciclo. E va rifatta quando cambiano i dati: se la vulnerabilità entra nel KEV, la stessa combinazione con sfruttata attivamente porta a fuori ciclo.

Il PC di linea che non si può aggiornare. Un pannello operatore di una linea di produzione gira su una versione di Windows fuori supporto, con una vulnerabilità di rete del tipo usato da WannaCry nel 2017 e da molti ransomware dopo. La vulnerabilità è nel KEV (sfruttata attivamente) e si propaga da sola (automatizzabile). Il PC è in una rete di linea separata dall'ufficio da un firewall, ma raggiungibile dalla teleassistenza del costruttore: esposizione con accesso limitato. Poca vale solo per una rete davvero chiusa, senza collegamenti remoti né chiavette USB. Se un attacco lo prende, la linea si ferma (una funzione essenziale) e chi lavora alla macchina deve intervenire con tutta la propria attenzione per riportarla in sicurezza (impatto sulla sicurezza marginale): impatto medio. Decisione: fuori ciclo. Qui la patch esiste, ma il costruttore della macchina non ne autorizza l'installazione. Il CERT/CC però definisce la decisione come applicazione della «mitigazione o correzione»: fuori ciclo vuol dire isolare il PC, chiudere il protocollo vulnerabile, controllare chi raggiunge quella rete, senza aspettare la manutenzione programmata. E vale una regola a parte: le funzioni di sicurezza della macchina non devono dipendere da quel pannello.

Che cosa serve per usarlo

SSVC non richiede strumenti speciali, ma richiede di conoscere i propri sistemi. Due delle quattro risposte, esposizione e impatto, non si trovano in nessun bollettino: vengono dall'inventario. Per questo il lavoro da fare prima è lo stesso che l'NCSC indica per prepararsi all'ondata di patch:

1. Inventario con due colonne in più. Per ogni sistema: è raggiungibile da Internet, solo dalla rete interna con restrizioni, o da una rete isolata? Quali attività si fermano se viene compromesso, e c'è un rischio per chi lavora?
2. Fonti per lo sfruttamento. Il catalogo KEV e gli avvisi del CSIRT Italia, da ricontrollare nei giorni successivi perché lo stato cambia. Per macchine e PC di linea servono anche gli avvisi del costruttore, che dice se e quando la patch si può installare. Fra le vulnerabilità non ancora sfruttate, l'EPSS, la probabilità stimata che vengano sfruttate nei 30 giorni successivi, aiuta a capire quali tenere d'occhio.
3. Tempi scritti per ogni decisione. SSVC dice «fuori ciclo», non «entro tre giorni». Quanto vale ciascuna decisione in ore o giorni lo stabilisce l'azienda, e conviene scriverlo prima di averne bisogno.
4. Una persona che decide. Il metodo rende la scelta ripetibile, ma qualcuno deve dare le quattro risposte e prendersene la responsabilità.

---

Aggiornato al 10 novembre 2026. Le definizioni e la tabella delle decisioni sono quelle del modello deployer pubblicato dal CERT/CC; le traduzioni dall'inglese sono a cura dell'autore. Gli esempi sono illustrativi. Articolo informativo, non consulenza tecnica sul caso specifico.