Brian Martin January 27, 2026 6 Min Read Source: Warakorn Hamprasop via Alamy Stock Photo OPINION The Common Vulnerability Enumeration (CVE), now dubbed Common Vulnerabilities and Exposures, was created in 1999 to fill a void that never really existed to begin with. The CVE initiative was born out of a white paper titled " Towards a Common Enumeration of Vulnerabilities, " written by David Mann and Steve Christey-Coley. The gist of the paper described the need for a "common enumeration" of vulnerabilities. However, it overlooks that there was already a broad coverage public vulnerability database (VDB) that had existed for more than a year. By the time of CVE's launch, ISS (later acquired by IBM) maintained a fully public VDB, as of August 1997. A company I helped found, Repent Security Inc., also offered a commercial subscription to a VDB by early to mid-1998. Before that there were other efforts to catalog vulnerabilities, all of them to varying levels of completeness, but none fully comprehensive, of course. MITRE's desire for a new VDB invokes the classic XKCD comic about standards . Source: XKCD, a webcomic of romance, sarcasm, math, and language. The original CVE white paper insisted on the need for a consistent naming scheme for vulnerabilities and offered this example of how a bug's identity can become hard to track: "For example, one vulnerability discovered in 1991 allowed unauthorized access to NFS file systems via guessable file handles," the white paper said. "In the ISS X-Force Database, this vulnerability is labeled nfs-guess; in CyberCop Scanner 2.4, it is called NFS file handle guessing check; and the same vulnerability is identified (along with other vulnerabilities) in CERT Advisory CA-91.21, which is titled SunOS NFS Jumbo and fsirand Patches." It's left up to individuals to read descriptions of the vulnerabilities to look for commonalities to track these bugs, which can quickly become onerous and error-prone, the paper argued. It's easy to miss, but this explainer has a fair dose of irony, as they don't themselves cross-reference it to ISS X-Force 77 specifically, nor point out that ISS links to CERT and Sun, which provides that cross-reference they say is so desperately needed. This example serves a second purpose, when you consider that, eventually, CVE-1999-0167 would be published and it links only to ISS and not CERT or Sun, the foundation of their example. When launched in September 1999, CVE had 321 records, a fraction of the more than 3,700 vulnerabilities known at the time. Even back then, 26 years ago, it would seem the stage was already set for how poorly MITRE would fare in the world of running a VDB. MITRE's Flawed Federal CVE Program Funding Model MITRE receives funding for projects as a federally funded research and development center (FFRDC). FFRDCs like MITRE adhere to regulations set forth by the US government that dictate how contracts are awarded. One advantage they have is that they often get contracts that are no bid and non-compete, a relative rarity for government contracts. They do this by pitching a contract to the government that is supposed to meet certain criteria, and, if accepted, they get jobs without other businesses being able to compete for it. That is what has allowed MITRE to enjoy the CVE contract for so long, despite objectively sub-par performance . Code of Federal Regulations Title 48, Federal Acquisition Regulations System, is one of the sets of rules that MITRE is subject to for such contracts, specifically section 35, "Research and Development Contracting." Soliciting contracts ( 35.007 ), the evaluation for award ( 35.008 ), and, specifically, the section on FFRDCs ( 35.017 ) have enough language to argue that the CVE contract should never have been awarded. Criteria for MITRE's funding including having "novel ideas," the "highest competence in a specific field," a "special competency," and perform work which cannot be met by an "existing in-house or contractor resources." While I am not a lawyer or government regulation author, I would argue that a layperson's interpretation of these points strongly suggests that CVE was not a novel idea, the creators were no more experts than anyone else at the time, and that the need for such an effort could have been obtained for free or contracted through ISS at the time. Another provision of Title 48, covered under section 35.017-4 , requires that the contract sponsor, in this case the Cybersecurity and Infrastructure Security Agency (CISA), conduct a review prior to extending the contract. Per 35.017-4(c), part of the review should include the "consideration of alternative resources," an "assessment of the efficiency and effectiveness for … meeting the sponsor's needs," including that the FFRDC "maintain its objectivity … quick response capability, currency in its field of expertise." Critically, CISA is required to assess whether the FFRDC is running a "cost-effective operation." Further, according to the government-run Defense Acquisition University , an "FFRDC's performance of its tasks requires that a special relationship exist between the FFRDC and its sponsor." That list largely mirrors the above but includes one more: "Adaptability — ability to respond to emerging needs of their sponsors and anticipate future critical issues." It reads like a list of how MITRE has precisely failed at running the CVE program and why they are coming up short, failing the world over when it comes to vulnerability intelligence. There have been many cases historically of MITRE not being perceived as objective, and the pattern continues to this day . MITRE does not have a quick response capability. Researchers wait days, weeks, months, even years to receive a CVE ID assignment. It would take an entirely separate series of articles to cover why MITRE and the CVE team leaders arguably do not have expertise in the field of vulnerability database management, based on my experience managing a VDB in one form or another since 1993. Despite the topic being discussed on the CVE Board as far back as 2017 , it wasn't until 2024 that MITRE finally adopted a policy regarding assignments for cloud/software-as-a-service (SaaS) vulnerabilities. That certainly does not meet the criteria for "adaptability" and anticipating "future critical issues." Finally, cost-effective operation is a consideration and one that MITRE has failed since early in the program. Between 2004 and 2005, MITRE received almost $5 million to run the CVE program, a baffling figure at the time. A community-driven database, OSVDB , was able to catalog far more vulnerabilities and do it for a tiny fraction of the cost. Jump to 2024/2025, and that funding exploded to a staggering $29 million . Jerry Gamblin did some math to determine that "MITRE received $664.01 for each of the 43,625 CVEs published during the contract period." As someone who has worked on a commercial VDB since 2011, I can assure you that a superior database can be run for a tiny fraction of that cost. Based on MITRE's performance and CVE funding, I believe the Government Accountability Office (GAO) must ask two questions. First, is MITRE meeting the requirements of being an FFRDC running a vulnerability database? And second, is an FFRDC even required in 2026 when there are higher performing commercial/contracted alternatives? The GAO is the agency tasked with investigating "fraud, waste, abuse and mismanagement," after all. Read more about: Opinion About the Author Brian Martin Brian ((jericho)) Martin is a vulnerability historian, VDB integrity evangelist, aspiring anthropologist, interlocutor, and champion of small misunderstood woodland creatures. See more from Brian Martin