CVE Data Is Often Misinterpreted: Here's What to Look For

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.