CVE: How Two Engineers Got Tired of the Chaos and Gave Vulnerabilities a Common Name

As it happens, I've spent the past three years working in cybersecurity, mostly with vulnerability data and information about open-source packages. Along the way, I've become fascinated not just by the field as it is today, but by its history — how it all began and how we got here.

I originally published this article in Russian on Habr. I'm not sure how interesting it will be to English-speaking readers — after all, the sources I used were in English to begin with. Still, I wanted to share the story here as well. I hope you enjoy the read.

One vulnerability, a dozen names, 321 entries, and a conference booth where competitors agreed to work together. The origins of cybersecurity's best-known identifier, told through primary sources from 1999.

Hi! I'm Iuliia Volkova, and for almost three years I've been responsible for data at CodeScoring — more specifically, I lead our Data Collection and Analytics team.

My team prepares the data that powers our product: information about vulnerabilities, licenses, open-source packages, and everything connected to them. We collect it from many different sources, each with its own quirks. They vary in completeness, quality, structure, and depth. Sometimes they complement one another. Sometimes they disagree on the details. And sometimes they contradict each other outright.

I may write about that side of our work another time. But I'd like to start this series not with today's data challenges, but with the history of the infrastructure we now rely on to work with vulnerabilities. What is the CVE Program? Where did NVD come from, and why was it needed? Why did the GitHub Advisory Database and the OSV format emerge? What role does FIRST.org play? How do these initiatives fit together, and what comes next?

Throughout this series, I'll look not only at how these projects work, but also at why they appeared, which problems they were meant to solve, how they evolved, and where their responsibilities begin and end.

Many of the standards and formats we now take for granted did not emerge from a grand master plan. They were responses to specific problems: technical, organizational, and even political. So it makes sense to begin with one of the cornerstones of the vulnerability ecosystem: the CVE Program.

Let's start with the chaos it grew out of.

One Vulnerability, Three Names

Picture the late 1990s. You're responsible for security at a large organization. You have three vulnerability scanners from three different vendors, an intrusion detection system (IDS) from a fourth, and a folder full of printed CERT (Computer Emergency Response Team) advisories. Scanner №1 reports a problem under one name, scanner №2 uses another, and the CERT advisory describes the same hole under a third. Your job is to work out whether these are different problems or different descriptions of the same one.

This is not a hypothetical scenario. A September 1999 paper on the development of CVE gives an example that could make any security practitioner's eye twitch. The same NFS vulnerability appeared as:

• "NFS file guessing check" in the CyberCop scanner database;
• "nfs-guess" in the X-Force database from ISS;
• "SunOS NFS Jumbo and fsirand patches" in a CERT advisory.

Although all three names contain "NFS," that is not enough to establish that the records describe the same problem at the same level of abstraction. Worse, the sources divided up the same set of NFS issues differently. CERT covered them in six advisories. CyberCop reported them through 13 separate security checks. X-Force split the information into 20 vulnerability entries.

Good luck figuring out that all of this was describing the same set of problems.

Meanwhile, the PHF CGI vulnerability — a classic web server flaw of the era — was known by roughly a dozen different names across a dozen vendors. Everyone maintained their own database and named vulnerabilities however they liked. One source named it after the phf program, another after the escape_shell_cmd function, and another after an internal check number.

The math was brutal. To map N independent databases directly to one another, you would need a separate set of mappings for every pair: up to N(N−1)/2 integrations, or O(N²). And within each integration, someone still had to manually connect records that might describe the same vulnerability under different names.

The authors of CVE described this work as labor-intensive and error-prone. It was a Tower of Babel: everyone was talking about the same things, but in different languages. And that was where everyone had to work.

CVE changed the architecture of the problem. Instead of mapping every source to every other source, each could be mapped to a single shared list.

MITRE's Own Pain Point

Interestingly, CVE did not begin as a grand project to standardize an entire industry. Its origins were much more modest — and practical.

