Panoramica sul framework CVSS: come si è evoluto il sistema di valutazione delle vulnerabilità

Nel 2025 il Common Vulnerability Scoring System (CVSS), standard ormai universalmente accettato per la definizione delle vulnerabilità dei software, compie vent’anni. Anche se viene utilizzato da decenni ed è arrivato alla quarta generazione (adesso è in vigore la versione 4.0), questo sistema di classificazione continua a essere applicato in modo non corretto e resta al centro di un vivace dibattito. Cosa è necessario sapere sul framework CVSS per proteggere al meglio le risorse IT?

Il punteggio Base del framework CVSS

Secondo i suoi sviluppatori, il CVSS è uno strumento che consente di descrivere le caratteristiche delle vulnerabilità dei software e definirne il livello di gravità. Gestito dal Forum of Incident Response and Security Teams (FIRST), è stato pensato per creare un linguaggio comune con cui gli esperti possano intendersi sulle vulnerabilità e per semplificare l’elaborazione automatica dei dati riguardanti i difetti nei software. Quasi tutte le vulnerabilità riportate nei più importanti database e cataloghi in materia, come CVE, EUVD o CNNVD, sono associate a una valutazione del livello di gravità in base alla scala del framework CVSS.

In genere, la valutazione comprende due parti principali:

• Una classificazione da 0 a 10 (punteggio del framework CVSS) che indica quanto è grave la vulnerabilità, dove 10 è attribuito a quelle più critiche e pericolose.
• Un vettore, ossia una stringa di testo standardizzata, che descrive le caratteristiche fondamentali della vulnerabilità, ad esempio se può essere sfruttata da remoto tramite una rete o soltanto in locale, se richiede privilegi elevati, quanto è complesso sfruttarla e quali aspetti del sistema vulnerabile può interessare, come la disponibilità, l’integrità o la riservatezza.

Ecco un esempio di valutazione della vulnerabilità CVE-2021-44228 (Log4Shell), che presenta un livello di gravità elevato e viene sfruttata attivamente: Base Score 10.0 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H)

Vediamo di preciso cosa significa: il vettore di attacco agisce tramite una rete, la complessità dell’attacco è bassa, non sono richiesti privilegi né l’interazione dell’utente, la vulnerabilità ha una portata che interessa altri componenti di sistema, e gli effetti sulla riservatezza, sull’integrità e sulla disponibilità sono gravi. Una descrizione dettagliata di ogni componente è disponibile nelle specifiche delle versioni CVSS 3.1 e CVSS 4.0.

Una parte fondamentale del sistema CVSS è il metodo di assegnazione del punteggio, chiamato anche “sistema di calcolo”, previsto per entrambe le versioni (4.0 e 3.1). Inserendo informazioni su tutti i componenti del vettore, è possibile ottenere automaticamente un punteggio relativo al livello di criticità espresso in cifre.

All’inizio, la metodologia di calcolo si basava su tre gruppi di metriche: Base (Base), Temporal (Temporali) ed Environmental (Ambientali). Il primo gruppo riguardava le caratteristiche essenziali e invariabili di una vulnerabilità ed è su questo che si fondava il calcolo del punteggio Base del CVSS. Il secondo gruppo prendeva in considerazione le caratteristiche che cambiano col passare del tempo, come la divulgazione pubblica di un codice exploit. Il terzo gruppo era pensato per essere utilizzato internamente dalle aziende e teneva conto di fattori specifici legati al contesto, come la portata dell’applicazione vulnerabile o la presenza di misure di sicurezza, all’interno dell’infrastruttura aziendale, in grado di mitigare l’impatto di un eventuale attacco. Nella versione 4.0 del CVSS, le metriche Temporal hanno cambiato nome, che è diventato Threat (Minacce), ed è stato aggiunto un nuovo gruppo di metriche chiamato Supplemental (Supplementari).

Ecco come sono correlate le metriche. I fornitori di software o le aziende di cybersecurity in genere esaminano se una vulnerabilità è al livello di criticità Base, definito “CVSS-B” nella specifica della versione 4.0. Inoltre, forniscono una valutazione relativa alla disponibilità e alla divulgazione pubblica di un exploit (CVSS-BT nella versione 4.0 del framework, Temporal in quella 3.1). Dato che quest’ultima valutazione consiste in un punteggio Base modificato, il valore del CVSS-B può essere maggiore o inferiore a quello del CVSS-BT. Il punteggio Environmental (CVSS-BTE) viene invece calcolato all’interno di una data organizzazione in base al CVSS-BT, con opportune modifiche che tengono conto delle condizioni di utilizzo specifiche del software vulnerabile.

L’evoluzione del framework CVSS

Le prime due versioni del CVSS, rilasciate nel 2005 e nel 2007, non sono quasi più utilizzate. È possibile che alcune vulnerabilità più recenti presentino un punteggio CVSS basato sulle versioni meno recenti, ma attualmente i framework CVSS 3.1 (2019) e CVSS 4.0 (2023) sono i più diffusi. Il problema è che, in molti casi, i fornitori di software e i database delle vulnerabilità sono lenti a adottare la versione 4.0 e continuano a fornire punteggi basati sul framework CVSS 3.1.

La prima versione del CVSS era incentrata su un concetto fondamentale: quantificare il livello di gravità delle vulnerabilità mediante l’assegnazione di un punteggio, inizialmente suddiviso nelle metriche Base, Temporal ed Environmental. In quella fase, le descrizioni testuali non erano state formalizzate con esattezza e il punteggio era calcolato in modo distinto per i tre gruppi di metriche.

