Why the Full Vulnerability Intelligence Picture Depends on Data Beyond CVE and NVD

If your risk models are missing nearly one-third of all known vulnerabilities, are they effective?

The Common Vulnerabilities and Exposures (CVE) database has become the unofficial “official” source for disclosed vulnerabilities. Nearly every organization’s vulnerability management framework relies on it somehow. To the point that whenever vulnerabilities are mentioned, CVE IDs are often the first thing that comes to mind. Nearly every security tool, from vulnerability scanners to antivirus, base their findings on CVE, as well as the National Vulnerability Database (NVD).

With CVE so ingrained into the current vulnerability management process, does it mean that CVE/NVD are the best sources for vulnerability intelligence? No. Despite the industry’s dependency, data from CVE and NVD isn’t always reliable and definitely is not timely. In fact, CVE has a significant coverage gap that is likely holding your vulnerability management program back.

Here are the facts:

1. CVE has failed to report over 100,000 vulnerabilities since its inception in 1999, with many affecting major vendors and products.
2. CVE’s aggregation process has systemic issues that result in missing, inaccurate, duplicate, and non-issue entries.
3. CVE only aggregates vulnerabilities that are directly reported to them; they do not proactively seek new issues. This results in CVE having a very real coverage gap.

CVE / NVD operates on 66 percent visibility

The purpose of having a vulnerability management framework is to ensure that your organization is aware of dangerous issues. As such, most have plans in place to remediate risk. But if your risk models are missing nearly a third of all known vulnerabilities, how effective can they be?

While many choose to not bring attention to it, CVE routinely misses around 33 percent of disclosed vulnerabilities per year. And over time, this has resulted in a gap of over 100,000 missed vulnerabilities.

Within this delta, many of these missing vulnerabilities affect major vendors and products. Many of them are used by every major organization in the world. There are also many that are high-to-critical, as well as issues that have public exploits or are remotely exploitable. In addition, CVE has a serious coverage gap of third-party libraries that may pose a risk to software supply chains.

CVE / NVD does not proactively seek vulnerabilities

Why is CVE missing so many vulnerabilities? The answer lies in their approach to vulnerability aggregation, in addition to their inability to shift with evolving trends.

CVE does not proactively seek vulnerabilities; they only collect what is reported directly to them. This is the primary reason for the gap of over 100,000 vulnerabilities. To exactly understand how this happens, it’s important to learn how the vulnerability landscape has changed since CVE’s creation.

Vulnerability disclosures have changed by 1711% since 2000

When CVE was formed back in 1999, the number and rate of disclosed vulnerabilities was completely different. In 2000, only 1,584 vulnerabilities were reported, and a majority came from just a few dozen sources. Since then, year-to-year totals steadily increased, with the exception of 2006, which saw a massive uptick. 2012 marked the year that reported vulnerabilities consistently surpassed 10,000.

However, despite this, it wasn’t until 2015 that MITRE added syntax to support CVE identifiers with five digits.

Now, it is common to see over 10,000 reported in a six-month period. Flashpoint analysts aggregated 12,723 vulnerabilities between January 1, 2021 and June 30, 2021. And by the end of last year, that number more than doubled, reaching 28,695. And since then, the total number for vulnerabilities disclosed in 2021 reached over 30,000.

Vulnerabilities are now found everywhere. Not just CVE / NVD.

While the number of disclosed vulnerabilities has dramatically increased, the sources of where they are being reported has also grown. These days, vulnerabilities are found all across the internet, a far-cry from decades past. Back then, the majority of issues could be tracked using vendor advisories and a couple vulnerability mailing lists.

The number of new software, vendors, vulnerability researchers, and hobbyists has increased exponentially. Resulting in a highly volatile environment where issues and their details are reported across every medium. It’s common for new vulnerabilities to be disclosed on random blog posts, tweets, and GitHub repositories, in addition to traditional sources. Therefore, it isn’t feasible to rely on a “vulnerability stork” to hand-deliver all the issues you should be aware of.