MITRE, a nonprofit organization, had an internal Information Security Committee. The committee used scanners and IDS products from multiple vendors and was building a centralized approach to protecting MITRE's own corporate network. It had some very concrete requirements:

• Determine whether different tools were reporting the same vulnerability.
• Connect an IDS alert to the most recent scan results for the same host.
• Gather everything known about a discovered issue.
• Compare coverage across tools and against CERT advisories.

Every product had its own database and its own name for the same problem. Correlation became a manual exercise in detective work.

On January 8, 1999, while looking for a way out of this recurring headache, two MITRE engineers — David E. Mann and Steven M. Christey, also known as Coley — published "Towards a Common Enumeration of Vulnerabilities." The paper laid out their proposed approach.

The authors also explicitly acknowledged their colleague William H. Hill, who, they said, had provided much of the conceptual inspiration. Notice the original name, too: Common Vulnerability Enumeration. The first paper was about precisely that — a common list of vulnerabilities.

By the time of the public launch, the name had expanded to the familiar Common Vulnerabilities and Exposures, but the acronym CVE stayed the same.

An Enumeration, Not a Taxonomy

The key design decision behind CVE was not which fields to include in a new database. It was which fields to deliberately leave out.

Mann and Christey could have tried to build a universal classification system for vulnerabilities: categories, relationships, levels of abstraction, and a precise model of affected products. The industry had already seen attempts of this kind. The authors explicitly discussed work on universal primitives and formal taxonomies, including Taimur Aslam's taxonomy of Unix flaws.

But they deliberately chose not to go down that road. Even a seemingly simple question — how to describe an operating system, for example — could quickly generate another round of disagreement within the security community.

Instead, Mann and Christey proposed a minimal model: a unique name and a text description sufficient to distinguish one entry from another. A one-dimensional list. An enumeration. No ontology, no supposedly correct set of categories. Just an agreement that this problem over here and that problem over there were the same problem. Other databases could keep their own classifications, assessments, and perspectives, with CVE serving as a logical bridge.

They supported their reasoning with two analogies. The first came from chemistry. Before Mendeleev, scientists had spent almost a century simply listing the elements: more than 80 years separated Lavoisier's work from the periodic table of 1869. A simple, agreed-upon list helped science speak a common language.

The second came from zoology. The California golden bear, brown bear, Kodiak bear, and grizzly had once been considered separate species; they came to be classified as a single species, Ursus arctos.

Nomenclature is an iterative process. It begins not with a perfect classification system, but with agreement on what counts as the same thing.

This was a political decision as much as a methodological one. To use CVE, companies did not have to accept someone else's vulnerability assessment, risk model, or bug classification. They only had to agree on one point: these two records describe the same problem.

Even the naming format was deliberately boring. As the paper on CVE's development put it:

The decision regarding naming was to keep the name a simple number with a "CVE" prefix.

The authors went on to argue that a more elaborate naming convention would make CVE neither more useful nor more effective.

A more complicated scheme would only invite arguments about things irrelevant to a simple list. This minimalism helps explain CVE's early success. An identifier can sit on top of any model. The identifier itself does not assess risk, propose a fix, or classify the issue. It simply says: "CVE-1999–0067 is that particular vulnerability." Here, 1999 is the year component and 0067 is the sequence-number component. And yes, that is the PHF vulnerability from the opening section. You can look up its CVE Record.

Openness

The second foundational decision was openness. Commercial vulnerability databases already existed, but they were restricted by copyright, incomplete, or shaped by the interests of a particular product. If a shared identifier belonged to one vendor, it would never become a neutral bridge between competitors.

MITRE set out a clear model: CVE had to be public and freely distributable, with an open archive of discussions and votes. This accomplished several things at once:

• It removed barriers to access.
• It avoided competing with commercial databases on analytical depth: CVE was not the analysis, but the key to finding it.
• It created a sense of community ownership.
• It positioned MITRE as a moderator rather than the ultimate authority on vulnerabilities.

That last point matters. MITRE was not claiming to be an oracle. It was offering infrastructure and ground rules, while leaving decisions to the community.

