Nel 2025 il Common Vulnerability Scoring System (CVSS), standard ormai universalmente accettato per la definizione delle vulnerabilit\u00e0 dei software, compie vent\u2019anni. Anche se viene utilizzato da decenni ed \u00e8 arrivato alla quarta generazione (adesso \u00e8 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 \u00e8 necessario sapere sul framework CVSS per proteggere al meglio le risorse IT?<\/p>\n
Secondo i suoi sviluppatori<\/a>, il CVSS \u00e8 uno strumento che consente di descrivere le caratteristiche delle vulnerabilit\u00e0 dei software e definirne il livello di gravit\u00e0. Gestito dal Forum of Incident Response and Security Teams (FIRST), \u00e8 stato pensato per creare un linguaggio comune con cui gli esperti possano intendersi sulle vulnerabilit\u00e0 e per semplificare l\u2019elaborazione automatica dei dati riguardanti i difetti nei software. Quasi tutte le vulnerabilit\u00e0 riportate nei pi\u00f9 importanti database e cataloghi in materia, come CVE<\/a>, EUVD<\/a> o CNNVD<\/a>, sono associate a una valutazione del livello di gravit\u00e0 in base alla scala del framework CVSS.<\/p>\n In genere, la valutazione comprende due parti principali:<\/p>\n Ecco un esempio di valutazione della vulnerabilit\u00e0 CVE-2021-44228 (Log4Shell), che presenta un livello di gravit\u00e0 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)<\/strong><\/p>\n Vediamo di preciso cosa significa: il vettore di attacco agisce tramite una rete, la complessit\u00e0 dell\u2019attacco \u00e8 bassa, non sono richiesti privilegi n\u00e9 l\u2019interazione dell\u2019utente, la vulnerabilit\u00e0 ha una portata che interessa altri componenti di sistema, e gli effetti sulla riservatezza, sull\u2019integrit\u00e0 e sulla disponibilit\u00e0 sono gravi. Una descrizione dettagliata di ogni componente \u00e8 disponibile nelle specifiche delle versioni CVSS 3.1<\/a> e CVSS 4.0<\/a>.<\/p>\n Una parte fondamentale del sistema CVSS \u00e8 il metodo di assegnazione del punteggio, chiamato anche \u201csistema di calcolo\u201d, previsto per entrambe le versioni (4.0<\/a> e 3.1<\/a>). Inserendo informazioni su tutti i componenti del vettore, \u00e8 possibile ottenere automaticamente un punteggio relativo al livello di criticit\u00e0 espresso in cifre.<\/p>\n All\u2019inizio, la metodologia di calcolo si basava su tre gruppi di metriche: Base<\/strong> (Base), Temporal<\/strong> (Temporali) ed Environmental<\/strong> (Ambientali). Il primo gruppo riguardava le caratteristiche essenziali e invariabili di una vulnerabilit\u00e0 ed \u00e8 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\u2019applicazione vulnerabile o la presenza di misure di sicurezza, all\u2019interno dell\u2019infrastruttura aziendale, in grado di mitigare l\u2019impatto di un eventuale attacco. Nella versione 4.0 del CVSS, le metriche Temporal hanno cambiato nome, che \u00e8 diventato Threat<\/strong> (Minacce), ed \u00e8 stato aggiunto un nuovo gruppo di metriche chiamato Supplemental<\/strong> (Supplementari).<\/p>\n Ecco come sono correlate le metriche. I fornitori di software o le aziende di cybersecurity in genere esaminano se una vulnerabilit\u00e0 \u00e8 al livello di criticit\u00e0 Base, definito \u201cCVSS-B\u201d nella specifica della versione 4.0. Inoltre, forniscono una valutazione relativa alla disponibilit\u00e0 e alla divulgazione pubblica di un exploit (CVSS-BT nella versione 4.0 del framework, Temporal in quella 3.1). Dato che quest\u2019ultima valutazione consiste in un punteggio Base modificato, il valore del CVSS-B pu\u00f2 essere maggiore o inferiore a quello del CVSS-BT. Il punteggio Environmental (CVSS-BTE) viene invece calcolato all\u2019interno di una data organizzazione in base al CVSS-BT, con opportune modifiche che tengono conto delle condizioni di utilizzo specifiche del software vulnerabile.<\/p>\n Le prime due versioni del CVSS, rilasciate nel 2005 e nel 2007, non sono quasi pi\u00f9 utilizzate. \u00c8 possibile che alcune vulnerabilit\u00e0 pi\u00f9 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\u00f9 diffusi. Il problema \u00e8 che, in molti casi, i fornitori di software e i database delle vulnerabilit\u00e0 sono lenti a adottare la versione 4.0 e continuano a fornire punteggi basati sul framework CVSS 3.1.<\/p>\n La prima versione del CVSS era incentrata su un concetto fondamentale: quantificare il livello di gravit\u00e0 delle vulnerabilit\u00e0 mediante l\u2019assegnazione 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.<\/p>\n 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\u2019interno di specifiche aziende e in base a particolari condizioni, derivante da uno dei due punteggi precedenti.<\/p>\n Nelle versioni 3.0 e 3.1 del framework \u00e8 stato aggiunto il concetto di Scope (Ambito, ossia le conseguenze su altri componenti del sistema). Inoltre, i parametri legati ai privilegi richiesti e all\u2019interazione dell\u2019utente sono stati definiti con maggior precisione, mentre molti altri sono stati estesi e perfezionati. L\u2019aspetto pi\u00f9 importante \u00e8 che queste versioni hanno cercato di riaffermare il fatto che il framework CVSS valuta il livello di gravit\u00e0 di una vulnerabilit\u00e0, anzich\u00e9 i rischi che pu\u00f2 creare.<\/p>\n Nel caso della versione 4.0, l\u2019intenzione degli sviluppatori era quella di ottimizzare le metriche del CVSS per un\u2019analisi a livello aziendale di come le vulnerabilit\u00e0 possano influire sui rischi, ma di fatto non \u00e8 stata introdotta una metrica apposita per questi ultimi. Il livello di complessit\u00e0 di un attacco \u00e8 stato suddiviso in due componenti distinte: requisiti e complessit\u00e0. Questa distinzione mette in luce la differenza che sussiste tra le difficolt\u00e0 tecniche insite in un attacco e le condizioni e i fattori esterni necessari perch\u00e9 l\u2019attacco vada a buon fine. In sostanza, un difetto che richiede una configurazione specifica e personalizzata sul prodotto vulnerabile avr\u00e0 requisiti di attacco pi\u00f9 elevati e di conseguenza un punteggio CVSS complessivo inferiore.<\/p>\n La metrica Scope, che spesso era interpretata erroneamente e consentiva soltanto di indicare se l\u2019attacco poteva avere o meno conseguenze su altri componenti, \u00e8 stata sostituita. Gli sviluppatori hanno introdotto un concetto pi\u00f9 chiaro, ossia quello di \u201csistemi correlati\u201d, che ora specifica quali aspetti operativi sono interessati dalla vulnerabilit\u00e0. Inoltre, \u00e8 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\u2019impatto di diversi componenti sul punteggio relativo alle minacce \u00e8 stato rivalutato sulla base di un enorme database di vulnerabilit\u00e0 e di dati sugli attacchi sferrati nel mondo reale.<\/p>\n Per gli esperti in cybersecurity, la versione 4.0 del CVSS risulta molto pi\u00f9 pratica e in linea con le esigenze della realt\u00e0 odierna. Attualmente esistono decine di migliaia di vulnerabilit\u00e0, che in molti casi ricevono un punteggio CVSS elevato e in molte organizzazioni vengono quindi segnalate per procedere a una risoluzione immediata. Il problema \u00e8 che i database e i cataloghi delle vulnerabilit\u00e0 continuano a espandersi e il tempo medio necessario per correggere una vulnerabilit\u00e0 \u00e8 pari a quasi sette mesi<\/a>.<\/p>\n Quando si effettua una rivalutazione passando dal framework CVSS 3.1 al framework CVSS 4.0<\/a>, il punteggio Base relativo ai difetti con un livello di gravit\u00e0 compreso tra 4,0 e 9,0 tende ad aumentare leggermente. Invece, nel caso delle vulnerabilit\u00e0 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\u00e0, le metriche Threat ed Environmental hanno ora un peso molto pi\u00f9 grande. A questo proposito, la societ\u00e0 Orange Cyberdefense ha condotto una ricerca<\/a> interessante. Ha considerato il caso di un\u2019azienda che stia monitorando 8.000 vulnerabilit\u00e0 e in cui i team addetti all\u2019IT e alla sicurezza debbano correggere tutti i difetti a cui \u00e8 stato assegnato un punteggio Base superiore a 8 in un arco di tempo prestabilito. A seconda che si tenga conto della divulgazione pubblica dell\u2019exploit (aspetto che modifica le metriche Temporal\/Threat), qual \u00e8 la percentuale di queste 8.000 vulnerabilit\u00e0 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\u00e0 (il 33%, a fronte del 18% nel caso della versione 3.1). Se per\u00f2 si prende in considerazione il fattore della disponibilit\u00e0 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%).<\/p>\n Che differenza c\u2019\u00e8 tra una vulnerabilit\u00e0 \u201ccritica\u201d e una semplicemente pericolosa? La specifica descrive il livello di gravit\u00e0 in formato testo, ma questa modalit\u00e0 non \u00e8 sempre necessaria per definire una vulnerabilit\u00e0:<\/p>\n All\u2019atto pratico, molti fornitori di software descrivono le vulnerabilit\u00e0 in modo creativo, ad esempio modificando le denominazioni o includendo valutazioni o elementi specifici che non sono previsti dal framework CVSS. Un esempio calzante \u00e8 rappresentato dal Patch Tuesday, il secondo marted\u00ec del mese in cui Microsoft rilascia aggiornamenti e correzioni di sicurezza. A giugno, l\u2019azienda ha segnalato nello specifico le vulnerabilit\u00e0 CVE-2025-33064<\/a> e CVE-2025-32710<\/a>. Anche se la prima \u00e8 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.<\/p>\n\n","protected":false},"excerpt":{"rendered":" Scopriamo in dettaglio il framework CVSS (Common Vulnerability Scoring System, il sistema globale di valutazione delle vulnerabilit\u00e0): a cosa serve, come viene applicato e perch\u00e9 il punteggio Base rappresenta soltanto il punto di partenza della valutazione delle vulnerabilit\u00e0.<\/p>\n","protected":false},"author":2722,"featured_media":29831,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2364,2955,2956],"tags":[2982,3882,538,3570,67,584],"class_list":{"0":"post-29830","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"category-smb","10":"tag-ciso","11":"tag-cvss","12":"tag-patch","13":"tag-strategia","14":"tag-suggerimenti","15":"tag-vulnerabilita"},"hreflang":[{"hreflang":"it","url":"https:\/\/www.kaspersky.it\/blog\/cvss-4-base-evolution\/29830\/"},{"hreflang":"ar","url":"https:\/\/me.kaspersky.com\/blog\/cvss-4-base-evolution\/12577\/"},{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/cvss-4-base-evolution\/28320\/"},{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/cvss-4-base-evolution\/31157\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/cvss-4-base-evolution\/40086\/"},{"hreflang":"tr","url":"https:\/\/www.kaspersky.com.tr\/blog\/cvss-4-base-evolution\/13555\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/cvss-4-base-evolution\/53825\/"},{"hreflang":"fr","url":"https:\/\/www.kaspersky.fr\/blog\/cvss-4-base-evolution\/22979\/"},{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/cvss-4-base-evolution\/24009\/"},{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/cvss-4-base-evolution\/32432\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/cvss-4-base-evolution\/29378\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.it\/blog\/tag\/vulnerabilita\/","name":"vulnerabilit\u00e0"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts\/29830","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/users\/2722"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/comments?post=29830"}],"version-history":[{"count":2,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts\/29830\/revisions"}],"predecessor-version":[{"id":29836,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts\/29830\/revisions\/29836"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/media\/29831"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/media?parent=29830"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/categories?post=29830"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/tags?post=29830"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\n
L\u2019evoluzione del framework CVSS<\/h2>\n
In che modo il framework CVSS 4.0 sta cambiando la scala prioritaria delle vulnerabilit\u00e0<\/h2>\n
Critico, elevato e altri livelli<\/h2>\n
\n