Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Vulnerabilities / Threats

10:00 AM
Jeffrey Martin
Jeffrey Martin
Connect Directly
E-Mail vvv

Is CVSS the Right Standard for Prioritization?

More than 55% of open source vulnerabilities are rated high or critical. To truly understand a vulnerability and how it might affect an organization or product, we need much more than a number.

The software development industry's increasing reliance on open source components has led to a rise in awareness of open source security vulnerabilities, resulting in a drastic increase in the number of discovered open source vulnerabilities, as WhiteSource's annual report, "The State of Open Source Security Vulnerabilities," shows.

Faced with a continuously growing number of open source vulnerabilities in our codebase, how can software development organizations keep up with the long list of security alerts to make sure they are remediating the most urgent issues first?

Prioritization of security alerts has become an important part of vulnerability management, and many organizations look to the CVSS (Common Vulnerability Scoring System) score of vulnerabilities as an objective standard for prioritizing their open source security vulnerabilities. However, data in the WhiteSource research report shows that relying on the CVSS rating for prioritization will get organizations only so far.

What's in a CVSS Score?
Since 2005, the CVSS from the good folks at FIRST (the Forum of Incident Response and Security Teams) has become the standard for assessing the severity of a vulnerability. In the CVSS, researchers examine a vulnerability's base, temporal, impact, and environmental metrics to gain an understanding of how hard an exploit is to carry out and the level of damage it can cause if the attacker is successful.

The CVSS has continued to evolve over the years with new and updated versions as the community works to improve the scoring system. New parameters have been added, such as the Scope and User Interaction metrics that came in CVSS v3 when it was released in 2015, which provide more information than what was available in v2. More recently, CVSS v3.1 was released to "clarify and improve the existing standard."

However, even as the changes made in v3 provided valuable details for helping organizations better ascertain the severity of a given vulnerability, there was one significant consequence from shifting to the new standard. 

Were All Vulnerabilities Created Equal? CVSS Ratings Over Time
The WhiteSource research report analyzed the CVSS ratings of more than 10,000 open source vulnerabilities that were reported between 2016 and 2019 to compare the severity breakdown of vulnerabilities rated by CVSS v2, v3.0, and v3.1. 

Data shows that v3.0 and v3.1 scores are significantly higher than the v2 scores. For instance, a vulnerability with a 7.6 CVSS under v2 may find itself classified as a 9.8 by v3.x standards.

Comparing v2.0 rating standards to v3.0 rating standards provides partial explanation of the dramatic shift:

Critical and High Severity Vulnerabilities Are on the Rise
After showing that CVSS v3.x scores are generally higher, the research report goes on to compare the severity distribution of vulnerabilities rated with a CVSS v3 score to better understand the scope of high and critical severity open source vulnerabilities.

The numbers for 2019 show that over 55% of CVEs were rated as high or critical. The study also reported that open source vulnerabilities rose by 50% in 2019, meaning that not only are more CVEs classified as high and critical, but there are many more vulnerabilities to contend with overall.

The first and most prominent change that the recently released CVSS v3.1 presented was that it measured severity, not risk. This change was supposed to provide users with a more comprehensive and precise context and shared understanding of a vulnerability's severity score to allow more users to leverage the information. The data shows that as the scoring method continues to evolve, developers and security teams are forced to address a large volume of high and critical severity vulnerabilities with limited tools for prioritization.

There are a number of reasons for the imbalance in the distribution of severity scores. These range from the security community's heightened focus on high and critical issues to the difficulty in creating CVEs, which are time-consuming and cause some to avoid them for lower-severity issues. The question remains: How can development and security teams address this imbalance?

Should CVSS Ratings Figure into Vulnerability Remediation Prioritization
As the security landscape continues to evolve, we know that to truly understand a vulnerability and how it might affect an organization or product, we need much more than a number.

V3.1 is based on the understanding that the CVSS score shouldn't be taken as the only parameter. Factors such as vulnerable dependencies or network architecture and configuration, to name a few, require consideration when assessing the risk of a security vulnerability in our assets.

It's still up to DevSecOps teams to ensure that their organization's software inventory, cloud environments, and network structure are all taken into consideration as part of the assessment of vulnerabilities.

Related Content:

Check out The Edge, Dark Reading's new section for features, threat data, and in-depth perspectives. Today's featured story: "Election Security in the Age of Social Distancing."

Jeffrey Martin has spent the last 15 years in product roles, helping both the organizations he worked for and their customers transform and measure their business processes, development, and QA. He especially enjoys cultural and mindset transformations for their ability to ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Author
6/24/2020 | 5:21:33 AM
CVSS is only one Vector to prioritise correctly
As you approach the work of determining if a vulnerability is critical or not, there are other factors you should consider, apart from CVSS - threats in the wild, the importance of the digital asset at risk, and its configuration and accessibility - considering these, alongside CVSS, can drop down the nu,ber of critical vulnerabilities dramatically.
COVID-19: Latest Security News & Commentary
Dark Reading Staff 9/25/2020
Hacking Yourself: Marie Moe and Pacemaker Security
Gary McGraw Ph.D., Co-founder Berryville Institute of Machine Learning,  9/21/2020
Startup Aims to Map and Track All the IT and Security Things
Kelly Jackson Higgins, Executive Editor at Dark Reading,  9/22/2020
Register for Dark Reading Newsletters
White Papers
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, when determining the common dimension size of two tensors, TFLite uses a `DCHECK` which is no-op outside of debug compilation modes. Since the function always returns the dimension of the first tensor, malicious attackers can ...
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, a crafted TFLite model can force a node to have as input a tensor backed by a `nullptr` buffer. This can be achieved by changing a buffer index in the flatbuffer serialization to convert a read-only tensor to a read-write one....
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, if a TFLite saved model uses the same tensor as both input and output of an operator, then, depending on the operator, we can observe a segmentation fault or just memory corruption. We have patched the issue in d58c96946b and ...
PUBLISHED: 2020-09-25
In TensorFlow Lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, saved models in the flatbuffer format use a double indexing scheme: a model has a set of subgraphs, each subgraph has a set of operators and each operator has a set of input/output tensors. The flatbuffer format uses indices f...
PUBLISHED: 2020-09-25
In TensorFlow Lite before versions 2.2.1 and 2.3.1, models using segment sum can trigger writes outside of bounds of heap allocated buffers by inserting negative elements in the segment ids tensor. Users having access to `segment_ids_data` can alter `output_index` and then write to outside of `outpu...