Nine Months from Paper to Launch

On January 21–22, the idea was presented at the 2nd Workshop on Research with Security Vulnerability Databases at Purdue University. The work had been done for an internal security committee, but this paper became the conceptual foundation of the CVE Program.

Purdue was no random choice of venue. By 1999, it was already a major U.S. academic center for information security research. In the early 1990s, Eugene "Gene" Spafford and Samuel Wagstaff had established the COAST laboratory there, working on Unix system auditing, intrusion detection, vulnerability analysis, and digital forensics.

By January 1, 1999, COAST had become part of the interdisciplinary CERIAS center, which organized the workshop where CVE was introduced.

Spafford posted the workshop invitation to Bugtraq on January 4, 1999. The organizers wanted to bring together researchers from academia, government, and industry. This was very much a working meeting: places were limited, and participants were expected to contribute actively to discussions and working groups.

About 100 people from roughly 50 organizations attended. They included representatives from NIST — the National Institute of Standards and Technology, which would later launch and maintain NVD — as well as the NSA, IBM, Cisco, Secure Computing, and universities. NIST and the NSA would also become direct funders of the CVE Program.

The program committee selected eight papers for inclusion in the published workshop proceedings. Mann and Christey's presentation was the sixth and, according to the workshop report, attracted considerable interest. The next day, participants split into five working groups to discuss open, centralized, and federated models for vulnerability databases. Out of this environment came a working group that would become the first CVE Editorial Board and take on responsibility for governing the program.

MITRE then began assembling a draft list of vulnerabilities. Data came from ISS, L-3 Security, SANS, and Netect, and was also collected from Bugtraq, NTBugtraq, CERT advisories, and the databases used by the CyberCop, NetSonar, and NetRecon scanners. This mattered for more than simply filling the list: every additional source exposed differences in how records were named and where their boundaries were drawn.

On May 9, 1999, the CVE Task Force — the future Editorial Board — held its first meeting at SANS-99 in Baltimore. The surviving notes describe thoroughly practical goals: secure support from key industry players, validate the draft list, and agree on a release.

Between May and September 1999, MITRE compiled the draft while the Board debated levels of abstraction — how many separate bugs should count as "one vulnerability" — as well as inclusion rules and the terms vulnerability and exposure. Members also voted on candidate entries. Most of the Editorial Board's work happened on a mailing list. Christey acted as moderator and the central point of coordination. The correspondence has been preserved, so it is still possible to see not just the outcome, but the discussions and decisions that led to it.

Initially, representatives from 12 commercial and research organizations were involved.

On September 29, 1999, CVE launched publicly, accompanied by a press teleconference. The list contained 321 entries. Alongside it was an Editorial Board representing 19 organizations.

A note on the numbers: modern accounts often refer to 19 members of the original Board, while the September 1999 paper mentions 23 individuals.

Nineteen Organizations, One Booth, and a Future Who's Who of Security

MITRE's bet on openness paid off. The organizations involved in the launch included many direct competitors: scanner vendors, IDS vendors, and vulnerability database providers — companies whose business depended on their product being better than the next one.

They included the CERT Coordination Center, IBM Research, Cisco, Internet Security Systems (ISS), AXENT, BindView, Bugtraq, CERIAS/Purdue, Network Associates, NFR, NTBugtraq, the SANS Institute, SecurityFocus.com, Silicon Defense, UC Davis, and others. And the Ballistic Missile Defense Organization. Yes, the missile defense organization.

The participants also included well-known security experts: Gene Spafford, Matt Bishop, Adam Shostack, Elias Levy, and others.

A CVE booth at the SANS Network Security conference became a symbol of mutually beneficial cooperation. It embodied the project's idea: representatives of competing companies deliberately staffed the booth together.

And Mann and Christey were not the only people working behind the scenes to make this coalition possible.

