La Cybersecurity and Infrastructure Security Agency (CISA) ha annunciato che, a fine settembre, interromperà la pubblicazione dei Vulnerability Bulletin settimanali: i roundup che, dal 2004, elencavano le nuove vulnerabilità con CVE, punteggi di severità e sintesi. Non è un ritiro dalla divulgazione tecnica: è un cambio di metodo nella gestione della coda di rischio.
Contenuto informativo basato su comunicazioni CISA e reportistica di settore. Non sostituisce una valutazione di rischio sul perimetro specifico della vostra organizzazione.
Cosa viene chiuso (e cosa resta)
Viene dismesso il formato «elenco settimanale di tutto ciò che è uscito». Restano due strumenti che contano di più in produzione:
- Advisories su vulnerabilità specifiche, quando il contesto lo richiede;
- il catalogo Known Exploited Vulnerabilities (KEV), che segnala falle con evidenza di sfruttamento nel mondo reale.
In sintesi: meno rumore aggregato, più segnali collegati a sfruttamento ed esposizione.
Il passaggio: da severità a rischio
La CISA colloca la chiusura del bulletin nel percorso già avviato verso una gestione basata sul rischio, non sul solo punteggio di severità. A luglio ha pubblicato linee guida di remediation per le agenzie federali con scadenze legate a criteri concreti — tra cui se l’asset è raggiungibile da Internet e se lo sfruttamento può essere automatizzato. Le linee guida vincolano il perimetro federale USA; per imprese e operatori privati restano un riferimento metodologico utile, da adattare al proprio contesto.
Il messaggio operativo, ripetuto anche in contesti pubblici dall’agenzia, è lineare: non tutte le vulnerabilità pesano allo stesso modo per la vostra organizzazione. Un CVE «alto» su un sistema isolato non è automaticamente più urgente di un CVE «medio» su un servizio esposto, autenticato debolmente o già presente nel KEV.
CVSS e SSVC: strumenti diversi
Il CVSS resta utile come linguaggio comune di severità tecnica. Non è, da solo, un piano di patching. La CISA spinge l’uso di framework come lo SSVC (Stakeholder-Specific Vulnerability Categorization): decisioni di priorità che tengono conto di evidenza di exploitation, impatto sul servizio e contesto dello stakeholder, non solo del numero sul report dello scanner.
Per una PMI o un team IT con risorse limitate, la differenza pratica è questa: smettere di trattare «tutte le Critical della settimana» come un blocco unico e costruire una coda ordinata su asset critici, esposizione e prove di sfruttamento.
Cosa fare in azienda (checklist breve)
- Inventario minimo: servizi internet-facing, appliance di gestione, VPN, mail gateway, hypervisor, identity provider.
- Allinea la coda di patch al KEV (e agli advisory vendor) prima di inseguire ogni nuova CVE generica.
- Separa severità e urgenza: CVSS alto + asset non esposto ≠ priorità automatica; KEV + esposizione = intervento pianificato subito.
- Documenta criteri: chi decide, in quanti giorni, con quale rollback — così il patching non dipende dalla «newsletter della settimana».
Dove si collega nel percorso ITSOS
Senza una fotografia dell’esposizione, la prioritizzazione resta teorica. Per uno stato di fatto misurabile: Audit / Security Status Report. Per chiudere le aperture dopo l’assessment: Hardening. Per monitoraggio continuo su sistemi concordati: 003 Intelligence.
Fonti
- Cybersecurity Dive — sintesi dell’annuncio e del contesto di prioritizzazione.
- Comunicazione CISA (GovDelivery) — dichiarazione sulla chiusura del Vulnerability Bulletin.
- CISA Known Exploited Vulnerabilities Catalog.
- CISA — SSVC.
Prossimo passo
Se la coda CVE è lunga e le priorità non sono scritte, conviene partire dall’esposizione reale — non dall’ultimo elenco aggregato. Contatti: itsos.it/contatti · hub: Cybersecurity.