Sonatype Delivers Premium Open Source Controls to GitHub | Press Release

blog-logo Sonatype Blog

What Does the New CVSS 3.1 Scoring Model Mean for Enterprise Security?

February 17, 2020 By Akshay 'Ax' Sharma

With thousands of security vulnerabilities reported each month in products ranging from hardware devices to firmware to popular software apps, how does one prioritise what needs the most attention? From a business and project management perspective, it makes sense to, first and foremost, allocate engineering and/or risk assessment resources to the most severe vulnerabilities that need immediate patching. Trivial vulnerabilities, which are likely to be practically unexploitable in the current business context, could be addressed at a later time, if at all.

To solve this problem, an open standard, Common Vulnerability Scoring System (CVSS) was devised in 2004 by the National Infrastructure Advisory Council (NIAC).

The CVSS score is a way to assess the severity of a vulnerability. It consists of a base score assigned to a vulnerability, followed by the temporal and environmental scores which further reflect the severity of factors around the vulnerability.

CVSS2-calculatorCVSS 2.0 calculator

CVSS3-calculatorCVSS 3.0 calculator

The initial CVSS standard released to address this problem, however, didn’t undergo a massive peer-review. Only after receiving valuable feedback from industry stakeholders was a version 2.0 introduced with some improvements. However, major noticeable differences were added in CVSS version 3.0 which incorporated additional changes into the Base score, such as replacement of Authentication (Au) with the Privileges Required (PR) parameter and addition of Scope (S).

Over the last decade, CVSS 2.0 and 3.0 scoring has been used most widely when reporting vulnerabilities across NVD, and MITRE, with a few other and miscellaneous platforms taken into consideration.

What Changed in Version 3.1: Context

Where CVSS 2.0 and 3.0 scores could have been ‘erroneously’ employed as a measure of risk arising from a vulnerability, CVSS 3.1 standard, maintained by FIRST (Forum of Incident Response and Security Teams) explicitly clarifies “CVSS measures severity, not risk.”

Version 3.1, without making major changes to the CVSS scoring formula itself, focuses on clarifying what is meant by attack vector. Different factors and configurations may allow for the same vulnerability to have multiple, different base scores depending on the context. This is especially useful when a vulnerability on a particular system configuration or operating system may not pose a high severity, whereas it would on another.

The new CVSS version also accounts for concepts such as “vulnerability chaining.” This is when an attacker follows steps to carry out a series of attacks after performing some basic reconnaissance.

CVSS 3.1 Impacts Score Formula and Decision Making

All of this impacts prioritization from a decision-maker’s perspective. For example, where previously a vulnerability with a low base score would normally have been ignored by your project management team under the impression it poses “low risk,” CVSS 3.1 guidelines and factors instruct accounting for circumstances specific to an organization, such as the network architecture and overall configuration. Naturally, a vulnerability with a “low” score may in fact be highly exploitable when it comes to the network design of your corporate environment. This therefore helps security professionals look at ‘surrounding’ factors around a vulnerability rather than mistakenly focusing on just a score as the sole indicator of risk.

Regardless of whichever version of CVSS you stick to, 2.0, 3.0, or 3.1, consistency is important. Additionally, when converting scores between CVSS 2.0 and 3.x, care must be taken to ensure additional parameters further augment the quality of the score meaningfully rather than focusing exclusively on keeping the newly calculated scores “in match” with the previous ones.

A key challenge arises when scoring vulnerabilities for which a CVE ID has not yet been assigned by NVD and there’s no CVSS score.

VulnerabilityDetails

The Sonatype security research team extensively monitors diverse sources of vulnerabilities such as GitHub, ExploitDB and 60 other places, for which CVE has not yet been requested, and assigns these proprietary Sonatype identifiers along with accurate CVSS scores.

The products display the most up-to-date CVSS 2.0 and 3.1 scores, from both NVD along with Sonatype’s own CVSS assessment score. Sonatype’s scoring is more accurate and precise than that from NVD. Scan your app for free here to try it out.

Tags: vulnerabilities, security, open source security, enterprise, Application Security, nvd, Post security/devsecops, CVSS

Written by Akshay 'Ax' Sharma

Endorsed an Exceptional Talent (‘a recognized leader’) by the British Government, Akshay aka Ax is a Security Researcher at Sonatype and Engineer who holds passion for perpetual learning. In his spare time, he loves exploiting vulnerabilities ethically and educating a wide range of audiences.