Margie Zuk was the project manager and a driving force behind industry adoption; she would later lead CVE. Pete Tasker, who headed MITRE's Security and Information Operations work, was the initiative's internal sponsor and advocate. Christey, meanwhile, combined three roles: format designer, list editor, and Editorial Board moderator. In other words, architectural, editorial, and procedural authority sat with one person.

In 2000, Zuk, Christey, Mann, and Tasker received the SANS Security Technology Leadership Award. The industry recognized the significance of what had happened almost immediately.

From a List to Planet-Scale Infrastructure

CVE's public launch was only the beginning. Over the next quarter-century, a simple list of identifiers became the foundation of an entire vulnerability data ecosystem.

In September 2002, NIST published Special Publication 800–51, recommending that U.S. federal agencies use CVE in vulnerability-related activities. From that point on, CVE was not just a voluntary industry agreement: it was also part of official federal guidance.

On August 10, 2005, NIST launched the National Vulnerability Database, or NVD. Built on top of CVE, the new database contained almost 12,000 entries at launch and supported searches by vulnerability type, severity, impact, vendor, product, and version. Over time, NVD became a separate data-enrichment layer: NIST links published CVE Records to CVSS scores, CWE weakness types, CPE-based applicability configurations, and other metadata.

By 2013, the program had run into an unexpectedly mundane limitation: the original identifier format would eventually run out of room. The CVE-YYYY-NNNN scheme allowed no more than 9,999 identifiers for a single year. As the flow of reports grew, the CVE Board had to choose a new format.

The list that had started with 321 entries in 1999 contained 54,392 vulnerabilities by the end of 2012. In 2012 alone, 5,351 entries had been added.

The new scheme, allowing a variable-length sequence-number component after the year, took effect on January 1, 2014. On January 13, 2015, the first identifiers beyond the four-digit limit were published: the five-digit CVE-2014-10001 and the six-digit CVE-2014-100001.

The change looked cosmetic, but it affected the entire ecosystem: databases, regular expressions, parsers, report formats, and interfaces that had spent years assuming a CVE ID would always have a fixed length.

CVE was officially preparing to handle tens of thousands of vulnerabilities a year.

In 2016, when the program had just 23 CVE Numbering Authorities (CNAs), it adopted a strategy for scaling its federated model. More vendors, research teams, CERTs, open-source projects, and other organizations began assigning CVE IDs and publishing CVE Records within their agreed scopes. The CNA mechanism itself was not invented in 2016: Candidate Naming Authorities had already been described in the 1999 documents.

What was new was the scale of distributed publication.

Now let's talk about the money.

For all its openness, CVE has never been infrastructure sustained solely by community enthusiasm. The U.S. government funded the program's core from the beginning. As mentioned earlier, the NSA and NIST were the first funding sources, with other federal agencies joining later. From 2001 to 2005, a separate CVE Senior Advisory Council was tasked with providing not only strategic direction, but also long-term funding.

By 2004, the U.S. Department of Homeland Security — DHS — had become the main sponsor. In the current model, funding comes through CISA, an agency within DHS. MITRE remains the program's operator, carrying out the work under a federal contract through HSSEDI, a MITRE-operated federally funded research and development center (FFRDC).

This arrangement gave CVE the resources for continuous editorial, organizational, and technical work. It also made a piece of global infrastructure dependent on a single government customer.

On April 15, 2025, information from a MITRE letter to the CVE Board became public: the contract supporting MITRE's work on the program was due to expire the following day, and its continuation had not yet been confirmed. On April 16, however, CISA announced that it had activated an option period under the contract on April 15, so CVE operations had not been interrupted.

The agency later clarified that this had not been a lack-of-funding issue, but a contract administration problem resolved before the contract expired.

Still, the episode was enough for a group of CVE Board members to announce the creation of the CVE Foundation that same day. According to the Foundation, preparations had been underway for about a year. Its stated goals were long-term sustainability and reduced dependence on a single government sponsor and a single contractual mechanism. The announcement did not mean that control of CVE was immediately being transferred to the Foundation. It was a proposal for a different future model.

