The Common Vulnerability Scoring System (CVSS) can help you navigate the constantly growing ocean of open source vulnerabilities. But it’s difficult to lend your trust and put the security of your organization and your customers into the hands of a system that you may know very little about. Let’s take a closer look at the CVSS to see what it’s all about.
What exactly is the CVSS
While the potential impact of a software vulnerability should not be downplayed, it would be unreasonable to claim that every vulnerability introduces an equal amount of risk and demands your complete and immediate attention. The CVSS, authored by FIRST.org, is an industry standard designed to specify the characteristics and severity of vulnerabilities, which can be leveraged by organizations to obtain a richer understanding of each vulnerability to prioritize accordingly. In simpler terms, the CVSS provides the context to help you decide which vulnerabilities you should be most concerned about. This isn’t to say that the CVSS will make prioritization decisions for you, but it will give you one piece of information you need to make informed decisions that are best for your organization.
How a CVSS score is calculated
A CVSS score assesses the severity of a vulnerability by leveraging four complimentary metric groups: Base, Threat, Environmental, and Supplemental.
The Base Score reflects the core characteristics of a vulnerability, or those that remain constant throughout time and operating environments. When determining Base Scores, analysts break it down further to Exploitability metrics and Impact metrics.
The exploitability of a vulnerability refers to factors like attack vector, complexity, and the privileges required by an attacker. When calculating this score, the researcher may ask questions like:
- What means would a hacker use to carry out an exploit?
- How easy would it be?
- What kind of permissions would they need from the application?
The Impact metric is calculated by considering the effects on the most impacted component should an exploit occur. This is formed by considering the confidentiality, integrity, and availability of the affected component after an exploit. Setting these scores requires consideration of:
- How much restricted, or confidential, information handled by the affected component has been exposed
- How much can an organization trust the information handled by the affected component ? Has it been heavily modified, or did it retain its integrity?
- Can an organization still access the affected component, or is the attacker completely denying service?
Threat Scores, which temper and refine the Base Score, focus primarily on exploit maturity, which is the sole metric used in determining this score. The threat score uses information such as exploit code availability, exploit techniques, and active exploitation to determine the likelihood that the vulnerability will actually be attacked. Keep in mind that this score only takes into account factors that are external to the vulnerability, and will often change over time.
For example a vulnerability may be discovered, and the Base Score metrics that are calculated determine it to be a severe vulnerability. However, the current exploit is only a proof-of-concept. This would Threat Score would then reduce the Base Score, reducing the severity. Over time, the PoC exploit code made become publicly available, attacks begin to be reported, the Threat Score increases, along with the severity of the vulnerability.
Environmental Scores allow a researcher to customize the CVSS score depending on how important the affected assets are to their company. Since this is so specific to every company’s unique environment, you won’t find it published in third-party vulnerability feeds.
Simply put, this score is comprised of metrics that are equivalent to those used to form the Base Score. So, researchers look at each of the Base metrics and ask themselves how it would affect their company should an exploit occur. For example, let’s consider the availability metric from the Base score:
- What type of adverse effect on the company and its associates (employees, customers, etc.) would a loss of availability of the affected IT component have?
Lastly, the Supplemental Score is made up of a group of metrics that describe extrinsic attributes of a vulnerability. Since the measurement of each metric is dependent on the environment of the impacted system, this score is going to have to be determined by the consumer. These metrics focus on impact to human safety, the possibility for exploit automation, recovery and response efforts, and a few others.
The dynamic nature of the CVSS
While the scoring metrics discussed earlier are all available in the latest version of the CVSS, they weren’t all always offered. To keep up with the ever changing software landscape, FIRST continues to keep the scoring system current and relevant. Here’s what you get in version 4.0 that you won’t find in previous versions:
- To reinforce that CVSS is not just the Base score, new nomenclature has been introduced to identify scoring combinations, such as Base alone (CVSS-B), Base + Threat (CVSS-BT), Base + Threat + Environmental (CVSS-BTE), and so on.
- Addition of a new Base metric - Attack Requirements
- Retirement of the Scope metric.
- Renaming of the Temporal metric group to Threat group, along with simplification of associated metrics.
- New metric group, Supplemental, to communicate extrinsic vulnerability attributes without impacting final CVSS-BTE score.
- Increased focus on operational technology and safety, which has been a weak point of previous CVSS versions, several critics would say.
Currently, v4.0 remains the latest version, having been officially released in October 2023.
How Black Duck Security Advisories (BDSAs) leverage the CVSS
Once you overcome the obstacles of obtaining an accurate inventory of open source software in your applications and actively comparing them to vulnerability feeds, your next step is to prioritize the fixing of those bugs. To avoid throwing every issue that comes across your desk over the wall to be fixed immediately, you need multiple inputs to understand the potential impact of a vulnerability so that you can triage accordingly. As we discussed, CVSS is one such input. However, you won’t find the detail you need in free feeds, like the NVD, which only provide Base Scores. With just the Base score in hand, you’ll struggle to determine the true severity of a vulnerability, potentially leaving developers with a longer than necessary list of critical vulnerabilities to work through.
In comparison, BDSA’s go beyond Base scores. Since CVSS v4 is still being adopted, the latest version supported by BDSAs is v3.x, which means Temporal scores (changed to Threat scores in v4) will be included. In addition, Black Duck recognizes the major differences in the past couple versions of the CVSS, so you’ll find scores aligned with versions 2.0 as well. And since this information is only as good as its sources, the dedicated professionals at the Synopsys Cybersecurity Research Center (CyRC) take the time to research, review, and issue accurate and actionable scores.
With both scores in hand from a source you can trust, you have an understanding of not only the basic characteristics of the vulnerability, but also current conditions that may make an exploit more or less possible. With this information, you can automate what needs to be addressed and when, so that your smooth SDLC can keep running.
Continue Reading
