The Common Vulnerabilities and Exposures (CVE) database has become the unofficial “official” source for disclosed vulnerabilities. Almost every organization’s vulnerability management framework relies on it in one form or another, and whenever vulnerabilities are reported, CVE IDs are often the first thing mentioned. Almost all security tools, from vulnerability scanners to antiviruses, base their findings on CVEs as well as the National Vulnerability Database (NVD).
With CVE so ingrained in today’s vulnerability management process, does that mean CVE/NVD are the best sources of vulnerability intelligence? No. Despite industry dependency, CVE and NVD data is not always reliable and definitely not timely.
Here are the facts:
- CVE has reported almost no 93,000 vulnerabilities since its inception in 1999, and many affect major suppliers and products.
- The CVE aggregation process has systemic issues resulting in missing, inaccurate, duplicate, and no issues entries.
- CVE only adds vulnerabilities that are reported to it directly; they do not proactively search for new topics.
The public fountain operates with a visibility of 66 percent.
The purpose of having a vulnerability management framework is to ensure that your organization is aware of issues that could affect them and that you have a plan to manage the risk. But if their risk models are missing almost a third of all known vulnerabilities, how effective can they be?
While many choose not to draw attention to themselves, CVE routinely misses about 33 percent of disclosed vulnerabilities per year. And over time, this has resulted in a gap of nearly 93,000 missing vulnerabilities:
Within this delta, many of these missing vulnerabilities affect major vendors and products found in every major organization around the world. There are also many that are high to critical, as well as issues that have public exploits or can be exploited remotely. Additionally, CVE has a serious gap in coverage of third-party libraries that can pose a risk to software supply chains.
CVE does not proactively search for vulnerabilities
Why is CVE missing so many vulnerabilities? Ultimately, the answer lies in its approach to vulnerability aggregation, coupled with its inability to change with evolving trends.
CVE does not proactively search for vulnerabilities; they only collect what is directly reported to them. This is the main reason for the gap of about 93,000 vulnerabilities. But to understand exactly how this happens, it’s important to consider how the vulnerability landscape has changed since the creation of CVEs.
Vulnerability disclosures have changed by 1,711% since 2000
When CVE was formed in 1999, the number and pace of vulnerabilities being disclosed was completely different than it is now. In the year 2000, only 1,584 vulnerabilities were reported, and most came from a few dozen sources. Since then, the year-over-year totals have risen steadily, with the exception of 2006, which saw a massive spike. 2012 marked the year that reported vulnerabilities consistently exceeded 10,000. However, despite this, it was not until 2015 that MITER syntax added to support CVE identifiers with five digits.
Now, it is common to see more than 10,000 reported in a six months period. According to Risk Based Security, they added 12,723 vulnerabilities between January 1, 2021 and June 30, 2021. And at the end of last year, that number more than doublereaching 28,695.
Vulnerabilities are now everywhere
While the number of disclosed vulnerabilities has increased dramatically, the sources from which they are reported have also grown. These days, vulnerabilities are all over the Internet, a far cry from decades past where most issues could be tracked using vendor advisories and a couple of 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 everywhere. It is common for new vulnerabilities to be disclosed in random blog posts, tweets and GitHub repositoriesin addition to traditional sources. Therefore, it is not feasible to rely on a “vulnerability stork” to personally deliver all the issues you need to be aware of.
Why the CVE vulnerability delta is important and how it affects you
In a way, CVE/NVD has become the stork of this generation, where companies rely on CVE to “mint” CVE IDs to cover vulnerabilities, and then on NVD to provide a CVSS score to dictate prioritization.
There was, and still is, a real need to categorize vulnerabilities, and CVE provided a system that shaped the security industry. However, most of today’s security problems arose when security providers it began to rely on CVE and NVD as much as regular organizations.
For more than 20 years, security vendors have built their solutions around CVE/NVD data. Therein lies the issue, creating two problems:
- Decades of heavy use of CVEs have led some to believe that CVE IDs are “seals of authenticity” for vulnerabilities.
- The misconception that CVE is complete, yet unaware of nearly 93,000 vulnerabilities, means that organizations that rely on security providers that replicate CVE/NVD what’s more inherit the delta as well as other CVE errors.
Vulnerabilities do not depend on CVE IDs
Organizations should be aware that CVE IDs do not validate vulnerabilities. By definition, a vulnerability it is a failure in computer software or hardware that affects confidentiality, integrity, and availability by crossing privilege boundaries.
A CVE assignment does not influence the impact of a vulnerability. All a CVE ID indicates is that the problem has been reported to MITRE. Although it may seem that only valid problems would be assigned an assignment, this is not always the case.
Last year, 307 CVE IDs were considered Not a vulnerability (NAV), and many of them can still be found on CVE. Unfortunately, some of them haven’t been updated to reflect this, which means security teams unaware of the new details will assume they still pose a risk.
NAVs occur for two reasons, the first is that the issue was not considered to be a vulnerability after its initial disclosure, or validation checks were not performed. One might think that CVE has improved its processes to reduce the number of NAV entries, but the data shows that NAV CVE assignments have increased progressively over time.
Security vendors that replicate CVE data will inherit bugs
Security vendors that rely strictly on the public source will likely replicate NAV CVEs, but more importantly, they will be unaware of nearly 93,000 known vulnerabilities. Are you comfortable knowing that your CVE-based vulnerability scanner can’t immediately identify 33% of issues that may affect your systems?
Professionals are likely to know that the scan delta is actually much higher, when taking into account naturally occurring coverage gaps, and the fact that most scanning technologies often look for only a third of CVEs. We’ll cover the main timeliness issues with signatures in a later article, but the important thing to know is that users won’t be aware of innate coverage gaps. Scan reports won’t tell you that your data subset is incomplete, so if you’re not aware of CVE’s innate issues, you’re likely to be lulled into a false sense of security.
The end result is more work on your part.
In addition to missing NAVs and vulnerabilities, CVE/NVD replication creates another critical problem: existing CVE and NVD data.
MITER and NIST (the maintainers of NVD) have had historical issues with data accuracy and lack of metadata resulting in timeliness issues, and most of it is due to how vulnerabilities are reported. Since neither organization actively searches for new information, they rely heavily on what is provided when input is submitted.
Technically, anyone can submit a vulnerability for a CVE assignment, and as such each entry tends to vary greatly. Titles may be misleading or vague, vital metadata such as the exploit and solution may be missing, or the CVSS could be rated poorly if based on poor data. There are even CVE IDs being published that don’t even list the affected vendor or product.
At the end of the day, current CVE/NVD data creates more work for the user, who spends more time validating and researching input than managing it. With comprehensive vulnerability intelligence, you can get actionable details 21 days faster on average compared to CVE, eliminating the need to investigate issues and enabling faster remediation.
Having a comprehensive source of vulnerability intelligence is essential to ensure the risk is remediated in a timely manner. sign up for a vulndb free trial to gain visibility into vulnerabilities that the public source misses, while experiencing comprehensive and detailed CVE/NVD coverage.
The charge Why the Full Vulnerability Intelligence Picture Relies on Data Beyond CVE/NVD first appeared in Flash point.
*** This is a syndicated Security Bloggers Network blog from Blog – Flash Point written by Curtis Kang. Read the original post at: https://www.flashpoint-intel.com/blog/looking-beyond-cve-and-nvd/