Se ti occupi di IT, amministri un server o semplicemente hai iniziato a leggere report di sicurezza, avrai sicuramente incontrato sigle come CVE-2023-XXXX. A prima vista sembrano codici fiscali per software difettosi. In realtà sono molto di più.

Fondamentalmente, le CVE sono l'alfabeto comune della cybersecurity. Senza di esse, ogni azienda chiamerebbe lo stesso bug in modo diverso, creando un caos gestionale immane.

Ma quindi, CVE cosa sono esattamente?

L'acronimo sta per Common Vulnerabilities and Exposures. Tradotto letteralmente: vulnerabilità e esposizioni comuni. Non si tratta di un software o di un tool di scansione, ma di un elenco pubblico di falle di sicurezza informatica già identificate e catalogate.

Immagina un immenso archivio mondiale dove ogni singola falla di sicurezza — che sia in Windows, in un plugin di WordPress o nel firmware di un router cinese — riceve un nome univoco. Questo permette a chiunque (analisti, sistemisti, hacker etici) di parlare la stessa lingua.

Proprio così. Se io ti dico che c'è un problema di "buffer overflow nella gestione dei pacchetti TCP", potremmo intendere due cose diverse. Se ti dico CVE-2021-44228 (la famigerata Log4Shell), sappiamo entrambi esattamente di quale mostro stiamo parlando.

Come viene assegnato un codice CVE?

Non è che qualcuno si sveglia la mattina e decide a caso un numero. Esiste un processo strutturato gestito dalla MITRE Corporation, un'organizzazione non profit che coordina il sistema per conto del governo statunitense.

Tutto parte da una scoperta. Un ricercatore di sicurezza trova un bug, lo segnala al produttore del software e, una volta confermato, viene richiesta l'assegnazione di un ID CVE. Esistono poi i cosiddetti CNA (CVE Numbering Authorities): aziende come Microsoft, Google o Apple che hanno l'autorità di assegnare codici direttamente per i propri prodotti.

Un dettaglio non da poco: il codice è composto dall'anno in cui la vulnerabilità è stata identificata e un numero sequenziale. Semplice, lineare, efficace.

La differenza tra CVE e CVSS (per non fare confusione)

Qui è dove molti inciampano. Spesso si confonde l'identificatore della falla con la misura della sua pericolosità. Il CVE ti dice COSA è il problema; il CVSS ti dice QUANTO è grave.

Il CVSS (Common Vulnerability Scoring System) è quel punteggio che va da 0.0 a 10.0. Se vedi un CVE con un punteggio di 9.8, significa che quella falla è una porta spalancata per gli attaccanti e devi patchare il sistema immediatamente.

Il calcolo del CVSS tiene conto di vari fattori:

  • Vettore di attacco: Il bug è sfruttabile via rete (remoto) o serve l'accesso fisico alla macchina?
  • Complessità: Basta un click su un link o serve una laurea in crittografia per triggerare il problema?
  • Privilegi richiesti: L'attaccante deve essere già loggato come utente o può entrare come ospite anonimo?
  • Impatto: Cosa succede se l'attacco riesce? I dati vengono rubati? Il sistema crasha?

Senza questa metrica, i sistemisti non saprebbero da dove iniziare a lavorare quando escono 50 nuovi bug in un solo giorno.

Perché queste sigle sono vitali per la tua sicurezza?

Se gestisci l'infrastruttura di un'azienda o anche solo il tuo sito web, monitorare le CVE è l'unico modo per non essere sorpresi. Gli hacker non inventano sempre nuovi modi per entrare; spesso usano exploit pubblici basati su CVE vecchie di mesi che qualcuno ha semplicemente dimenticato di aggiornare.

Il flusso tipico è questo: viene pubblicata la CVE → l'attaccante crea uno script per sfruttarla → il tuo sistema, non aggiornato, cade.

Usare un calcolatore CVSS o consultare database come il NVD (National Vulnerability Database) permette di dare priorità agli interventi. Non puoi aggiornare tutto ogni ora, ma puoi decidere di dare precedenza a ciò che ha un impatto critico sulla tua business continuity.

Dove trovare le informazioni sulle CVE?

Il punto di partenza è sempre il sito della MITRE o l'NVD del NIST. Tuttavia, per chi cerca qualcosa di più discorsivo e meno "burocratico", esistono forum di sicurezza e newsletter specializzate che analizzano l'impatto reale delle nuove vulnerabilità.

Esistono anche tool di scansione automatica che confrontano la versione dei tuoi software con il database CVE. Se il tool trova una corrispondenza, ti avvisa: "Attenzione, stai usando la versione X del software Y, che è vulnerabile alla CVE-XXXX".

È un gioco di gatto e topo costante.

Il lato oscuro: l'arma a doppio taglio

C'è chi critica la pubblicazione immediata delle CVE. Il motivo? Rendendo pubblica la falla, si avvisano anche i malintenzionati. È il dilemma della Full Disclosure.

Tuttavia, la storia insegna che nascondere i bug non li risolve. Anzi, spesso li rende più pericolosi perché gli utenti rimangono ignari del rischio mentre un gruppo di hacker scopre la stessa falla in segreto e la usa per anni senza che nessuno se ne accorga.

La trasparenza è l'unica difesa reale. Sapere che esiste una vulnerabilità permette di mitigare il rischio, anche quando la patch ufficiale non è ancora pronta (magari chiudendo una porta specifica del firewall o disabilitando una funzione superflua).

In sintesi: cosa ricordare

Se dovessimo riassumere l'importanza di questo sistema in pochi punti, diremmo che le CVE sono lo standard che permette a tutta la comunità della sicurezza informatica di coordinarsi. Senza di esse, saremmo ciechi.

Ricorda: CVE = Nome del problema. CVSS = Gravità del problema.

La prossima volta che leggerai un avviso di aggiornamento che cita un codice CVE, non ignorarlo. Quel numero è l'indicazione precisa di una falla che qualcuno ha trovato e che, molto probabilmente, qualcuno sta già provando a sfruttare.

L'unica vera protezione? L'aggiornamento costante e l'analisi consapevole dei rischi legati alle proprie tecnologie.