Cos'è davvero un CVSS score?

Se lavori nella sicurezza informatica o gestisci l'infrastruttura di un'azienda, avrai incontrato centinaia di volte la dicitura cvss score: seguita da un numero tra 0.0 e 10.0. A prima vista sembra semplice: più alto è il numero, più grave è il problema. Ma ridurre la sicurezza a una scala numerica è un rischio.

Il Common Vulnerability Scoring System (CVSS) non è un giudizio assoluto sulla pericolosità di un bug, ma un framework standardizzato per valutare le caratteristiche di una vulnerabilità. In parole povere, ci dice potenzialmente quanto sia grave un problema, non necessariamente quanto lo sia per il tuo specifico server in questo preciso momento.

C'è una differenza enorme tra una vulnerabilità con score 9.8 che risiede in un sistema isolato senza accesso a internet e una da 6.5 che colpisce l'endpoint principale della tua applicazione web. Proprio così.

La scomposizione del punteggio: non tutto è Base Score

Quando leggi un report di vulnerabilità, quasi sempre vedi il Base Score. È il valore che definisce le qualità intrinseche della falla. Non cambia nel tempo e non dipende dall'ambiente in cui si trova il software.

Il calcolo si basa su diverse metriche. Ad esempio, l'Attack Vector (AV) ci dice se l'attaccante deve essere seduto fisicamente davanti al PC o se può agire da remoto. Ovviamente, un attacco via rete è molto più preoccupante di uno che richiede l'accesso fisico.

Poi c'è la Complexity. Alcuni exploit sono "point-and-click", altri richiedono condizioni temporali millimetriche per funzionare. Un dettaglio non da poco che sposta drasticamente il rischio reale.

Ma fermiamoci un attimo. Il Base Score è solo l'inizio. Per avere un quadro completo servono altre due dimensioni:

  • Temporal Score: questo valore cambia nel tempo. Se viene rilasciata una patch ufficiale o se appare un exploit pubblico su GitHub, il punteggio temporale si aggiorna.
  • Environmental Score: è qui che entra in gioco l'analista. Permette di personalizzare il punteggio in base all'importanza del sistema colpito per l'organizzazione.

Senza queste due variabili, stai navigando a vista.

I livelli di severità: dove tracciare la linea?

La scala CVSS divide i punteggi in categorie. Generalmente, un cvss score tra 0.1 e 3.9 è considerato Low, da 4.0 a 6.9 Medium, da 7.0 a 8.9 High e da 9.0 a 10.0 Critical.

Il problema sorge quando i team IT iniziano a patchare solo i Critical. È l'errore più comune. Molti attaccanti concatenano diverse vulnerabilità "Medium" per ottenere un controllo totale del sistema. Questa tecnica, chiamata exploit chaining, rende i punteggi bassi pericolosi quanto uno alto se non vengono gestiti.

Immagina una porta blindata (Critical) ma con una finestra aperta in bagno (Medium). L'attaccante non proverà a sfondare la porta; entrerà dalla finestra.

Perché il CVSS score può essere ingannevole

Il sistema è potente, ma ha dei limiti. Uno dei principali è che non tiene conto della probabilità di accadimento. Il CVSS misura l'impatto e le caratteristiche, non la frequenza con cui un attacco viene tentato nel mondo reale.

Esistono vulnerabilità con score altissimi che rimangono teoriche per anni perché richiedono condizioni impossibili da replicare in produzione. Al contrario, bug "banali" vengono sfruttati ogni giorno perché sono facili e scalabili.

Per questo motivo, chi si occupa di sicurezza oggi preferisce integrare il CVSS con altri sistemi, come l'EPSS (Exploit Prediction Scoring System), che prova a prevedere la probabilità che una vulnerabilità venga effettivamente sfruttata nei prossimi 30 giorni.

Come prioritizzare le patch senza impazzire

Non puoi risolvere tutto subito. È matematicamente impossibile in aziende con migliaia di asset. Quindi, come usare il punteggio per decidere cosa fare lunedì mattina?

Il primo passo è mappare l'asset. Se il software vulnerabile gestisce dati sensibili o è esposto pubblicamente, quel cvss score: 7.5 diventa improvvisamente una priorità assoluta, superando magari un 9.0 di un sistema di test interno.

Un altro criterio fondamentale è la disponibilità dell'exploit. Se esiste un modulo di Metasploit pronto all'uso per quella vulnerabilità, il tempo di reazione deve essere immediato. Non importa se lo score è "solo" Medium: l'arma è già nelle mani dei malintenzionati.

L'approccio corretto non è seguire ciecamente un numero, ma usare quel numero come punto di partenza per un'analisi di rischio contestualizzata.

Il calcolo manuale e gli strumenti di analisi

Calcolare a mano ogni metrica sarebbe un incubo burocratico. Per questo esistono i calcolatori CVSS, che permettono di inserire i parametri (come l'impatto sulla riservatezza o l'integrità) e ottenere istantaneamente il punteggio finale.

Usare uno strumento dedicato permette di simulare scenari diversi. Cosa succede se cambio l'Attack Vector da Network a Local? Come cambia il rischio se l'utente deve avere privilegi amministrativi per eseguire l'attacco?

Queste domande sono essenziali durante una valutazione della sicurezza o un penetration test. Permettono di spiegare al management perché certe vulnerabilità richiedono budget e tempo per essere risolte, trasformando un numero astratto in un rischio aziendale concreto.

Oltre il numero: la cultura della mitigazione

In definitiva, l'ossessione per lo score perfetto può portare a una falsa sensazione di sicurezza. "Abbiamo risolto tutti i Critical, siamo al sicuro". No, non lo siete.

La vera sicurezza nasce dalla difesa in profondità. Anche se un bug ha uno score basso, implementare correttamente il principio del least privilege o segmentare la rete può rendere quell'exploit inutile. In questo modo, riduci l'impatto reale indipendentemente dal valore numerico assegnato dal framework CVSS.

Il punteggio è una bussola, non la mappa completa. Usalo per orientarti, ma tieni sempre gli occhi aperti sull'intero orizzonte della tua infrastruttura.