Introduction

Imagine a world where software safety is treated with the same care as airline safety. Where software defects are tracked with the precision of aircraft maintenance logs. Where defenders are given actionable insights within seconds when a manufacturer reports a flaw. Where they can instantly answer the questions that matter most:

Which of our systems are affected by this vulnerability and how severely?

How fast do we need to act, and what should we do first?

Is there already a patch, mitigation, or configuration change available?

That world is within reach — but only if we raise the quality of CVE records (Common Vulnerabilities and Exposures).

For nearly a decade, the CVE Program has been in an expansion phase. Almost 500 CNAs (CVE Numbering Authorities) are now authorized to issue records. That growth was essential. It built the foundation for what comes next.

Now, we enter the quality phase.

The truth is simple: we cannot achieve global software safety with inconsistent, incomplete, or inaccurate records. Yet that's where we are today. Too much energy is spent fixing CVE records after publication — repairing data that should have been correct from the start. We keep looking downstream for solutions to problems that begin upstream.

It's time to change that.

High-quality CVE records are no longer optional; they are the backbone of vulnerability management, threat intelligence, and automated defense. They make it possible for every organization — large or small — to know what's vulnerable, what's urgent, and what's safe to ignore.

High-quality CVE records are not a luxury — they are a user right. Every software manufacturer has a duty to the people who trust their products. When a manufacturer learns of a security defect and recognizes that its customers may be in danger, it must notify them — clearly, accurately, and without delay. That is the essence of the social contract between makers and users of software.

This manifesto calls for a shift in mindset and practice.

It argues that CNAs must take responsibility for the quality of their records, and that the CVE Program must equip them with tools, standards, and automation that make accuracy and completeness the natural outcome.

If we succeed, CVE will no longer be a registry of defects.

It will be a living infrastructure for global software safety — built not by repair, but secure by design.

Why It Matters

CVE record quality is not an abstract concern — it is the difference between defense and disaster. When records are incomplete, inaccurate, or delayed, the entire ecosystem suffers.

High-quality CVE records unlock the full potential of vulnerability data. Even if all they did was uniquely identify defects, they would still be valuable. But when the metadata is structured, complete, accurate, and timely, it turns information into action. It allows defenders to combine vulnerability data with knowledge of their networks, asset value, and risk posture to make intelligent decisions about which systems need attention now — and which can safely wait.

When that quality is missing, automation breaks down. Tools that ingest CVE data have to guess at what CNAs meant, not what they wrote. Each system interprets records differently, introducing inconsistency, wasted effort, and exposure.

The results are predictable and dangerous:

Missed vulnerabilities lead to breaches. When key details are missing, defenders can't tell whether they're affected. Deployments of updates are delayed, attackers exploit the gap, and organizations learn too late that the situation was avoidable.

Low-quality data wastes precious time. In any operation, every patch window carries risk. When CVE records are wrong or unclear, operators may patch systems unnecessarily — taking vital services offline and disrupting networks.

Confusion spreads through the supply chain. During active exploitation events, poor CVE quality amplifies chaos. Incomplete version ranges and mismatched product names make it impossible to know who is truly exposed. As a single flawed record ripples through hundreds of products, uncertainty replaces clarity at the very moment precision matters most.

High-quality CVE records cut through that chaos. They make automation reliable. They let defenders act with confidence and manufacturers maintain trust.

Foundational Philosophies

The quality era of CVE begins with new principles, not just new processes. If we want high-quality records, we must design a system that makes quality the natural outcome, not an afterthought. These foundational philosophies describe how that shift happens — from accountability to architecture. They are the mindset changes that turn CVE from a registry of defects into an infrastructure of trust.

1. CNA accountability: CNAs should be responsible and accountable for the quality of their records. Quality cannot be bolted on; it must be baked in. The tools that the CVE Program provides CNAs (web interfaces, APIs, technical tools, training) should be constructed with the goal of making it easy for CNA agents to do the right thing, reducing their costs while improving record quality for downstream consumers. Nevertheless, it is not the responsibility of the CVE Program to issue high-quality records. The buck stops with the CNAs. CNAs should actively measure and improve the quality of their CVE records over time.
2. Software companies should be CNAs. A part of taking ownership for customer security outcomes is providing authoritative information about defects in their products. That includes working with upstream open source projects to ensure effective coordination of remediation and communication of downstream risk.
3. Opinionated system design: The CVE system should clearly define what "good" looks like and prevent the creation of low-quality records. It should reject records that downstream consumers would struggle to interpret or use effectively. Instead of relying on others to correct problems after publication, the focus should be on ensuring high-quality records at the point of creation.
4. Automation-first approach: Schema design and field requirements should prioritize automation, consistency, and machine readability. While freeform text fields have limited use, the true value of CVE records at scale comes from placing information in strongly typed fields. This approach not only eliminates ambiguity and makes it effortless for software to process CVE records without custom logic, but also enables clear, automated presentation of records in any language — allowing translation and localization systems to operate with precision and consistency.

