CVSS v3 Creates New Challenges For Developers
Table of Contents
What is CVSS 3.0?
The CVSS (Common Vulnerability Scoring System) provides an open framework for communicating the characteristics and impacts of IT vulnerabilities. Its quantitative model ensures consistent and accurate measurement, while enabling users to see the underlying vulnerability characteristics that were used to generate the scores.
The numerical score can then be translated into a qualitative representation (such as low, medium, high, and critical) to help organizations properly assess and prioritize their vulnerability management processes.
CVSS 2.0 vs. CVSS 3.0
NVD provides qualitative severity rankings of “Low”, “Medium”, and “High” for CVSS v2.0 base score ranges in addition to the severity ratings for CVSS v3.0 as defined in the CVSS v3.0 specifications.
The newer version of CVSS introduces a number of changes in the scoring system that reflect more accurately vulnerabilities that fall under the web application domain.
While all three metric groups: the Base Score, the Temporal Score and the Environmental Score remained the same, new metrics such as Scope (S) and User Interaction (UI) were added. In addition, old metrics such as Authentication (Au) were changed to newer ones such as Privileges Required (PR).
The Scope metric differentiates between an exploited vulnerability that can only affect resources managed by the same authority. In this case, the vulnerable component and the impacted component are the same.
The Environmental Metrics group also saw a new addition with the Modified Base Metrics—allowing analysts to customize CVSS scores based on the host that has been affected in the analyst’s organization, making it contextual when necessary.
| CVSS v2.0 Ratings | CVSS v3.0 Ratings | ||
|
Severity |
Base Score Range |
Severity |
Base Score Range |
|
|
| None | 0.0 |
|
Low |
0.0-3.9 | Low | 0.1-3.9 |
|
Medium |
4.0-6.9 | Medium | 4.0-6.9 |
|
High |
7.0-10.0 | High | 7.0-8.9 |
|
|
| Critical | 9.0-10.0 |
How to prioritize when CVSS v3 vulnerabilities are higher
The number of vulnerabilities reported is on the rise, adding to an already heavy workload for developers. According to our most recent annual report, reported open source vulnerabilities in 2017 jumped by 60% the year before. Given this increase of vulnerabilities, some aspects of CVSS v3 serve only to complicate things for developer moving forward.
While most agree that the new metrics in CVSS v3 helped to address some of the shortcomings of its predecessor CVSS v2, we now have to contend with a different set of challenges when it comes to prioritizing our remediations.
The most noticeable change has been that scores are going up, bringing us far higher scores than before. To put it simply, a vulnerability that would have been rated as a 7.6 under CVSS v2 could quickly find itself with a 9.8 under CVSS v3.
A recent study by Cisco which analyzed 745 vulnerabilities found that 38% of those that had been rated as Medium in CVSS v2 where now designated as High in CVSS v3. For developers, this now means that nearly 40% more of their screen will be filled with red, and they will be under more pressure to clear them off the list. Considering how the total number of vulnerabilities is on an upward trajectory, teams need to start taking stock of how to approach this time-consuming challenge.
These changes in how we rate vulnerabilities should serve as a wake-up call that they may be riskier than we had previously considered, thus warranting the higher ratings. At the same time, when all of these scores rise, it makes it hard for teams to know which ones to address first. This is because while the scores may be higher due to a variety of factors, we still do not know which vulnerabilities have a direct impact on our product, and therefore should be our first concern.
Utilizing effective usage analysis for greater visibility and prioritization
One of the common misconceptions is that an alert to a vulnerability necessarily means that your product is at risk. This does not refer to the issue of false positives, but of not properly understanding which functionalities of the vulnerable component are in fact effective, meaning that it is being called upon by the proprietary code.
For developers, gaining visibility into which vulnerabilities pose a direct threat to their products can be invaluable. According to our research over the course of beta testing our Effective Usage Analysis technology on Java components, Mend discovered that only 30% of functionalities in vulnerable components were found to be effective. Extrapolating this data shows us that upwards of 70% of alerts do not require remediation, thus reducing the total workload for already stressed teams.
Perhaps most importantly, it helps developers cope with the spike in vulnerability scores brought on with the adoption of CVSS v3. By understanding which vulnerable components are most demanding of remediation based on the fact of having an impact on our product or not, we can skip the panic of finding a 9.5 rated vulnerability in one of our open source components, if Effective Usage Analysis tells us that it is not effective.
