The trouble with CVEs and vulnerability management in modern tech stacks

Conversations about basic cybersecurity hygiene often start with a lecture on effective patch management. While proper patch management is certainly recommended, much more can be done. Say you’ve locked the doors of your house before leaving for vacation – an opportunist might only check to see if the doors are locked, but a persistent thief might try the windows or look for other ways in. Similarly, CVEs and CVSS serve a purpose, but they still leave you with many untreated risks. Why? Because vulnerability management through CVEs is an incomplete solution.

Before we look at the trouble with CVEs, let’s define what CVEs are. According to CVE.org:

 The mission of the CVE® Program is to identify, define, and catalog publicly disclosed cybersecurity vulnerabilities. There is one CVE Record for each vulnerability in the catalog. The vulnerabilities are discovered then assigned and published by organizations from around the world that have partnered with the CVE Program. Partners publish CVE Records to communicate consistent descriptions of vulnerabilities. Information technology and cybersecurity professionals use CVE Records to ensure they are discussing the same issue and to coordinate their efforts to prioritize and address the vulnerabilities.

The CVE® Program is maintained by the MITRE Corporation and funded by the U.S. Department of Homeland Security. Organizations can prioritize how they approach patch management with this as a bases.

But, a long list of issues would be impossible to consume unless there is a way of prioritizing issues. That’s why the Common Vulnerability Scoring System (CVSS) has been the long-term established industry standard since the beginning of time. Does this mean everything is all good?

Not so. This article takes a deep dive into the mathematical construction of the CVSS scoring system, particularly the distribution and concentration of scores that can be found in the CVSS program.

The problem with the math of CVEs

What exactly is wrong with CVEs? For starters, the scoring system (aka the math) for CVSS 3.1 is flawed – the model is essentially based on the retrofitting of an arbitrary equation. Creating a mathematical formula, in theory, sounds good, but it makes scoring feel more trustworthy than it actually is. One assumption that can be made about the CVSS program is that the group behind it developed the math equations to fit the sample data they wanted.

What about the actual math? Let’s look at CVSS 3.1 for application security. The issue here is that ‘Network’ is always the attack vector, often resulting in a base score of at least 5.3 for many remote attacks, regardless of how trivial the impact is. When leveraging the environmental scores, the score drops to 4.4. A floor of 4.4 leaves almost 50% of the scale not in use. 

The CVSS is an essential part of the Information Security Management Systems (ISMS) at most organizations, but why do we put so much trust in a model that clearly has issues? Can’t we develop something better? There have been attempts to create better models, such as EPSS, but nothing has made it all the way to acceptance. EPSS has its challenges too, especially for application security where in many cases the attack likelihood increases given the simplicity of attacks and remote availability of active vulnerabilities. 

“Creating a mathematical formula, in theory, sounds good, but it makes scoring feel more trustworthy than it actually is”

CVSS isn’t a true indication of the risk a CVE represents to your organization. It tries to take the environment into consideration but only has limited success. This is why basing your security program on CVSS scores is flawed. How high or low a CVSS score is has no relation to the risk it represents to your organization. A public glossary like the CVE Program doesn’t know your specific business conditions and does not account for the potential attack path. The amount of risk to your organization is entirely dependent upon your business conditions, not the CVSS score. Expecting public ratings to correlate directly to your environment is not a reasonable risk management approach.

The risk in third-party plugins to established software cores

Take third-party plugins, for example. If you are using something like WordPress, effective patch management should take care of the core. But most people rely on plugins and add-ons to enhance the applications they build. In many cases, these plugins are not covered by formal reporting processes. This is inherently insecure as the add-ons increase the attack surface for organizations and creates additional opportunities for malicious hackers to gain access by exploiting these overlooked areas.

CVE noise

Furthermore, there are more than 50 CVEs published every day. Not only is it unreasonable to expect your security team to go through all of them, but not every CVE contains all the information that you need. You can prioritize the important CVEs, but it’s not always clear which ones actually represent the most risk to your environment.

• Does a published CVE actually represent a risk to you?
• Do you need to patch it or not?

Making this decision 50 times per day is neither realistic nor sustainable. Obviously, a Vulnerability Management product will help with this to some extent, but as their scoring is based on CVSS, you will still get a significant amount of noise. 

Recent research conducted by our team at Detectify found that from a sample of 198 CVEs, the % of CVEs that were relevant to AppSec teams decreased exponentially as CVE scores increased. In the latest Verizon breach report, the “application” has now become the most active attack vector. How is that then represented in the CVE data? This makes little sense, seeing as the “application” is becoming more of an active vector, but less of a focus in public patch lists. 

Detectify’s research found that at a score of 5, only 50% of CVEs targeted the modern application tech stack, with their relevance becoming much less as the CVE score increased. At a score of 9, only 20% of the CVEs targeted the modern application. Does this mean that there aren’t that many critical vulnerabilities in modern web applications? Or does it point to something more troublesome, that the CVE scoring system is not fit for purpose for the modern tech stack?   

Large share of AppSec vulnerabilities are not part of public path lists

Many vulnerabilities, particularly in modern application tech stacks, go unreported or underreported. Roughly 35% of vulnerabilities identified by Detectify’s private network of ethical hackers did not have a CVE assigned.

It is clear that many organization’s ISMS are based on a data source that is not complete, clearly biased, and that has a flawed prioritization model. The lack of a comprehensive approach to managing the entire attack surface makes business executives nervous. According to ThoughtLab’s “Cybersecurity Solutions for a Riskier World,” 41% of respondents didn’t think that their security initiatives kept up with the pace of digital transformation, 

At Detectify, we are currently working on a new framework for prioritization, by trying to leverage information about the context of assets, combined with customer priorities and our internal security expertise. We’re also keen to hear your ideas and comments on the matter – why not reach out to us on Linkedin or Twitter and lets see if we can find a model that works better than CVSS?

About the author Rickard Carlsson

A tech nerd that went from Applied physics/maths to management consultant at McKinsey to co-founding Detectify, Rickard lives on the border between tech and commercial dialogues. Rickard has grown Detectify from a group of ethical hackers with an idea on how to make the internet safer, to an international industry challenger that's 130+ people strong. Rickard has a background in tech and management consulting and has lived and worked in Sweden, India, and the US.