Let's look at the Common Vulnerability Scoring System (CVSS) and how it can help you in vulnerability management.

A typical challenge in the process of vulnerability management is triage: which vulnerabilities need to be addressed immediately, and which ones can be deferred, or perhaps even ignored? This is where CVSS can help.

The Common Vulnerability Scoring System (CVSS) attempts to solve this problem by assigning a decimal severity value from 0.0 to 10.0 to each vulnerability indicating how easy it is to exploit, and how much damage a successful exploitation can do. This score can help you make decisions about which vulnerabilities to prioritize, and whether vulnerability is severe enough to be addressed immediately with an emergency patch. More importantly, CVSS can be tailored to your organization.  By applying temporal factors (such as the current status of available fixes) and environmental factors (such as extra layers of protection in your deployment environment), you can calculate a more realistic value.

(Not just) one number to rule them all

The US government originally developed CVSS version 1, but its development was handed over to a global organization called FIRST (Forum of Incident Response and Security Teams) in 2005. The CVSS special interest group of FIRST developed version 2 (still in use) in 2007 and version 3 in 2015. The current version 3.1 (released in July 2019) clarifies the v3 scheme without changing the actual scoring.

CVSS scores can be calculated by anyone, including the vendor and the researcher who found the vulnerability.

At the core of CVSS is the calculation of a score of a vulnerability based on the value of several exploitability and impact metrics. Exploitability is a composite of factors such as whether the system can be attacked through the internet or only locally (or perhaps only with physical access); whether unusual conditions need to be met for the attack to succeed; and whether the attacker needs to be authenticated in the system first. Impact is defined by a metric called Scope (can the exploit also affect other components than just the vulnerable one?) as well as the worst damage an exploit can do to the three main security properties: confidentiality, integrity, and availability.

Calculating CVSS

So far, it looks rather straightforward – just feed all these metrics into the CVSS 3.1 calculator, and it spits out a number! But it’s not as simple as that. This is just the base score, and – depending on the context – the severity of the vulnerability can vary wildly from it.

The first of these contextual modifiers of CVSS is the temporal score – how exploitable is this vulnerability in the real world right now? The main considerations here are the availability of exploit code, fixes or mitigations, and whether the vulnerability report itself has been corroborated or – even better – confirmed by the vendor.

Finally, the environmental score puts the vulnerability in context of how that vulnerable component is used by your organization. Each of the fields defined for the base score can be overridden if the impact is different in that particular deployment. For instance, if the vulnerable status page of your web server – normally public – is only accessible from the intranet after authentication, it will modify the attack vector and required privileges, pushing the score down.

Note that v3 scores tend to be higher than v2 scores in general – this is due to the new definition of CIA impact metrics (degree of impact rather than exposure) as well as the creation of several concepts that can raise the severity of a vulnerability (such as an extended scope, or a vulnerability chain). For instance, the Android use-after-free vulnerability CVE-2019-2215 had a CVSSv3 score of 7.8 and a CVSSv2 score of 4.6…

CVSS is not magic

CVSS is an inherent simplification of a potentially complex security issue. As such, it is not always going to be accurate; there have been instances of SCADA and healthcare industries speaking out about the inaccuracies of the scoring system for their products.

At an early stage, estimating the severity of vulnerability can be difficult. It is not uncommon for vulnerability databases to come up with different values: for example, the assessments of NVD and ISC² had more than a 2-point difference for Meltdown and Spectre. A vulnerability database can also significantly reassess the CVSS as new information comes to light – e.g. CVE-2019-14657 went from 7.8 to 8.8, while CVE-2019-17624 went from 8.8 to 3.3!

There is also the risk of experts making a mistake when defining the score (just look at the github issue for CVE-2019-17624). It’s a good idea to look at multiple vulnerability databases to get a broad view on its real risk, especially if the vulnerability is still very new.

CVSS in the real world

In addition to your national or regional CERT or major software vendor there are many other organizations that can calculate CVSS scores for vulnerabilities.  NVD is a good general resource, as it defines a score for every vulnerability in the CVE database.

Once you have the base score, you should adapt the CVSS value to your own deployment by specifying the appropriate temporal and environmental metrics.

Most importantly, remember that CVSS is a vulnerability management tool, not a panacea. It helps you estimate a particular vulnerability’s severity intended for triage – and is an essential piece of securing the DevOps puzzle – but should not be considered a substitute for an in-depth risk analysis or security evaluation!

If you want to learn more about CVSS or vulnerability management, several of our courses go in depth on the topic, such as Machine learning security, Secure coding in C and C++ for automotive, Cloud application security in Python for AWS, and Security testing Python Web applications. We cover the basics of vulnerability management in many other courses as well.