{"id":53825,"date":"2025-07-15T11:28:55","date_gmt":"2025-07-15T15:28:55","guid":{"rendered":"https:\/\/www.kaspersky.com\/blog\/?p=53825"},"modified":"2025-07-15T11:28:55","modified_gmt":"2025-07-15T15:28:55","slug":"cvss-4-base-evolution","status":"publish","type":"post","link":"https:\/\/www.kaspersky.com\/blog\/cvss-4-base-evolution\/53825\/","title":{"rendered":"All about CVSS: how vulnerability scoring evolved"},"content":{"rendered":"<p>This year marks the 20<sup>th<\/sup> anniversary of the Common Vulnerability Scoring System (CVSS), which has become a widely accepted standard for describing software vulnerabilities. Despite decades of use and four generations of the standard \u2014 now at version 4.0 \u2014 CVSS scoring rules continue to be misused, and the system itself remains the subject of intense debate. So, what do you need to know about CVSS to effectively protect your IT assets?<\/p>\n<h2>The CVSS Base Score<\/h2>\n<p>According to its <a href=\"https:\/\/www.first.org\/cvss\/v4-0\/faq\" target=\"_blank\" rel=\"nofollow noopener\">developers<\/a>, CVSS is a tool for describing the characteristics and severity of software vulnerabilities. CVSS is maintained by the Forum of Incident Response and Security Teams (FIRST). It was created to help experts speak a common language about vulnerabilities, and to facilitate automatic processing of data on software flaws. Almost every vulnerability published in major vulnerability registries like <a href=\"https:\/\/www.cve.org\/\" target=\"_blank\" rel=\"nofollow noopener\">CVE<\/a>, <a href=\"https:\/\/euvd.enisa.europa.eu\/\" target=\"_blank\" rel=\"nofollow noopener\">EUVD<\/a>, or <a href=\"https:\/\/www.cnnvd.org.cn\/\" target=\"_blank\" rel=\"nofollow noopener\">CNNVD<\/a> includes a severity assessment based on the CVSS scale.<\/p>\n<p>An assessment typically consists of two main parts:<\/p>\n<ul>\n<li>A numerical rating (CVSS score), which shows how severe the vulnerability is on a scale from 0 to 10. A score of 10 means it\u2019s an extremely dangerous, critical vulnerability.<\/li>\n<li>A vector, which is a standardized text string that describes the vulnerability\u2019s key characteristics. This includes details like whether it can be exploited remotely over a network or only locally, if elevated privileges are needed, how complex it is to exploit, and what aspects (such as availability, integrity, or confidentiality) of the vulnerable system are affected by exploitation.<\/li>\n<\/ul>\n<p>Here\u2019s an example using the highly severe and actively exploited vulnerability CVE-2021-44228 (Log4Shell): <strong>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<p>Let\u2019s break that down: the attack vector is network-based, attack complexity is low, privileges required: none, user interaction isn\u2019t required, the scope indicates the vulnerability impacts other system components, and the impact on confidentiality, integrity, and availability is high. Detailed descriptions of each component are available in the <a href=\"https:\/\/www.first.org\/cvss\/v3-1\/user-guide#Scoring-Rubrics\" target=\"_blank\" rel=\"nofollow noopener\">CVSS 3.1<\/a> and <a href=\"https:\/\/www.first.org\/cvss\/v4-0\/user-guide#Scoring-Rubrics\" target=\"_blank\" rel=\"nofollow noopener\">CVSS 4.0<\/a> specifications.<\/p>\n<p>A crucial part of the CVSS system is its scoring methodology \u2014 also known as the calculator, and available for both <a href=\"https:\/\/www.first.org\/cvss\/calculator\/4.0\" target=\"_blank\" rel=\"nofollow noopener\">4.0<\/a> and <a href=\"https:\/\/www.first.org\/cvss\/calculator\/3.1\" target=\"_blank\" rel=\"nofollow noopener\">3.1<\/a>. By filling in all the vector components, you can automatically get a numerical criticality score.<\/p>\n<p>The original CVSS calculation methodology included three metric groups: <strong>Base<\/strong>, <strong>Temporal<\/strong>, and <strong>Environmental<\/strong>. The first group covers the fundamental and unchanging characteristics of a vulnerability, and forms the basis for calculating the CVSS Base Score. The second group includes characteristics that can change over time \u2014 such as the availability of published exploit code. The third group is designed for internal organizational use to account for context-specific factors like the vulnerable application\u2019s scope or the presence of mitigating security controls in the organization\u2019s infrastructure. In CVSS 4.0, the Temporal metrics have evolved into <strong>Threat<\/strong> metrics, and a new group of <strong>Supplemental<\/strong> metrics has been introduced.<\/p>\n<p>Here\u2019s how the metrics are interconnected. Software vendors or cybersecurity companies typically assess the Base criticality of a vulnerability (referred to as \u201cCVSS-B\u201d in the 4.0 specification). They also often provide an assessment related to the availability and public disclosure of an exploit (CVSS-BT in 4.0, and Temporal in 3.1). This assessment is a modified Base Score; therefore CVSS-B can be higher or lower than CVSS-BT. As for the Environmental score (CVSS-BTE), it\u2019s calculated within a specific organization based on the CVSS-BT, with adjustments made for their unique conditions of using the vulnerable software.<\/p>\n<h2>The Evolution of CVSS<\/h2>\n<p>The first two versions of CVSS, released in 2005 and 2007, are hardly used today. While you might still find older CVSS scores for modern vulnerabilities, CVSS 3.1 (2019) and CVSS 4.0 (2023) are the most common scoring systems. However, many software vendors and vulnerability registries aren\u2019t in a rush to adopt version 4.0, and they continue to provide CVSS 3.1 scores.<\/p>\n<p>The core idea behind the first CVSS version was to quantify the severity of vulnerabilities via a scoring system \u2014 with an initial separation into Base, Temporal, and Environmental metrics. At that stage, the textual descriptions were loosely formalized, and the three groups of metrics were calculated independently.<\/p>\n<p>CVSS 2.0 introduced a standardized vector string and a new logic: a mandatory and unchangeable Base score, a Temporal score calculated from the Base score but accounting for changing factors, and an Environmental score used within specific organizations and conditions derived from either the Base or Temporal score.<\/p>\n<p>Versions 3.0 and 3.1 added the concept of Scope (impact on other system components). They also more precisely defined parameters related to required privileges and user interaction, and they generalized and refined the values of many parameters. Most importantly, these versions attempted to solidify the fact that CVSS measures the severity of a vulnerability \u2014 not the risks it creates.<\/p>\n<p>In version 4.0, the creators aimed to make the CVSS metric more useful for business-level assessments of how vulnerabilities impact risk. This is still not a risk metric, though. Attack complexity was split into two distinct components: attack requirements and attack complexity. This highlights the difference between the inherent engineering difficulty of an attack and the external factors or conditions necessary for the attack to succeed. In practical terms, this means a flaw that requires a specific, non-default configuration on the vulnerable product to be exploited will have higher attack requirements and, consequently, a lower overall CVSS score.<\/p>\n<p>The often-misunderstood Scope metric, which simply offered \u201cyes\u201d or \u201cno\u201d options for \u201cimpact on other components\u201d, has been replaced. Developers have introduced the clearer concept of \u201csubsequent systems\u201d, which now specifies what aspect of their operation the vulnerability affects. Additionally, a range of supporting indicators has been added \u2014 such as the automatability of an exploit and the impact of exploitation on human physical safety. The formulas themselves have also undergone substantial revisions. The influence of various components on the numerical threat score has been re-evaluated based on a vast database of vulnerabilities and real-world exploitation data.<\/p>\n<h2>How CVSS 4.0 is changing vulnerability prioritization<\/h2>\n<p>For cybersecurity professionals, CVSS 4.0 aims to be more practical and relevant to today\u2019s realities. We\u2019re facing tens of thousands of vulnerabilities \u2014 many of which receive a high CVSS score. This often leads to them being automatically flagged for immediate remediation in many organizations. The problem is, these lists are constantly growing, and the average time to fix a vulnerability is <a href=\"https:\/\/www.csoonline.com\/article\/3596697\/kicking-dependency-why-cybersecurity-needs-a-better-model-for-handling-oss-vulnerabilities.html\" target=\"_blank\" rel=\"nofollow noopener\">nearing seven months<\/a>.<\/p>\n<p>When vulnerabilities are <a href=\"https:\/\/www.orangecyberdefense.com\/global\/blog\/cert-news\/impact-of-the-transition-from-the-cvssv3-to-cvssv4-norm\" target=\"_blank\" rel=\"nofollow noopener\">re-evaluated from CVSS 3.1 to CVSS 4.0<\/a>, the Base Score for defects with a severity between 4.0 and 9.0 tends to slightly increase. However, for vulnerabilities that were considered critically severe in CVSS 3.1, the score often remains unchanged or even decreases. More importantly, while Temporal metrics had little impact on a vulnerability\u2019s numerical rating before, the influence of Threat and Environmental metrics is now much more significant. Orange Cyberdefense conducted a <a href=\"https:\/\/www.orangecyberdefense.com\/global\/blog\/cert-news\/impact-of-the-transition-from-the-cvssv3-to-cvssv4-norm\" target=\"_blank\" rel=\"nofollow noopener\">study<\/a> to illustrate this. Imagine a company is tracking 8000 vulnerabilities, and their IT and security teams are required to fix all defects with a Base CVSS score above 8 within a specified timeframe. What percentage of these 8000 real-world vulnerabilities would fall into that category \u2014 with or without considering exposure of the exploit to the public (Temporal\/Threat adjustment)? The study found that CVSS 4.0, in its base version, assigns a score of 8 or higher to a larger percentage of vulnerabilities (33% compared to 18% in version 3.1). However, when adjusted for the availability of exploits, this number drops significantly \u2014 leaving fewer truly critical flaws to prioritize (8% versus 10%).<\/p>\n<h2>Critical, High, and everything in between<\/h2>\n<p>What\u2019s the difference between a \u201ccritical\u201d vulnerability and one that\u2019s just plain dangerous? A text-based severity description is part of the specification \u2014 but it\u2019s not always required in a vulnerability description:<\/p>\n<ul>\n<li>Low Severity: 0.1\u20133.9<\/li>\n<li>Medium Severity: 4.0\u20136.9<\/li>\n<li>High Severity: 7.0\u20138.9<\/li>\n<li>Critical Severity: 9.0\u201310.0<\/li>\n<\/ul>\n<p>In practice, many software vendors take a creative approach to these text descriptions. They might modify the names or incorporate their own assessments and factors not included in CVSS. A case in point is June\u2019s Microsoft Patch Tuesday \u2014 specifically <a href=\"https:\/\/msrc.microsoft.com\/update-guide\/vulnerability\/CVE-2025-33064\" target=\"_blank\" rel=\"nofollow noopener\">CVE-2025-33064<\/a> and <a href=\"https:\/\/msrc.microsoft.com\/update-guide\/vulnerability\/CVE-2025-32710\" target=\"_blank\" rel=\"nofollow noopener\">CVE-2025-32710<\/a>. The first is described as \u201cImportant\u201d and the second as \u201cCritical\u201d, yet their CVSS 3.1 scores are 8.8 and 8.1, respectively.<br>\n<input type=\"hidden\" class=\"category_for_banner\" value=\"kaspersky-next\"><\/p>\n","protected":false},"excerpt":{"rendered":"<p>We break down the Common Vulnerability Scoring System: what it&#8217;s for, how it&#8217;s used in practice, and why the Base Score is just the beginning \u2014 not the end \u2014 of vulnerability assessment.<\/p>\n","protected":false},"author":2722,"featured_media":53827,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1999,3051,3052],"tags":[268],"class_list":{"0":"post-53825","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-vulnerabilities"},"hreflang":[{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/cvss-4-base-evolution\/53825\/"},{"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":"it","url":"https:\/\/www.kaspersky.it\/blog\/cvss-4-base-evolution\/29830\/"},{"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":"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.com\/blog\/tag\/vulnerabilities\/","name":"vulnerabilities"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/53825","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/users\/2722"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/comments?post=53825"}],"version-history":[{"count":3,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/53825\/revisions"}],"predecessor-version":[{"id":53830,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/53825\/revisions\/53830"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/media\/53827"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/media?parent=53825"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/categories?post=53825"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/tags?post=53825"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}