{"id":24403,"date":"2025-07-22T23:47:33","date_gmt":"2025-07-22T19:47:33","guid":{"rendered":"https:\/\/me-en.kaspersky.com\/blog\/cvss-rbvm-vulnerability-management\/24403\/"},"modified":"2025-07-22T23:47:33","modified_gmt":"2025-07-22T19:47:33","slug":"cvss-rbvm-vulnerability-management","status":"publish","type":"post","link":"https:\/\/me-en.kaspersky.com\/blog\/cvss-rbvm-vulnerability-management\/24403\/","title":{"rendered":"From CVSS to RBVM: vulnerability prioritization done right"},"content":{"rendered":"

When you first encounter CVSS<\/a> (Common Vulnerability Scoring System), it\u2019s easy to think this is the perfect tool for triaging and prioritizing vulnerabilities. A higher score must mean a more critical vulnerability, right? In reality, that approach doesn\u2019t quite work out. Every year, we see an increasing number of vulnerabilities with high CVSS scores. Security teams just can\u2019t patch them all in time, but the vast majority of these flaws are never actually exploited in real-world attacks. Meanwhile, attackers are constantly leveraging less flashy vulnerabilities with lower scores. There are other hidden pitfalls too \u2014 ranging from purely technical issues like conflicting CVSS scores to conceptual ones like a lack of business context.<\/p>\n

These aren\u2019t necessarily shortcomings of the CVSS itself. Instead, this highlights the need to use the tool correctly, as part of a more sophisticated and comprehensive vulnerability management process.<\/p>\n

CVSS discrepancies<\/h2>\n

Do you ever notice how the same vulnerability might have different severity scores depending on the available source? One score from the cybersecurity researcher who found it, another from the vendor of the vulnerable software, and yet another from a national vulnerability database? It\u2019s not always just a simple mistake. Sometimes, different experts can disagree on the context of exploitation. They might have different ideas about the privileges with which a vulnerable application runs, or whether it\u2019s internet-facing. For instance, a vendor might base its assessment on its recommended best practices, while a security researcher might consider how applications are typically configured in real-world organizations. One researcher might rate the exploit complexity as high, while another deems it low. This isn\u2019t an uncommon occurrence. A 2023 study by Vulncheck<\/a> found that 20% of vulnerabilities in the National Vulnerability Database (NVD) had two CVSS3 scores from different sources, and 56% of those paired scores were in conflict with each other.<\/p>\n

Common mistakes when using CVSS<\/h2>\n

For over a decade, FIRST<\/a> has advocated for the methodologically correct application of CVSS. Yet organizations that use CVSS ratings in their vulnerability management processes continue to make typical mistakes:<\/p>\n

    \n
  1. Using the CVSS base score as the primary risk indicator. CVSS measures the severity of a vulnerability \u2014 not when it will be exploited or the potential impact of its exploitation on the organization under attack. Sometimes, a critical vulnerability is harmless within a specific company\u2019s environment because it resides in insignificant and isolated systems. Conversely, a large-scale ransomware attack might begin with a seemingly innocuous information leak vulnerability with a CVSS score of 6.<\/li>\n
  2. Using the CVSS Base score without Threat\/Temporal and Environmental adjustments. The availability of patches, public exploits, and compensatory measures significantly influences how and how urgently a vulnerability should be addressed.<\/li>\n
  3. Focusing only on vulnerabilities above a certain score. This approach is sometimes mandated by government or industry regulators (\u201cremediate vulnerabilities with CVSS score above 8 within one month\u201d). As a result, cybersecurity teams face a continuously growing workload that, in reality, doesn\u2019t make their infrastructure more secure. The number of vulnerabilities with high CVSS scores identified annually has been rapidly increasing over the past 10 years<\/a>.<\/li>\n
  4. Using CVSS to assess the likelihood of exploitation. These metrics are poorly correlated: only 17% of critical vulnerabilities<\/a> are ever exploited in attacks.<\/li>\n
  5. Using only the CVSS rating. The standardized vector string was introduced in CVSS so that defenders could understand the details of a vulnerability and independently calculate its importance within their own organization. CVSS 4.0 was specifically revised to make it easier to account for business context using additional metrics. Any vulnerability management efforts based solely on a numerical rating will largely be ineffective.<\/li>\n
  6. Ignoring additional sources of information. Relying on a single vulnerability database and analyzing only CVSS is insufficient. The absence of data on patches, working proofs of concept, and real-world exploitation cases makes it difficult to decide how to address vulnerabilities.<\/li>\n<\/ol>\n

    What CVSS doesn\u2019t tell you about a vulnerability<\/h2>\n

    CVSS is the industry standard for describing a vulnerability\u2019s severity, the conditions under which it can be exploited, and its potential impact on a vulnerable system. However, beyond this description (and the CVSS Base score), there\u2019s a lot it doesn\u2019t cover:<\/p>\n