Preface
When I started writing this, I was still on the CVE editorial board, which I was removed from in 2018. That means I have been taking notes and working on this blog for over eight years. It’s a case of more and more evidence piling up and me not having time to pick a time to dedicate to completing and publishing. Bear with the start of this if it sounds a bit dated but the problem is a lot more relevant today than it was then even. This blog has now, literally, been a decade in the making.
Since then it has been forced to adapt to the changing landscape within the CVE ecosystem. Today this blog is rapidly becoming obsolete as we enter the “vulnmageddon” or “vulnpocolypse”, names for the incredible jump in disclosures due to large language models (LLM) aka the so-called “AI”. But I think it is still important to finally publish this for more perspective on the history of vulnerability databases (VDBs).
Note that these are my observations and I am not a customer of any of the services I mention in this blog, and I don’t consider them a real competitor the database I work on (VulnDB) because we operate very differently and we serve customers that want broader and more complete vulnerability intelligence than offered by CVE and associated information.
(Long) Introduction
I’ve said quite a lot on the topic of the Common Vulnerabilities and Exposures (CVE) project over the years. In addition to being one of the most vocal critics of the project, I was on the CVE editorial board to (supposedly) help guide the project and improve it for the industry. I dedicated a lot of my personal time to try to improve the system as a whole. My relationship with CVE is a classic ‘love-hate’ relationship. Some days I hate that I love the idea of it, other days I very much love to hate it.
CVE clearly has, or had, a lot of value in the security industry. Unfortunately, that value has been dwindling steadily for the last fifteen years. One of the strongest and most valuable purposes it serves, has been drowned out as the flood of vulnerabilities disclosed has evolved in so many ways. CVE is not meant to be a ‘comprehensive’ vulnerability database, and the maintainers should readily admit this if asked, but they haven’t. The model for aggregation precludes them from even pretending that comprehensiveness is the goal. The more valuable function it serves is in a pre-disclosure assignment capacity, typically for coordination with vendors.
In the early 2000s, it was proven that multiple researchers would find the same vulnerability and work with a vendor to fix it and coordinate the disclosure. Having a single identifier for a specific issue better let the vendor coordinate the fix among multiple researchers. If Bob, Alice, and Eve all reported the same issue to Microsoft, a single identifier could be shared back with all of them. “Thanks for your report, we’ve been notified by several researchers of the same issue, and we are using CVE-2014-9999 to track it.” There is incredible value there. This has only become more prevalent with a single vulnerability being mutually discovered by ten or more people, or as many as 17 in one Microsoft advisory in their messy acknowledgements.
Break away from that valuable service, and what are you left with? An overpriced tax-payer funded vulnerability database that is not comprehensive, is not timely, requires more work by the end user than should, and has now offloaded as much work as possible to other organizations. What value does that give the industry exactly? It gives the industry a false sense of security, something we’re all too familiar with, as we use that term for shoddy vulnerability scanners, shoddy anti-virus, and any other shoddy security technology. It’s the illusion that the security provided is comprehensive, complete, and timely will truly protect you.
Back in 2004, I sent in a Freedom Of Information Act (FOIA) request asking for the financials of the CVE program, to better understand how CVE operates. I eventually got back a mish-mash of documents that MITRE was required to give up as part of their government contract. Those documents showed that tax-payers contributed around five million dollars a year for CVE. Oh wait, lest we draw the ire of the CVE project, that number isn’t accurate. That five million covered the CVE, OVAL, and PADC projects and MITRE staff were quick to point out that CVE doesn’t get all of that five million and that it is shared with other projects they run.
The FOIA results clearly indicated the total was for the three projects mentioned above. But MITRE’s argument that it covered other projects makes me wonder which ones… perhaps CPE, CWE, CME (now MAEC apparently?), CWSS, CWRAF, CCE, CAPEC, CEE, CVRF, CRRMA (?), STEP, and how many others I can’t remember or find via Google. At what point does it become clear there is a serious level of academic masturbation at play? Do we need an increasing amount of ways to catalog threats, when MITRE isn’t able to track ~ 30% of the publicly disclosed vulnerabilities that we know of, and hundreds of thousands past that? Regardless, I would bet a shiny bitcoin that a majority of that five million went to CVE. Subsequent FOIA requests clearly back up that notion. Getting all of my FOIA requests published is a priority now.
The Brief Interlude
Breaking from CVE, are you curious about what else MITRE is involved in? Looking at page 10 of their brochure, they are involved in the US drone program, but use pretty words to describe it… but we can read between the lines. Page 12 talks about their “four decade” effort to secure the government infrastructure, which has been plagued with breaches for … four decades. They are helping the FAA with the ‘NextGen’ system, which the GAO warned was vulnerable to hacking. Page 15 talks about MITRE helping the Census Bureau, which maintains a long list of ‘errata’ about their activities. Page 17 talks about MITRE’s involvement with technology regarding the judicial system, where too many innocent people are waiting to be freed of crimes they did not commit, once technology catches up.
New paragraph, because the PDF referenced above is a train wreck, but actually gets worse. Page 20 talks about “patient safety“, in the context of medical mistakes and security. CVE, the system to track vulnerabilities in medical systems, has specifically ignored medical software for most of the 25 years it has been active. If that isn’t enough, consider page 21 of 57 where they all but admit they are developing software that lets the government better track and monitor citizens on the Internet. Page 23 talks about how MITRE is helping the VHA, which has been under increasing criticism for the last few years. Page 25 talks about defending our GPS system from attackers… the same system that was already proven to be insecure. Page 27 goes into “countering cyber threat actors“, which have compromised U.S. interests as far back as 2010 and MITRE itself as recently as 2024. Page 30 informs us that “commercial space industry [may] take off as experts predict“. Written in their 2014 report, while being totally blind as to the efforts of SpaceX and others.
At this point, it isn’t worth going into the rest of their self-congratulatory masturbation. The last two paragraphs are obviously a deviation from my original point, as I read what they offered and scoffed at every page. The point of this is you may find yourself asking what qualifications does MITRE have to do any of this, let alone run a VDB used internationally. None really, other than being a Federally Funded Research and Development Center (FFRDC) which allows them to get contracts from the U.S. government without bidding and without competition. An organization founded by ex-military with deep ties to the government from day one…
Applying Lipstick…
So let’s get back to their most historic and well-known offering in Information Security: CVE. I’ll structure the rest of this blog in a way that lets you read the abbreviated issue and move on if you’d like, or you can stay to read some of the supporting evidence. The fundamental problem is that too many people and organizations want to put lipstick on the pig that CVE has become, while not taking any interest in making the underlying data better. The simple reality is that almost every vendor advertising their own VDB is just OEM CVE. Companies will use CVE’s data, wrap a slick interface around it, occasionally add a tiny bit of their own metadata, and call it their “own” VDB. They want to petty it up, but not enrich the data that they are using from MITRE. Worse, most that apply the lipstick don’t even understand the fundamentals including how CVE gets the data, what QA is performed (literally zero), and what biases are introduced due to MITRE’s process.
There are hundreds of security companies that do this. A vast majority only wrap it in their website color/style scheme and do no further enrichment. It’s a simple data pull from CVE or the National Vulnerability Database’s (NVD) API that is fully automated. In a majority of cases I have seen, there is no wording that clearly states that “their” database is just a CVE clone either, which is a level of dishonesty that doesn’t sit right with me. In some cases the company may add enrichment in the form of metadata, but often that is part of their commercial access. For those that do no enrichment at all, they do not have their own vulnerability database like claimed. They just have a copy of CVE which is available to anyone. Some companies will do the above and advertise it in spectacularly absurd ways:
“Revolutionary, AI-powered vulnerability intelligence resource that goes well beyond traditional static databases” and “real-time context, extended coverage, and actionable remediation insights.” Really? I personally doubt that they maintain a team of analysts that actually enrich the data like that because that is increasingly prohibitively expensive and time consuming. Even before the mid 2026 uptick in disclosures due to large language model (LLM) assisted research, a significant amount of entries in CVE did not come with solution information. Then enriching that data further and doing so in a timely fashion is exactly what I have done since 2004 while managing a VDB. I know the score.
So how many ways can we see companies take inferior vulnerability data (CVE / NVD), and dress it up? Worse, these same companies stay impressed with themselves as if their new “analysis” really brings great insight or value. In reality, they too are missing tens of thousands of vulnerabilities every year, and almost every company just makes it more dressed-up, not more actionable (e.g. more programmatically accessible, additional or more accurate risk scoring, better CPE data, more timely, more enrichment, etc.).
If your “vulnerability database” is 99% or more CVE data, then you are just offering lipstick on that pig that is CVE. Pigs are known for being slow and spending time in the mud, so I find that to be a good analogy. Until recently, NVD added all of the enrichment to CVE which was fairly minimal, but enough to make the data programmatically usable and actionable. Common Vulnerability Scoring System (CVSS), Common Platform Enumeration (CPE), and Common Weakness Enumeration (CWE) were historically the value-add with NVD. They expanded that to pull in Exploit Prediction Scoring System (EPSS) in recent years. But that is basically all that has been offered in the lifetime of the CVE ecosystem.
My biggest issue with this is that companies spend a fair amount of money to pull the data, reformat it, and add occasional enrichment without contributing back to the original source. Of course, MITRE makes that prohibitively impossible and while NVD was receptive to feedback, they can not even make edits to the CVE description without going back to MITRE. And of course, MITRE makes that kind of feedback and improvements near impossible as well. So you end up with a mostly closed loop of source data and hundreds of companies spending a lot of money that could be better spent if the ecosystem was managed properly. Ultimately this just hurts everyone world-wide that uses CVE data.
In the first paragraph of this section, I mentioned biases that are introduced in MITRE’s process. If you are wondering why that bias might matter, check out a presentation by Steven Christey (former CVE manager) and myself titled “Buying Into the Bias: Why Vulnerability Statistics Suck” (PPT), presented at Blackhat Briefings in 2013. There are many ways bias can get injected into vulnerability data (and the resulting statistics) and some of them are trivial to understand while others require a better understanding of the underlying ecosystem. Third-party analysis of CVE data rarely shows the caveats that must accompany the data and images that give any confidence the person understands these issues. Note, bias happens at every VDB, not just CVE. But it’s different when you clearly understand the biases and better account for them in your processes.
CVE has been facing a tipping point for years as the program is causing industry-wide issues that are best described as grotesque. Due to MITRE not managing the program properly, a considerable amount of extra work has historically been dumped on the NVD’s lap, and they have subsequently failed to keep up despite an enormous budget of their own. With their recent announcement that they will no longer enrich most of the vulnerabilities, it has severely crippled the ability for organizations around the world to do proper vulnerability management.
Meanwhile, MITRE has seriously ramped up the CVE Numbering Authority (CNA) program in the last few years. In short, MITRE taps a company to become a CNA who can then assign CVE IDs on their own, without going through MITRE every single time. The principle of doing this is sound and should improve the ecosystem as more vulnerabilities get assigned, often from organizations that are the single source of truth (SSoT) such as the vendor. However, MITRE has failed to manage the program effectively and they keep minting new CNAs who assign no CVE IDs even a year after minting, some that disclose vulnerabilities without a CVE ID, most of which do not assign CVE IDs for previously disclosed vulnerabilities, and other failures. Worse, many of the CNAs are submitting incomplete data, do not bother enriching the data, and cause more work for downstream consumers of the data. As I write this, a newly minted CNA just published two advisories containing a total of five dummy CVE IDs.
Recent initiatives to get better data such as the Authorized Data Publishers (ADPs) role will help, in theory. But even if a handful of the more active CNAs adopt it, it is far from enough. The Cybersecurity and Infrastructure Security Agency (CISA) is still currently the only ADP and while they do enrich a fair number of vulnerabilities, it is still a fraction of the overall volume. MITRE still has not managed to mint more ADPs to provide better enrichment of the base data even as NVD gives up.
Different Shades of Lipstick
One argument some folks may have with this blog is that CVE data can be enriched, and some CVE entries are, which brings value. Sure, potentially! CVSS, CWE, EPSS, and Stakeholder-Specific Vulnerability Categorization (SSVC) are the ways to make CVE data usable at all. But fundamentally when the base data is unverified and has a history of serious inaccuracies, that enrichment gets skewed and may not be accurate.
The current CVE workflow has a CNA or MITRE issuing an ID where the latter is done via forms and automation. If the CVE is published through MITRE there is no quality assurance performed. That means that the only provenance may be a URL that is unavailable (404) and we’re left to trust the description. If the researcher cannot figure out how to cite a publicly available disclosure, we shouldn’t trust them to write the CVE description either. That description only needs one typo in a version, misidentifying a product (happens more often than most realize), or misdiagnoses a root cause and/or impact.
Any one of those can mean the subsequent CVSS, CPE, EPSS, and SSVC are all incorrect. If that happens even 5% of the time it can significantly impact vulnerability triage efforts. If such a mistake leads an organization to misprioritize something it can have real-world consequences in the form of a compromise. If such a compromise is carried out by a skilled attacker or ransomware crew, that one typo can have serious financial and logistical fallout.
Vulnerability intelligence must be based on accurate information, otherwise the entire process can crumble.
Removing the Lipstick
With that, let’s look at some of the companies that are taking CVE, making it look different, and sometimes reselling their services around that data. Basically, they are putting their shade of lipstick on that CVE pig. I have no grudge or issue with any of these sites, they just serve to illustrate my point. In many cases the nuances are subtle where the wording implies something greater than what the offering actually is. We’ll start with Shai-Hulud, a worm that infected and backdoored many legitimate packages that became trojaned distributions, serving up malicious code to any software that depended on them. This is known as a supply-chain attack. In this particular case it was particularly nasty, discovered in the wild as a zero-day, and subsequently exploited a considerable amount of times as software pulled in the dependencies.
Before we proceed let’s manage expectations. Does such an issue that is not a classic vulnerability warrant inclusion in CVE? Well, mileage may vary because MITRE has never established a firm policy. But the fact that there are numerous assignments for such cases tells me it is fair game. We see recent examples like CVE-2026-44484 or CVE-2026-48027 and a few dozen going back to CVE-1999-0661 disclosed in 1994. That’s plenty of prior art to justify a trojaned distribution being included in CVE. Even worse, there are a few dozen CVE assignments for cases that should not have been included such as CVE-2017-16056 and CVE-2023-1512 (still RESERVED!) for instances of typo-squatting legitimate packages. CVE very clearly is not a malware cataloging system, that’s what CME was for, and yet there are plenty of IDs for this. MITRE has no consistency and no quality assurance to prevent this from happening or subsequently REJECT such IDs that slip through.
Vulnmon
So we have an extremely high-profile zero-day issue that impacted thousands of organizations that to this day does not have a CVE ID assigned. Ignoring that outright negligence by MITRE, we’ll use it because it is a good litmus test if a VDB is agnostic of CVE or just a CVE clone wearing lipstick. That said, here is our first example:
CVEdetails
Perhaps one of the more well-known sites for a long time is CVEdetails. One of the reasons for that is it offers decent graphs and statistics on the CVE data set. But it is still limited to CVE for all of its information meaning they just apply a lot of lipstick to the pig. For this example let’s take a different approach and look at CVE-2010-2773 (Novell Teaming Access Manager), CVE-2011-3333 (VLC Media Player), CVE-2012-5719 (Cisco NX-OS), CVE-2013-1625 (Titan FTP Server), CVE-2014-1630 (TRENDnet), or CVE-2015-5676 (FreeBSD). It took me just a couple minutes to identify all of these which are still in RESERVED status at CVE, meaning they are not found at CVEdetails at the time of this blog (just click those links!).
The catch? These have all been associated with public disclosures in their respective years and have been in VulnDB with details since. Note the CVE prefix year on each and you will see they are all over 10 years old too. Pretty statistics can only go so far when it comes to vulnerability intelligence, because those statistics do not include publicly disclosed vulnerabilities that may impact your organization. If you click through you may notice conflicting information from this site, bolding below is my emphasis.
Registered users have early access to information on reserved but not yet published CVEs. Log in or register for more information.
This site only contains valid CVE entries. Rejected or reserved CVE entries are not included in our database. Our data might be a slightly behind CVE.org and NVD, and new CVEs may not be available immediately.
So which is it? I’m not a customer of SecurityScorecard, who runs the site, so I can’t validate it. But I would bet a shiny nickel that the ones I linked are not available after authentication either. Short of running a CVE-agnostic database that proactively looks for vulnerability disclosures it just likely isn’t there. Past that, doing “meta-analysis” like they do introduces misleading data. Their “by type” chart for example is based on CWE but consider the “Overflow” category. Does that include all types of buffer overflows including e.g. out-of-bounds read issues? Those are decidedly less severe than other types but likely get merged in, or dropped completely. Who knows. At least they retired their tagline, “The ultimate security vulnerability datasource”, sometime in 2023.
SECALERTS
SecAlerts Pty Ltd. runs a site/service called SECALERTS that is another good example of lipstick on the CVE pig. In this case, they profit to some degree on the back of CVE data almost exclusively, wrapping it into an alerting service with tiered pricing options. Occasionally watching their evolution over the years has been entertaining. Something that stood out many years ago was how they tried to talk around zero day coverage, using laughable sales-speak.
While they define “zero-day” correctly, in my opinion, they go on to say they cover it by matching ZDI advisories because they “often” publish zero-days that the vendor has not fixed. Sure, that’s true, but so do a lot of other sources including some vendors ironically. That isn’t “zero-day” coverage by any stretch of the imagination, making this a really tacky shade of lipstick. As of today they make another bold and amusing claim that their offering “matches every disclosure against your software stack“. This is every large organization’s Achilles heel because not a single one actually has a complete asset inventory. So such a service, no matter who it is including VulnDB, must disclaim that vulnerability intelligence only goes so far if using the asset mapping approach due to that limitation.
The extra application of lipstick here is based around their claims for watching “hundreds of sources” in addition to CVE. That’s absolutely adorable and was antiquated even in 2005. If you aren’t watching many, many thousands of sources, you aren’t really beginning to provide actual vulnerability intelligence. Sorry, I don’t make the rules. At least they retired their “Never miss a vulnerability again!” tagline. It’s a fact CVE isn’t as broad and comprehensive as many think, including SecAlerts Pty Ltd. apparently. Amusingly, this entire “solution” could now be replaced with a Claude prompt.
Etc. Etc.
From here instead of pointing out more of the above, let’s take a quick spin down a bit of the tooling available for using CVE data. First off, there are a lot of tools out there that use CVE data in various ways from alerting to dashboards to trendings and more. Second, please remember my repeated warnings and disclaimers above! CVE data is incomplete, not validated in any way by MITRE, and full of errors. Building any tool or service without understanding and appreciating that is inviting subsequent errors and unrealistic expectations. If you use a tool based on CVE / NVD data and it does not disclaim this, you should walk away from it. Here’s a sampling:
- CVE Half-Day Watcher – “is a security tool designed to highlight the risk of early exposure of Common Vulnerabilities and Exposures (CVEs) in the public domain.”
- CIRCL Data Feed – is a “data feed includes a ranking of the likeliness of abuse in Luxembourg, which is based on CIRCL’s incident statistics.”
- CVESearch – is a “full text database search in #CVESearch turns it into “the Google of vulnerabilities””. Because Google doesn’t work with CVE?
- Facebook’s nvdtools – is a “set of tools to work with the feeds (vulnerabilities, CPE dictionary etc.) distributed by National Vulnerability Database (NVD)”. This repository was archived by the owner on Dec 1, 2024.
- VIA4CVE – is a “sister Project of #CVESearch: #VIA4: a Vulnerability Information Aggregator for CVEs.”
- Saucs – is “a free security platform based on CVE: subscribe to products and receive their vulnerabilities”. Domain is for sale today.
- CVE-Scan – “Development #CVESearch, Currently 2 plug-ins loaded: CVE-Scan and a RSS feed generator.”. Hosting domain not available, not even a Wayback snapshot.
- OpenCVE / opencve.io – is “a Vulnerability Intelligence Platform that helps you monitor and manage CVEs efficiently.” Their website says “OpenCVE aggregates vulnerability data from NVD, KEV, MITRE, Red Hat, CISA and more.” What is KEV in that specific context? Including CISA separate from KEV implies two separate sources, but KEV (“Known Exploited Vulnerability”) is a designation for a vulnerability, and CISA KEV is a specialized database.
- Vicarius.io – offers you to “find the latest CVE releases with Vicarius’s free, unlimited access to the world’s software CVE database.” Because apparently CVE’s website somehow doesn’t?
- vFeed_IO – “demonstrates how [it] can expand your CVE entries and enrich your vulnerability mgmt system within secs”. This repository was archived by the owner on Dec 19, 2024.
- CVEtrends.com – for “a way to monitor trending CVEs on Twitter”. Service now unavailable due to Twitter API changes. This one actually had a little value potentially but looking at an older snapshot suggests this offered little value.
- HuntDB – was “a simple dashboard to help track/search CVEs and security vulnerabilities in near real-time. No fancy stuff – just a clean interface to see what’s burning in the security world right now.” Now redirects to a different domain with a commercial offering, still built on CVE data mostly, but offers tracking non-CVE vulns to some degree. This is how you actually build on CVE data and improve one aspect; all the vulnerabilities that never get a CVE ID.
Conclusion & Moving Forward
This blog is a decade overdue as I started it over eight years ago. Sadly, it is just as relevant today as it was then. CVE had a lot of potential but it began failing the industry right out of the gate. I have a world of respect for Steven Christey-Coley and the efforts he made curating CVE for over a decade. I know very well the editorial standards he demanded and rightfully so. Unfortunately, the “come to us” model for assigning an ID and including it in the database effectively hamstrung it from day one. Since Christey-Coley moved on from CVE the standards went away overnight. Even five years ago one staff member was explicitly told not to fix errors in CVE descriptions. This is a simple reality of CVE and building tools on that data comes with pitfalls.
Companies that blindly take CVE data, wrap it in prettier HTML or create graphs on it, and call it their own vulnerability database are disingenuous at best. That is a level of deception that is pathetic in my eyes. Rather than enriching and improving questionable data, these companies opt instead to profit off taxpayer funded work without truly giving back to the community in too many cases. These companies are not helping with the problem of vulnerability management, at least, not like they think they are.
“What can we do?”, as John Oliver likes to ask at the end of his wonderful show. We can start by doing less tooling around bad data and focus more on making it better data. I fully understand there is a huge hurdle we call MITRE making this difficult, as there is no way to directly and efficiently contribute that back to the base CVE data. But doing third-party analysis, calling out disclosures that are not vulnerabilities as such, and pushing MITRE and NVD to improve are a cause worth taking up. Trust me on this, as I have been doing it for a long time. Despite my continued criticism of CVE, the anger and frustration that arises from it, I am still fighting the good fight two decades later.
Less dressing up bad data with pretty shades of lipstick, and more making the ugly data beautiful through actual analysis and work is the solution.
Leave a Reply