Why the CVE coverage gap matters and how it affects you

CVE/NVD has become this generation’s vulnerability stork, where enterprises rely on CVE to “mint” CVE IDs. Then they wait for NVD to provide a CVSS score to dictate prioritization.

There was, and still is, a real need to categorize vulnerabilities. To CVE’s credit, they provided a system that shaped the security industry. However, most of today’s security problems took form when security vendors started to rely on CVE and NVD just as much as regular organizations.

For 20+ years, security vendors have built their solutions around CVE/NVD data. That therein lies the issue, creating two problems:

1. Decades of heavy CVE use have caused some to believe that CVE IDs are “seals of authenticity” for vulnerabilities.
2. The mistaken notion that CVE is complete, while unaware of over 100,000 vulnerabilities. This means that organizations relying on security vendors who replicate CVE/NVD will also inherit the coverage gap as well as CVE’s other mistakes.

Vulnerabilities are not dependent on CVE IDs

Organizations need to be aware that CVE IDs do not validate vulnerabilities. By definition, a vulnerability is a flaw in computer software or hardware that impacts confidentiality, integrity, and availability by crossing privilege-boundaries.

An assignment from CVE has no bearing on the impact of a vulnerability. All a CVE ID indicates is that the issue has been reported to MITRE. Although it may seem that an assignment would only be given to valid issues, this isn’t always the case.

Last year, 435 CVE IDs were deemed Not a Vulnerability (NAV). Many of them can still be found in CVE. Unfortunately, some of them have not been updated to reflect this. This means that security teams unaware of new details will assume that they still pose a risk.

NAVs happen for two reasons, the first being that the issue was deemed not to be a vulnerability after its initial disclosure, or that validation checks were not performed. One may think that CVE has improved their processes for reducing the number of NAV entries, but data shows that NAV CVE assignments have progressively increased over time.

Security vendors replicating CVE data will inherit mistakes

Security vendors strictly relying on the public source will likely replicate CVE NAVs, but more importantly, they will be unaware of over 100,000 known vulnerabilities. Are you comfortable knowing that your CVE-based vulnerability scanner is immediately unable to identify nearly 33% of the issues potentially affecting your systems?

Practitioners are likely aware that the scanning delta is actually much higher, if accounting for naturally occurring coverage gaps, and the fact that most scanning technologies often look for only a third of CVE. We’ll explain the major timeliness issues that signatures pose in a later article, but the important thing to know is that users won’t be aware of the innate coverage gaps at all. Scanning reports will not tell you that its data subset is incomplete, so if you aren’t aware of CVE’s innate problems, you will likely have a false sense of security.

The end result is more work on your part

Aside from NAVs and missing vulnerabilities, replicating CVE/NVD bequeaths another critical problem – CVE and NVD’s existing data.

MITRE and NIST (the maintainers of NVD) have had historical problems with data accuracy and missing metadata that result in timeliness issues, and most of it is due to how vulnerabilities are reported. Since neither organization actively seeks new information, they heavily rely on what is provided when the entry is submitted.

Technically, anyone can submit a vulnerability for a CVE assignment and as such, each entry tends to greatly vary. Titles can be misleading or vague, vital metadata like exploit and solution can be missing, or the CVSS could be scored wrong if it is based on poor data. There are even CVE IDs that are published that don’t even include the affected vendor or product.

At the end of the day, current CVE/NVD data creates more work on the user’s end where they spend more time validating and researching the entry rather than actually managing it. With comprehensive vulnerability intelligence, you can get actionable details 21 days faster on average compared to CVE, eliminating the need to research issues enabling faster remediation.

Detect more issues and remediate faster with Flashpoint

Having a comprehensive source of vulnerability intelligence is essential to ensuring that risk is remediated in a timely manner. Sign up for a free VulnDB trial to gain visibility into the vulnerabilities that the public source misses, while experiencing full, detailed coverage of CVE/NVD.