CVE Record Minimum Data Requirements

[ccoffin]

What should the minimum data requirements be to publish a CVE Record?

Current requirements:
The current requirements are that the Record have a non-empty description, at least one affected product and version, and at least one public reference.

Things to keep in mind:

• Many in the community believe that a CVE Record should be published as soon as possible, so the requirements shouldn't be too restrictive
• Records can be enriched and updated later when needed
• What is most important to a defender/consumer when determining if a vulnerability applies to them?
• See METABUG: Potential concrete data quality improvements for 5.2.0 #384 for some previous thinking on this subject

[jgamblin]

Thank you for starting this crucial discussion on the minimum requirements for publishing a CVE Record.

To address the core question posed—"What is most important to a defender/consumer when determining if a vulnerability applies to them?"—I believe the answer points towards needing more structured, actionable data from the very beginning, rather than less. While the current minimums of a description, affected product/version, and a reference are a start, they often lack the necessary detail for the automated tooling and rapid risk assessment that defenders rely on.

This is where requiring fields like Common Platform Enumeration (CPE) and Common Weakness Enumeration (CWE) becomes critical for a record's initial utility.

CPE is essential for automation. For any organization managing more than a handful of assets, manually parsing product names from a description field is inefficient and error-prone. A valid CPE allows vulnerability management systems to automatically and accurately correlate a new CVE with a defender's asset inventory. Without it, a newly published CVE is just noise until a human can perform manual analysis.

CWE provides immediate context. Understanding the type of weakness is fundamental to a defender's triage and prioritization process. Knowing if a vulnerability is a SQL Injection (CWE-89) versus a Cross-Site Scripting (CWE-79) immediately informs the potential impact and the teams that need to be involved.

Regarding the point that "Many in the community believe that a CVE Record should be published as soon as possible, so the requirements shouldn't be too restrictive," I would be very interested in understanding this perspective in more detail. Could you please help clarify who these community members are? Is there any written rationale or public discussion we could review that elaborates on the benefits of speed at the expense of initial data quality?

While I agree that speed is important and that records can be enriched later, I would argue that publishing a record without a valid CPE or a CWE is counterproductive to the goal of timely defense. An incomplete record can create more work for consumers and may not be immediately actionable, delaying the very response it's intended to trigger.

Therefore, I propose that we strengthen the minimum requirements to include a valid CPE and an assigned CWE for initial publication. This would significantly enhance the immediate value of a CVE Record for the defenders and consumers who depend on it for their security operations.

[darakian]

While I agree that speed is important and that records can be enriched later, I would argue that publishing a record without a valid CPE or a CWE is counterproductive to the goal of timely defense. An incomplete record can create more work for consumers and may not be immediately actionable, delaying the very response it's intended to trigger.

The inverse is also true though and I think that's where the value judgements come in. What data is and is not necessary given tight time constraints is quite contextual and hence this conversation. What is an absolute minimum?

CPE is essential for automation.

I would abstract that to say that product identifiers are essential for automation. CPEs have known shortcomings for some product domains and forcing the use of CPEs in a domain where they do not make sense only creates more work for humans.

[darakian]

I think this conversation is dependent on #425
It's hard to say what a minimum viable advisory must contain until we have an idea of the audience for the advisory.

That said, I think Andrew's list of improvements need not be blocked. They all seem to be basic cleanup.

[ElectricNroff]

I'd like to explore changing the publication requirements so that they are closely aligned with section 4.5.1.6 of the CNA Rules "CNAs SHOULD publish CVE Records within 72 hours of becoming aware that a CVE ID assigned by the CNA has been Publicly Disclosed by a party other than the CNA" where "Publicly Disclosed" is defined at https://www.cve.org/ResourcesSupport/Glossary as 'The state in which non-trivial information about a vulnerability is publicly available. The publication of most vulnerability advisories, software updates, proof-of-concept exploit code, or other detailed information makes the vulnerability “Publicly Disclosed.”'

In other words, the CVE Program would be able to publish a document with two types of data: an ID number, and one piece of "non-trivial information."

Today, we have a number of deadlock situations in which 4.5.1.6 says "SHOULD publish" while (for example) at the same time 5.1.7 does not allow publication because of "MUST identify the type of Vulnerability." They include situations where the product is widely used and directly exposed to the Internet, a security update from the vendor has been publicly announced and distributed, and the impact of exploitation is substantial (e.g., downloading large amounts of private information). The reasons that details (such as for rule 5.1.7) are not yet available vary, but include cases where the vendor's policy is that it will never publish any details, and the discoverer will receive a substantial payment from the vendor if they delay publication for months.

CVE coverage of these cases seems very consistent with the Program mission of "Identify, define, and catalog publicly disclosed cybersecurity vulnerabilities." Also, there is a high risk of exploitation because, in some situations, the vulnerability just isn't very difficult to figure out.

I personally feel it would be great if some persons backed away from their sense of entitlement in which nobody is allowed to see these vulnerabilities on the CVE website unless the available information is suitable for that person's preferred process.