Common vulnerabilities and exposures (CVEs) contain actionable details that can help address your security concerns. Here's how to get more from CVE data.

Jerry Gamblin, Director of Security Research at Kenna Security (now part of Cisco)

October 5, 2021

4 Min Read
Digital padlock
Source: marcos alvarado via Alamy Stock Photo

Most people only ever give common vulnerabilities and exposures (CVEs) a passing glance. They might look at the common vulnerability scoring system (CVSS) score, determine whether the list of affected products is a concern for them, and move on.

That's not surprising when there's more to sift through than ever. Considering there have been more than 14,000 CVEs and counting published in 2021, it isn't practical to try and investigate them all. We are on pace to see nearly 40% more CVEs in 2021 than last year.

When you do see a CVE that might apply to you, how can you tell? What should you be looking at to determine if it's worth your time?

Unfortunately, you can't just read the title of a CVE and know whether it's safe to ignore. Within CVE data, there are actionable details that can help address your security concerns, including auxiliary data points, like common platform enumeration (CPE) specifics. It requires a little bit of extra work, but there could be a big payoff if you identify and patch a vulnerability before it's exploited.

Let's dig deeper on how to get more out of a CVE.

Where CVEs Come From
When you hear about vulnerabilities, it's often without the nuance of software versions or other descriptors. It's a much more impactful headline to just say "Microsoft Office Vulnerability" than to specify that only older versions are vulnerable. Those who write CVEs often know this but don't go out of their way to be overly descriptive because they see the notoriety that comes with "their" CVE making big waves in the media.

There are no standards for what constitutes a CVE, just suggestions. With the popularization of CVE numbering authorities (CNA) like GitHub, any user can request a CVE and it will run through the automated system. There are 184 CNAs across 13 countries, but the MITRE Corporation is the primary one. Having so many different CNAs creating CVE records has made it even more difficult to establish standards.

With more than 50 CVEs published every day, it is unrealistic to go through all of them individually, and some become useless because there are missing data points or are simply inaccurate. This has made the National Vulnerability Database (NVD) more like "best effort" and less like the "source of truth" it's intended to be.

For example, a description field within a CVE record can only be 500 characters, which isn't enough to fully describe what's going on. Linking back to the original security advisory describing the vulnerability and other resources can help you piece together why a vulnerability matters, but it still may not tell you everything you need to know.

Read the Advisories
One reason CVEs need more than a passing glance is that advisories should contain useful data on whether a remediation or patch exists for the CVE that may not be included in the CVE record.

VMware is one company that does a great job sharing its remediation data when it publishes a security advisory.

How CPE Data Can Help
Within a CVE, there is CPE data, which often plays the most meaningful role in explaining exactly what exactly is at risk.

There are four CPE data points in the JSON Scheme that are invaluable when investigating CVEs: VersionStartIncluding, VersionStartExcluding, VersionEndIncluding, and VersionEndExcluding. This is what allows you to narrow the vulnerability down to particular versions and, if your configuration management database (CMDB) is up to date, you can cross reference what you're running to find out whether this is important to you.

A major issue is that the CVE recorded isn't required to include affected versions. One example is that Microsoft stopped including versions in its CPE data when it switched to Chrome Edge, making its CPE data useless. In a perfect world, the NVD would make those four optional data points mandatory so users would better understand what is affected. When versions aren't correctly reported, you're left with two options: Either you consider every CVE that might affect your product and end up with false positives that clog your database, or you ignore anything that isn't specific and have false negatives, which is even worse for your security.

Commit to Digging Deeper
Simply by going beyond the CVE itself, you're investigating more than most. The deeper you dig into available data, the more you'll be able to remediate issues that affect your security. Take advantage of the information and any tools that may help.

The NVD provides an API that can help you look up a lot of this data that so many people ignore. Spending a few minutes to investigate which CVEs you need to be most concerned with could end up being a key investment that saves much more time and money down the road.

About the Author(s)

Jerry Gamblin

Director of Security Research at Kenna Security (now part of Cisco)

Jerry Gamblin's interest in security ignited in 1989 when he hacked Oregon Trail on his 3rd grade class Apple IIe. As a security evangelist, researcher, and analyst, he has been featured on numerous blogs, podcasts and has spoken at security conferences around the world. When he's not helping companies be more secure, he's usually taking his son to swim lessons or hacking embedded systems in cars and IoT devices. He is principal security engineer at Kenna Security, now part of Cisco.

Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

You May Also Like


More Insights