Security is becoming increasingly important to software development, knowing how to describe a security vulnerability is actually really useful.

CVSS stands for Common Vulnerability Scoring System and its aim is to capture the important aspects of a vulnerability and suggest just how severe it is.

CVSS scores are given to known vulnerabilities; that can be vulnerabilities found in anything from common operating systems to those found as the result of a penetration test on a website.

Without CVSS we’d be left with people giving vulnerabilities severity ratings based on how bad they think they are, so different people could give the same vulnerability wildly different scores.

As part of a development team receiving penetration test results, if you understand CVSS then you can get a better understanding of reported vulnerabilities and if necessary, question them. Questioning it is important because you can’t always trust the scores you get.

There are three main reasons people get CVSS scoring wrong:

1. Not reading the guide

The most important page for CVSS is this one right here, it’s the user guide that tells you exactly how to use it. The most important part of that page is the part right near the end titled Scoring Rubrics – essentially some flow charts that help you to decide on the metrics that calculate the score. This is many people’s first mistake, they don’t follow the graphs, maybe they don’t even know they exist.

Let’s take a commonly abused example. This flow chart determines the confidentiality impact i.e. does this vulnerability allow access to data that shouldn’t be accessed.

It starts by asking if there is an impact on confidentiality, that should be hard to get wrong.

Answering yes to that asks if it exposes all information, or if the information exposed is critical. This one is a little more tricky. Exposing all of the information is generally the result of SQL injection, granting an attacker access to the database. It could also be a vulnerability that grants access to administrator privileges, again granting access to all of the data. The important bit is the word ‘All’, if it is ‘All’ then answer yes.

If it isn’t ‘All’, then is the information critical? That’s a little harder to answer. What counts as critical? The user guide isn’t clear, so let’s consider what critical information might be. Data like credit card numbers or private medical information clearly have a big sign saying CRITICAL pointing at them. The same goes for anything to do with authentication, which would effectively allow further access. These are critical things, not just your name or address. Not that those things aren’t important, they’re just not critical. You can see why this is open to a little bit of interpretation though.

If in doubt, ask the person who performed the test to clarify how they arrived at the score!

2.Inflating Scores

Sometimes a penetration test is hard going, there might not be very many vulnerabilities. That’s a good thing. Unfortunately, the tester, or the testing company might worry that the customer will think they haven’t got value for money if there aren’t many findings. Maybe they’ll even wonder if the tester has done much work at all. What better way to make them think they’ve got value for money than taking a low risk finding and making it seem much more important!

Don’t get me wrong, most testers and testing companies will happily complete a test with only a couple of low risk items being found and think nothing of it, knowing they’ve performed a good test. You just need to be on the lookout for the odd occasion where this isn’t the case.

3.Copy and Paste

Probably the least fun part of performing a penetration test is writing the report. That can mean mistakes are made if trying to complete it as quickly as possible.

An important part of a CVSS score is the associated metrics, so they should always be displayed along with the final score. This comes in the format of a Vector String. An example looks like this (This one scores a 5.3 which is a medium risk):

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

This tells us that CVSS 3.1 was used, then attribute names and values are separated by slashes, so:

AV:N – means that the Attack Vector was Network

AC:L – means Attack Complexity was Low

PR:N – means Privileges Required was None

…etc

If that’s too hard to read then you can add the vector string to the end of the online calculator and see the results, e.g.

https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

It’s surprisingly common to see a vector string that looks nothing like the vulnerability that was found. This tends to come from a lack of accuracy by the report writer, often happening because the text for another vulnerability has been copy and pasted.

CVSS scores given to vulnerabilities should be checked to make sure the metrics make sense!

Knowing CVSS is Important for Software Development!

It’s important for both penetration testers and development teams to have a good understanding of CVSS so they can understand both how to create scores and how to interpret them. Without a good understanding, it's easy for an incorrect score to provoke the wrong reaction. If a vulnerability is scored as a high risk while it’s only a low risk then there might be an unnecessary push to fix it quickly.

The current version of CVSS is 3.1 and it can be found here. It’s an easy to use online calculator that spits out a score when you give it some metrics about a vulnerability. It’s split into Base Score, Temporal Score and Environmental Score, often just the Base Score is used. The result is a score between 0 and 10, which relates to severity ratings:

While the Base Score can be completely correct, there's also a final way the score can be unhelpful. Environmental and Temporal scores are used to adjust the Base Score to help the reader understand the severity of the vulnerability. The Environmental Score is used to adjust the severity according to the environment it's found in, so the environment might contain mitigations to make the vulnerability less severe. The Temporal Score is used to show how the vulnerability might change over time, with a vulnerability being less severe if for example there isn't yet a publicly available exploit. If these scores are relevant to the vulnerability then they should be given.

If your penetration test findings don’t even have CVSS scores on them then you should seriously consider if the severity ratings are correct.