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 three complimentary metric groups: Base, Temporal, and Environmental.

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?

Temporal scores, which temper and refine the Base Score, are meant to communicate the likelihood of the worst-case scenario across all deployed environments. In doing so, they paint a more accurate picture of a vulnerability’s severity. This takes into account factors that change over time due to events that are external to the vulnerability.

An example of one of these fluid factors is the current state, or the maturity, of exploit code and techniques. A vulnerability may exist, and there may be proof-of-concept exploit code, but if there is no known functional exploit code,  the likelihood of a hack decreases. Additional temporal factors include remediation level, or what type of fix or workaround is available, and report confidence, which looks at confirming the credibility of the reports and their related technical details. These scores are important because in the absence of an exploit, for example, it may be reasonable to move this down your prioritization list in favor of a vulnerability where a functional exploit exists.

Finally, there are Environmental Scores. These 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.

Very 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?

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 v3.x that you won’t find in v2.0:

• A whole new metric, Scope, focuses on an exploited vulnerability’s ability to affect resources managed by different authorities. For example, a vulnerability in a virtual machine may also affect the host OS
• Another new metric, User Interaction, was added, specifying whether or not the attacker requires the cooperation of a legitimate user
• Privileges Required, renamed from an old metric, is intended to indicate that escalated privileges are needed in order for an attacker to exploit a system
• Enhancement of the Environmental Score to include Modified Base Scores, allowing researchers to account for additional context specific to their organization

Currently, v3.0 remains the latest major version, but has since been further improved with the release of v3.1. For this version, FIRST focused on clarification and improvement of the existing standard, with their main message being that their key use is to measure severity, not risk. No new metrics or major changes to values or formulas were introduced.

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 for placing issues in a reasonable priority to be fixed in an appropriate amount of urgency. 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 deliver both the Base and Temporal Scores. 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 and 3.x. 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.

Learn more about BDSAs