Il framework CVSS 2.0 ha poi introdotto un vettore standardizzato e ha cambiato la logica di fondo, prevedendo quanto segue: un punteggio Base obbligatorio e invariato; un punteggio Temporal calcolato sul precedente, tenendo conto della variazione di alcuni fattori; e un punteggio Environmental, utilizzato all’interno di specifiche aziende e in base a particolari condizioni, derivante da uno dei due punteggi precedenti.

Nelle versioni 3.0 e 3.1 del framework è stato aggiunto il concetto di Scope (Ambito, ossia le conseguenze su altri componenti del sistema). Inoltre, i parametri legati ai privilegi richiesti e all’interazione dell’utente sono stati definiti con maggior precisione, mentre molti altri sono stati estesi e perfezionati. L’aspetto più importante è che queste versioni hanno cercato di riaffermare il fatto che il framework CVSS valuta il livello di gravità di una vulnerabilità, anziché i rischi che può creare.

Nel caso della versione 4.0, l’intenzione degli sviluppatori era quella di ottimizzare le metriche del CVSS per un’analisi a livello aziendale di come le vulnerabilità possano influire sui rischi, ma di fatto non è stata introdotta una metrica apposita per questi ultimi. Il livello di complessità di un attacco è stato suddiviso in due componenti distinte: requisiti e complessità. Questa distinzione mette in luce la differenza che sussiste tra le difficoltà tecniche insite in un attacco e le condizioni e i fattori esterni necessari perché l’attacco vada a buon fine. In sostanza, un difetto che richiede una configurazione specifica e personalizzata sul prodotto vulnerabile avrà requisiti di attacco più elevati e di conseguenza un punteggio CVSS complessivo inferiore.

La metrica Scope, che spesso era interpretata erroneamente e consentiva soltanto di indicare se l’attacco poteva avere o meno conseguenze su altri componenti, è stata sostituita. Gli sviluppatori hanno introdotto un concetto più chiaro, ossia quello di “sistemi correlati”, che ora specifica quali aspetti operativi sono interessati dalla vulnerabilità. Inoltre, è stata aggiunta una serie di indicatori supplementari, come il fatto che un exploit possa essere automatizzato e quali possono essere le conseguenze di un attacco sulla sicurezza fisica delle persone. Le formule stesse sono state notevolmente modificate. L’impatto di diversi componenti sul punteggio relativo alle minacce è stato rivalutato sulla base di un enorme database di vulnerabilità e di dati sugli attacchi sferrati nel mondo reale.

In che modo il framework CVSS 4.0 sta cambiando la scala prioritaria delle vulnerabilità

Per gli esperti in cybersecurity, la versione 4.0 del CVSS risulta molto più pratica e in linea con le esigenze della realtà odierna. Attualmente esistono decine di migliaia di vulnerabilità, che in molti casi ricevono un punteggio CVSS elevato e in molte organizzazioni vengono quindi segnalate per procedere a una risoluzione immediata. Il problema è che i database e i cataloghi delle vulnerabilità continuano a espandersi e il tempo medio necessario per correggere una vulnerabilità è pari a quasi sette mesi.

Quando si effettua una rivalutazione passando dal framework CVSS 3.1 al framework CVSS 4.0, il punteggio Base relativo ai difetti con un livello di gravità compreso tra 4,0 e 9,0 tende ad aumentare leggermente. Invece, nel caso delle vulnerabilità considerate molto gravi secondo la versione 3.1 del CVSS, spesso il punteggio rimane invariato o addirittura risulta inferiore. E soprattutto, se la metrica Temporal prima influiva in minima parte sul punteggio di una vulnerabilità, le metriche Threat ed Environmental hanno ora un peso molto più grande. A questo proposito, la società Orange Cyberdefense ha condotto una ricerca interessante. Ha considerato il caso di un’azienda che stia monitorando 8.000 vulnerabilità e in cui i team addetti all’IT e alla sicurezza debbano correggere tutti i difetti a cui è stato assegnato un punteggio Base superiore a 8 in un arco di tempo prestabilito. A seconda che si tenga conto della divulgazione pubblica dell’exploit (aspetto che modifica le metriche Temporal/Threat), qual è la percentuale di queste 8.000 vulnerabilità effettive che rientrerebbe nella categoria? Secondo lo studio di Orange Cyberdefense, la versione di base del framework CVSS 4.0 assegna un punteggio pari a 8 o superiore a una percentuale maggiore di vulnerabilità (il 33%, a fronte del 18% nel caso della versione 3.1). Se però si prende in considerazione il fattore della disponibilità degli exploit, la percentuale subisce una drastica riduzione, indicando come prioritaria la correzione di un numero inferiore di difetti realmente critici (8% a fronte del 10%).

Critico, elevato e altri livelli

Che differenza c’è tra una vulnerabilità “critica” e una semplicemente pericolosa? La specifica descrive il livello di gravità in formato testo, ma questa modalità non è sempre necessaria per definire una vulnerabilità:

• Livello di gravità basso: 0,1–3,9
• Livello di gravità medio: 4,0–6,9
• Livello di gravità elevato: 7,0–8,9
• Livello di gravità critico: 9,0–10,0

All’atto pratico, molti fornitori di software descrivono le vulnerabilità in modo creativo, ad esempio modificando le denominazioni o includendo valutazioni o elementi specifici che non sono previsti dal framework CVSS. Un esempio calzante è rappresentato dal Patch Tuesday, il secondo martedì del mese in cui Microsoft rilascia aggiornamenti e correzioni di sicurezza. A giugno, l’azienda ha segnalato nello specifico le vulnerabilità CVE-2025-33064 e CVE-2025-32710. Anche se la prima è definita di livello importante e la seconda di livello critico, i rispettivi punteggi sono pari a 8,8 e 8,1 secondo il framework CVSS 3.1.