As of September 5, 2026, the CVE List contained 380,563 published vulnerabilities. The infrastructure surrounding the program is now difficult to compare with that first list of 321 entries. At the time of writing, 537 organizations were participating as CNAs or CNAs of Last Resort, spanning 43 countries, with one organization having no specified country affiliation.

Success Was No Accident

Without the details, it might be tempting to imagine that in the good old 1990s, as the industry was taking off, any reasonably proactive engineer could make history simply by proposing a good solution to an urgent problem.

But that is not quite the whole story. Let's remember what MITRE was.

CVE's success cannot be explained by Mann and Christey's idea alone. Where that idea emerged mattered just as much.

MITRE grew out of work on SAGE, one of the largest information systems of the Cold War. The organization was not created to manufacture a particular radar or computer. It was created for systems engineering: bringing government bodies, research organizations, industrial contractors, and many technical components together into a functioning whole.

By the late 1990s, this way of working was already part of MITRE's organizational culture. It knew how to tackle problems where no participant controlled the entire system, but everyone needed shared rules for interacting with it.

MITRE also occupied the right institutional position. It worked in the public interest and operated federally funded research centers, but it did not sell its own commercial scanner or proprietary vulnerability database. To competing vendors, it was a much more acceptable coordinator than another market participant would have been.

MITRE had a real operational problem on which to test the idea. It had access to government, industry, and academia. And it had the resources to maintain not only the list, but the entire process around it: meetings, mailing lists, votes, a website, and ongoing editorial work.

None of this guaranteed success. But it created conditions without which Mann and Christey's work might have remained a promising conference paper from 1999 — and nothing more.

The CVE ID, the Early CVE Entry, and the Modern CVE Record

Before wrapping up CVE's story, it is worth qualifying an earlier statement: "CVE does not assess or classify anything."

That is true of the original philosophy and of the identifier itself. A CVE ID does not encode severity, weakness type, vendor, or remediation. In the 1999 design, the core entry consisted of a unique name and a short description. Additional information — dates, categories, references, a thesaurus, and keywords — was kept in a separate CVE Maintenance Extension, or CMEX. The CMEX categories were explicitly not intended to be a formal taxonomy.

But time passed, industry needs became clearer, and program participants and the Editorial Board made changes to the original idea. Today's CVE Record, which evolved from the original CVE Entry, provides a much richer description of a vulnerability in a strictly defined format. It can include severity information, affected products, attack vectors, and much more.

Is CVE Still the Main Bridge Between Vulnerability Records?

The main one, yes. The only one, no.

CVE did not put an end to vulnerabilities having multiple names. Python developers may have encountered PYSEC- identifiers; Rust developers, RUSTSEC- identifiers; and other ecosystems have their own variations. Anyone working with open-source packages will probably be familiar with GHSA identifiers from the GitHub Advisory Database. Russia also has FSTEC's BDU vulnerability database, which contains not only descriptions of known vulnerabilities found in other sources, but also locally specific information.

The list could go on. Most of these vulnerability descriptions point to specific CVEs. Most — but not all.

CVE did not eliminate duplicated information across sources. It did not remove vendors', open-source communities', or regulators' reasons for maintaining their own vulnerability databases. That was never the program's goal.

What CVE helped establish was the need to connect vulnerability records across sources. As a result, even a record with no CVE reference will often include other identifiers for the same known issue, such as a BDU or GHSA ID.

One of the things we do with vulnerability data at CodeScoring is determine which records from different sources describe the same problem and combine them into a single UNCS — Unified CodeScoring Vulnerability — record.

This is possible because of those connecting links: shared identifiers, also known as aliases in vulnerability data. Whether an alias is a CVE, GHSA, BDU, or something else does not matter.

A Final Thought

It is hard to overstate the importance of the CVE Program. Its story began with an operational headache inside a single organization and two engineers willing to propose a solution to an industry-wide problem.

Twenty-six years later, it is hard to imagine a security professional going an entire workday without mentioning at least one CVE ID. Right?

How many CVEs do you mention on a typical day?