Desired Outcomes

Philosophy alone is not enough. Change requires visible results. These desired outcomes define what success looks like when the CVE Program fully embraces quality by design. Each outcome is achievable and necessary for a world where software safety is the norm, not the exception.

1. High-quality at issuance: All CVE records are high-quality at the time of publication. No exceptions.
2. Effortless automation: Downstream consumers can automate ingestion and interpretation without manual parsing or inference.
3. Enforced quality standards: Clear expectations for record quality are defined, measurable, and enforced through the system itself.
4. CNA enablement: CNA agents receive active assistance through both API and web interfaces that make it easy to produce accurate records.

What is CVE Record Quality?

There is no widely accepted definition of CVE record quality, so I'll offer one here. A CVE record is high-quality when it is complete, accurate, and timely, a simple model that forms the acronym CAT. 🐱

Completeness

Completeness means that the CVE record includes all the information necessary for downstream consumers to understand and act on the vulnerability.

In practical terms, completeness means:

• All required fields are populated (e.g., product publisher, product name, affected versions, CWE (Common Weakness Enumeration), and references).
• The record includes enough detail for a downstream system or analyst to determine whether a specific product instance is affected.
• Optional fields that improve clarity, such as configurations, platforms, or component names, are filled out when the CNA has that information.
• Ideally, the record provides contextual sufficiency: someone reading the record can understand the nature and impact of the vulnerability without needing to consult the vendor advisory.

Completeness is about scope and sufficiency, not syntax. A record can be syntactically correct but still incomplete if it omits key facts necessary for defenders or automation systems to act.

That brings us to the next attribute: accuracy.

Accuracy (and Automatability)

Accuracy means that information is both syntactically valid and semantically correct.

First, the CNA uses the correct data type or format. Examples include:

• The CWE field contains a CWE identifier ("CWE-89"), not a text narrative or description.
• CWEs selected are from the "Allowed" category in the CWE Vulnerability Mapping list and not "Discouraged" or "Prohibited" identifiers such as CWE-16.
• Version ranges align with a valid versioning scheme, such as semver (major.minor.patch), rather than vague text phrases like "all versions" or "version 1.2.3 and below".

Rather than allowing CNAs to embed key details in the Description field as free-form text, CNAs should populate the appropriate fields in the schema. Every piece of information should go into its defined place.

Second, the values accurately describe the intended information. In other words, the information is correct. If the vulnerability requires physical access, then the CVE record should say that rather than to incorrectly claim that it can be exploited over the network.

One measure of accuracy is whether multiple people or tools can independently converge on the same result when interpreting or populating a CVE record. We would not expect convergence in freeform text fields, since narrative descriptions naturally vary in style and emphasis. However, we should expect multiple people with similar skill sets to converge on structured fields such as the affected product range, given the same underlying facts. They should fill in those fields consistently. Likewise, fields such as CWE identifiers should exhibit convergence — or at least near-convergence — across qualified analysts. Achieving this level of alignment requires taxonomies and schemas that are precise enough to guide consistent interpretation, yet not so granular that they create unnecessary disagreement. Convergence, in this sense, serves as a practical test of clarity, consistency, and interoperability across the ecosystem.

[Fun fact: The CWE taxonomy provides 19 ways to encode a "directory traversal" coding error. It is likely that multiple people trying to select one of these CWEs to describe the same vulnerability would not converge on the same identifier.]

The goal is not hygiene for its own sake. A consistent schema allows CNAs to produce records that downstream systems can consume automatically.

A good test of completeness and accuracy is whether the record is automatable. If an ingest tool requires custom logic to interpret what the CNA meant, the record fails the automation test. When CNAs misuse fields or omit data, they create avoidable friction for downstream consumers.

It is a common mistake to assume that CVE records are automatable simply because they are published in JSON. In practice, experience has shown that the absence of strongly typed fields shifts significant work onto consumers, who must compensate for ambiguity and inconsistency in the data. The real test of automatability is therefore not whether CVE records exist in a machine-readable format, but how easily and reliably consumers can actually use them.

