Oct 30 2015

Inside the Common Vulnerability Scoring System Latest Update

A new version of the Common Vulnerability Scoring System helps agencies simplify risk.

The Common Vulnerability Scoring System (CVSS) provides agencies with a straightforward way to assess the severity of software flaws.

CVSS measures the major characteristics of software vulnerabilities and then puts them into a formula that creates a score for each one. While most users look just at that score — ignoring the individual measurements behind it — CVSS provides a quick way to assess each vulnerability’s overall importance.

This can be invaluable in helping agencies to prioritize vulnerability mitigation activities, such as installing patches to ensure that the most critical ones are addressed first.

CVSS was introduced in 2004 with changes delivered every few years to adapt to new vulnerabilities. The Forum for Incident Response and Security Teams led the development of CVSS v.3 this past June, based on feedback from users and designers.

The National Institute of Standards and Technology’s National Vulnerability Database (NVD), major security and software vendors and others are adopting the standard for wider use, including inside government.

End-user organizations should start seeing CVSS v.3 scores in late 2015. Here are some of the most important changes from v.2 that users will see.

The CVSS Severity Rating Labels

CVSS v.3 defines five rating labels: None, Low, Medium, High and Critical. Users can use the labels instead of the numerical scores to better prioritize vulnerabilities.

This should help clarify some misconceptions that began when NVD created similar designations that were not part of the official v.2 specification. Other organizations introduced their own rating labels based on NVD’s unofficial ratings, puzzling users. The new official rating labels in v.3 should alleviate that confusion.

CVSS' Scope

In CVSS v.2, vulnerabilities were scored within the context of an operating system. A serious vulnerability in an application usually had a significantly lower score than a similar one in an OS.

In many cases, this made sense, but for applications that hold sensitive data, an application vulnerability could be just as serious as one in the OS.


The approximate number of vulnerabilities for which the National Vulnerability Database had CVSS scores, as of mid-2015*

SOURCE: National Vulnerability Database

CVSS v.3 takes this into account and scores the impact on the affected software, which is not always the operating system, with higher scores than the previous version.

CVSS accounted for how many passwords and other authentication credentials were presented to gain access to an application.

While good in theory, that number was almost always zero or one, giving the metric limited value. In v.3, this metric has been reworked to focus on the privileges needed for exploitation — something the previous version did not do.

Vulnerabilities that require many privileges for exploitation will get higher scores than those that use standard or no privileges.

How Compatible Is CVSS?

Based on some of the formula changes, it will be difficult initially to convert some of the scores from CVSS v.2 to v.3. While a number of scores from the original version converted to v.2 automatically, translating a v.2 score is likely to require manual rescoring.

Score producers will likely not have the resources to publish v.3 scores for all the vulnerabilities they previously scored under v.2. This will force agencies to use both v.2 and v.3 scores to prioritize vulnerabilities until they are able to convert all of their scores to the new system.

Bruce T. Brown/Getty Images