Quando viene pubblicata una nuova vulnerabilità, in azienda la conversazione tende a concentrarsi su una sigla e un numero: il codice CVE e il punteggio di gravità. Sono informazioni indispensabili, ma non dicono ancora se quel problema riguarda davvero i sistemi utilizzati, se è già sfruttato, quale processo espone e chi deve chiuderlo.
Il 6 agosto 2026 ENISA ha annunciato l’ampliamento del proprio ruolo nel programma CVE: sotto la sua struttura Root operano ora 20 CVE Numbering Authorities, 12 inserite direttamente dall’Agenzia e 8 trasferite dalla Root MITRE. Il punto non è soltanto istituzionale. Una rete più distribuita di soggetti capaci di assegnare identificatori e pubblicare record può migliorare tempestività, coerenza e coordinamento delle informazioni sulle vulnerabilità.
Per le imprese, però, una migliore infrastruttura informativa produce valore solo se alimenta un processo interno. Il CVE identifica il problema; la remediation richiede inventario, contesto, priorità, responsabilità, test e prova della chiusura.
Che cosa risolve il CVE e che cosa resta all’impresa
Il programma Common Vulnerabilities and Exposures assegna un identificatore univoco a una vulnerabilità resa pubblica. In questo modo produttori, ricercatori, team di sicurezza, fornitori e clienti possono riferirsi allo stesso problema senza dipendere da descrizioni diverse.
ENISA è diventata CVE Root per le entità europee nel novembre 2025. In questo ruolo forma e supporta le autorità CNA comprese nel proprio perimetro, favorisce l’assegnazione degli identificatori e verifica l’applicazione delle regole del programma. La crescita comunicata ad agosto rafforza quindi una componente della gestione europea delle vulnerabilità, ma non trasferisce all’Agenzia le decisioni operative di ogni azienda.
Un record CVE, da solo, non conosce l’architettura dell’impresa. Non sa se la versione vulnerabile è installata, se il componente è esposto a Internet, se esistono controlli compensativi, se il sistema sostiene un servizio critico o se una patch interromperebbe la produzione. Queste informazioni devono essere collegate all’inventario tecnico e ai processi aziendali.
La priorità non coincide con il punteggio più alto
Ordinare tutte le vulnerabilità soltanto per gravità può generare due errori opposti: rincorrere problemi critici che non sono presenti nell’ambiente e trascurare vulnerabilità meno appariscenti ma già sfruttate su sistemi esposti.
La European Vulnerability Database, sviluppata da ENISA in attuazione della NIS2, aggrega informazioni e consente di consultare elementi come gravità, probabilità di sfruttamento, prodotti coinvolti e indicazioni sull’exploitation nota. Sono segnali utili, non un motore automatico di decisione.
Una priorità aziendale credibile combina almeno cinque fattori:
- presenza effettiva del prodotto e della versione vulnerabile;
- esposizione del sistema e possibilità concreta di raggiungerlo;
- esistenza di sfruttamento noto o di tecniche disponibili;
- impatto sul processo, sui dati e sulla continuità operativa;
- disponibilità di patch, mitigazioni e controlli compensativi.
Il punteggio tecnico resta una base comune, ma deve essere arricchito dal contesto. Una vulnerabilità può essere grave in astratto e irrilevante per un’organizzazione che non usa il componente. Al contrario, un difetto con punteggio inferiore può meritare un intervento immediato se interessa un servizio pubblico, un accesso remoto o una dipendenza condivisa da più applicazioni.
Dall’identificatore alla catena di responsabilità
La Coordinated Vulnerability Disclosure descritta da ENISA è un processo multiparte: ricercatori, coordinatori, produttori e fornitori collaborano affinché la divulgazione avvenga dopo la preparazione di una correzione o di una mitigazione. All’interno dell’impresa serve una catena altrettanto chiara.
Il team di sicurezza può raccogliere e valutare la segnalazione, ma spesso non controlla l’applicazione. Il proprietario del servizio deve indicare l’impatto operativo; l’infrastruttura o il fornitore deve predisporre l’intervento; chi governa la continuità deve approvare finestre e rollback; il procurement deve far valere tempi e obblighi contrattuali quando il componente è gestito da terzi.
Per ogni vulnerabilità rilevante dovrebbe quindi esistere un ticket o un record operativo con almeno: asset coinvolto, proprietario, fonte dell’informazione, decisione motivata, azione prevista, scadenza interna, dipendenze, prova del test e stato finale. Se la correzione viene rinviata, il rischio residuo e il controllo compensativo devono essere espliciti, con una data di riesame.
Inventario e dipendenze: il punto in cui il processo spesso si rompe
Sapere che esiste un CVE non basta se l’azienda non sa dove si trova il componente vulnerabile. Il problema è particolarmente evidente nelle dipendenze software: una libreria può essere inclusa in un’applicazione, in un’appliance, in un’immagine container o in un servizio acquistato senza comparire nell’inventario tradizionale.
Per questo la gestione delle vulnerabilità deve collegarsi a tre mappe: asset tecnici, servizi aziendali e fornitori. La prima indica sistemi, versioni e configurazioni; la seconda mostra quali processi dipendono da quegli asset; la terza chiarisce chi può intervenire e con quali tempi.
Una Software Bill of Materials può aiutare a riconoscere le componenti presenti nei prodotti, ma non risolve da sola il problema. Deve essere aggiornata, confrontabile con le fonti di vulnerabilità e associata alle versioni realmente distribuite. Un elenco statico conservato in un fascicolo non è gestione: è documentazione non ancora collegata al rischio.
Una procedura minima in sei passaggi
Il Cybersecurity Framework 2.0 del NIST inquadra la sicurezza come gestione continua del rischio, non come somma di interventi isolati. Applicato alle vulnerabilità, questo principio può tradursi in una procedura essenziale:
1. raccogliere informazioni da fonti affidabili e normalizzarle su identificatori comuni;
2. verificare se prodotti, versioni e dipendenze sono realmente presenti;
3. stimare la priorità con esposizione, sfruttamento, impatto e controlli esistenti;
4. assegnare proprietario, azione, tempo interno e percorso di escalation;
5. testare patch o mitigazione, prevedendo rollback e continuità del servizio;
6. verificare la chiusura con una nuova scansione o un controllo tecnico, conservando l’evidenza.
La metrica utile non è soltanto quante vulnerabilità sono state rilevate. Contano anche il tempo tra pubblicazione e valutazione, la quota di asset coperti dall’inventario, il rispetto dei tempi interni per classe di rischio, le eccezioni scadute e il numero di correzioni effettivamente verificate.
Le domande da inserire nei contratti con i fornitori
La gestione si complica quando software e infrastruttura sono affidati a terzi. In fase di acquisto o rinnovo conviene chiedere come il fornitore riceve e pubblica le segnalazioni, quali identificatori usa, come comunica i prodotti e le versioni coinvolte, in quali tempi rende disponibili patch o mitigazioni e quale supporto offre in caso di sfruttamento attivo.
Servono anche un canale di escalation, regole per i componenti open source incorporati, accesso alle informazioni sulla composizione software quando pertinente e una procedura per i prodotti non più supportati. “Monitoriamo le vulnerabilità” è una promessa generica; un processo verificabile indica fonti, ruoli, tempi e prove.
La crescita del ruolo ENISA nel programma CVE rafforza una base comune europea per identificare e coordinare le vulnerabilità. Per le imprese è un segnale importante, non una delega. Il risultato si misura quando un identificatore raggiunge l’asset giusto, attiva un responsabile, produce una decisione motivata e termina con una correzione verificata.
Nota di trasparenza: questo articolo e le immagini collegate sono stati realizzati in parte con l’utilizzo dell’intelligenza artificiale, con supervisione e responsabilità editoriale umana.