Timeliness

Defenders need vulnerability information quickly. A CVE record that is missing data, formatted incorrectly, or published late prevents defenders from prioritizing effectively. Given how fast attackers exploit new flaws, delays carry real consequences.

Today, many CNAs issue incomplete records. Rather than holding CNAs to higher standards, the U.S. government funds staff and contractors to repair CVE records after publication. This process is error-prone because those performing the repairs are not the original subject-matter experts. It also introduces delays that reduce the record's usefulness, sometimes by days or weeks, and occasionally indefinitely.

Utility

CVE record quality and utility are closely related but distinct concepts.

• Quality asks: Is the record complete, accurate, and timely (CAT)? Quality is inward-facing and is about craftsmanship.
• Utility asks: Does this record help someone do their job? Utility is outward-facing and is about usefulness to others.

For example, even a minimal record that includes only the publisher, software name, and affected version can still have real utility for a defender, because it signals that something is wrong with a specific package, even if the nature of the problem is not yet clear. Timely awareness alone can be valuable. Nevertheless, the goal is not to settle for minimalism, but to systematically improve the quality of records across the dimensions of completeness, accuracy, and timeliness, since higher-quality records will, in aggregate, produce greater utility for most consumers in most situations.

Enrichment

The term "enrichment" is often (mis)used to describe work that brings incomplete CVE records up to a usable state. In reality, that is not enrichment. It is simply restoring basic quality.

True enrichment adds information that the CNA could not reasonably know, such as evidence of active exploitation or a technical report on the flaw in question. A CNA is expected to know the affected product name but not necessarily have access to threat-intelligence data.

Using the term enrichment to describe repair work misplaces accountability. It obscures the need to move responsibility for CVE record quality upstream, where it belongs.

Call to Action

The quality era will not happen on its own. It begins when we decide that every CVE record deserves the same rigor we expect from any safety system.

Each participant in the ecosystem has a role to play:

CNAs must treat every record as a public trust — complete, accurate, and timely (CAT) from the start. That means ensuring their CVE teams are properly staffed, trained, and supported. Senior executives should actively oversee those programs, reviewing metrics and compliance with evolving norms. CNAs should also establish formal programs to learn how their downstream users — defenders, tool vendors, and data scientists — consume their records. That feedback should drive improvements at the point of creation, not correction. Quality cannot depend on individual heroics; it requires institutional commitment, steady investment, and visible leadership.

Software manufacturers must treat CVE records as safety defect reports, not as public-relations risks. In other safety-critical industries, defect reporting is handled by professionals who are trained, resourced, and backed by executives who understand the gravity of the work. Software should be no different. Vulnerability disclosure must be integrated into mature, well-maintained processes with real executive sponsorship — not just reluctant buy-in. Within their product management functions, CVEs should be explicitly managed just like any other user feature and benefit, including in product requirements documents (PRDs) and product key performance indicators (KPIs). Manufacturers should maintain formal programs to study how customers and partners use their CVE data and look for ways to make it more useful at the time of publication. Treat CVE records not as a compliance chore, but as a core function of responsible software manufacturing. The walls between CVE specialists, Product Security Incident Response Teams (PSIRTs), and software development teams must be replaced with high-speed highways.

The CVE Program must lead with both vision and discipline. It should set measurable quality standards, enforce them through automation, and make performance visible to the community. It must provide modern tooling and guidance so that quality is the default outcome, not the exception, while reducing the burden on CNAs. The program should also establish feedback mechanisms that allow downstream consumers to report when they disagree with how a record's fields were populated or when they find quality issues. CNAs and software manufacturers need that input to improve their processes and the safety of their software. The CVE Program should make those signals timely, constructive, and transparent — closing the loop between record creators and record users.

Tool vendors and data consumers must be active participants in that feedback loop. When they detect malformed or inconsistent records, they should report them constructively and share insights that improve schema design and validation rules. Automation works best when everyone contributes to its refinement.

Defenders and researchers must demand better data and hold the ecosystem accountable. They should use high-quality records as the benchmark, reject incomplete or misleading ones, and praise CNAs that get it right. In doing so, they help shift incentives across the entire ecosystem.

Together, these actions can help guide the CVE Program from an era of expansion into an era of quality. This is how we give practical meaning to the idea of "quality by design".

The quality era starts now. Let's build it together.