Rules Change Request: CNA container must independently satisfy required content, with no ADP backstop
Section affected: 5.1 (Required CVE Record Content) generally; also 4.5.1.1
Current text:
4.5.1.1 CNAs MUST provide CVE Record content that meets the requirements listed in section 5.
5.1.4 MUST identify at least one Product as "affected" or "unknown" (with the possibility of being affected).
5.1.8 MUST NOT only contain Products with "unaffected" status. This would not be a Vulnerability.
Problem: The rules describe requirements as applying to "a CVE Record" without specifying whether the CNA's own container must independently satisfy them, or whether the record as a whole, CNA container plus any ADP-supplied enrichment, is what gets evaluated. In practice this ambiguity lets ADP enrichment substitute for CNA-supplied content. CVE-2026-24114, cited in GitHub issue #42, is a direct example: MITRE's CNA container left vendor, product, version, and CWE as "n/a," and CISA later added the real CWE and a CVSS score as an ADP. Under a literal reading, the completed record may appear to satisfy Section 5's requirements even though the CNA never did the work the rules assign to it. This creates a standing incentive problem: if ADP enrichment can silently repair a CNA's incomplete work, there's no operational pressure on the CNA to get it right at creation time, and "an ADP will catch it" becomes a durable, unstated exception to Section 5's MUST requirements.
There's a second, related gap worth closing at the same time. Every sub-rule in 5.1 already carries an explicit MUST or SHOULD tag, and Section 1.4 defines those keywords unambiguously, so the mandatory floor for a CVE Record technically exists today. But it exists only as something a reader has to reconstruct by combing through all thirteen sub-rules of 5.1 and sorting them by keyword; there is no single place that states the floor as a checklist. A rule requiring the CNA container to "independently satisfy the requirements of this section" inherits that same diffuseness, and a CNA disputing a compliance finding could reasonably argue about what exactly the phrase covers. Stating the floor explicitly, in one place, removes that argument before it starts.
A third gap sits inside the floor itself. 5.1.4 requires at least one Product marked "affected" or "unknown," and 5.1.8 only forbids a record where every Product is marked "unaffected." Combined, these permit a CVE Record where every listed Product is "unknown" and none is ever definitively asserted as affected, a record that's technically compliant while failing to assert its own subject matter. This hedge isn't actually necessary to accommodate a CNA still investigating downstream exposure: the Product where the coding error itself lives, the one that gave the CNA reason to create the record in the first place, is always known to the CNA at creation time. The "unknown" status only has a legitimate function for additional Products beyond that anchor, when a CNA is building out a broader downstream manifest, which is a completeness question governed elsewhere (5.1.5, 5.1.6), not a floor question.
Proposed change: Amend 5.1.4 to read:
MUST identify at least one Product as affected. Additional Products, if identified, MAY be marked affected or unknown.
Add to the introduction of 5.1:
The minimum viable CVE Record consists of the following, all of which the CNA container MUST independently satisfy: identification of at least one affected Product (5.1.3); a definitive "affected" status for that Product (5.1.4, as amended); identification of the type of Vulnerability (5.1.7); a prose description (5.1.9); at least one public reference (5.1.10); and compliance with any approved submission format (5.1.12). This list reflects the MUST-level requirements of this section as they stand at any given time, including any later amendments that convert a SHOULD-level requirement in this section to a MUST.
Add to 5.1:
The CNA container of a CVE Record MUST independently satisfy the requirements of this section at the time of publication. Enrichment or correction supplied by an Authorized Data Publisher (ADP) MUST NOT be treated as satisfying a CNA's obligations under this section, and MUST NOT be counted toward a CNA's compliance with these rules. ADP-supplied content is additive and does not relieve the CNA of the obligation to supply complete and accurate required content in its own container.
Add a corresponding clarification to 4.5.1.1:
This requirement is not satisfied by content supplied by an ADP in lieu of the CNA.
Rationale: This closes the specific loophole illustrated by GitHub issue #42 at the Program's own CNA-LR. It doesn't prohibit ADP enrichment, which remains valuable for adding detail a CNA may not have. It just prevents that enrichment from functioning as a substitute for the CNA doing its own required work, which is the upstream-versus-downstream distinction the whole review period should be organized around. Stating the minimum viable record explicitly also gives CNAs, Roots, and any future statutory Assessment of CVE record quality a single, checkable list rather than requiring each party to independently reconstruct the floor from scattered MUST and SHOULD tags. Phrasing the list as tracking the section's MUST-level requirements "as they stand at any given time" keeps it automatically consistent with any future changes that convert specific SHOULD requirements in 5.1 to MUST, rather than requiring this list to be manually kept in sync by hand. Tightening 5.1.4 closes the all-unknown loophole without touching the legitimate use of "unknown" for supplementary Products beyond the anchor: it asks a CNA to definitively assert the one thing it already knows, not to complete a downstream investigation before publishing.
Rules Change Request: CNA container must independently satisfy required content, with no ADP backstop
Section affected: 5.1 (Required CVE Record Content) generally; also 4.5.1.1
Current text:
Problem: The rules describe requirements as applying to "a CVE Record" without specifying whether the CNA's own container must independently satisfy them, or whether the record as a whole, CNA container plus any ADP-supplied enrichment, is what gets evaluated. In practice this ambiguity lets ADP enrichment substitute for CNA-supplied content. CVE-2026-24114, cited in GitHub issue #42, is a direct example: MITRE's CNA container left vendor, product, version, and CWE as "n/a," and CISA later added the real CWE and a CVSS score as an ADP. Under a literal reading, the completed record may appear to satisfy Section 5's requirements even though the CNA never did the work the rules assign to it. This creates a standing incentive problem: if ADP enrichment can silently repair a CNA's incomplete work, there's no operational pressure on the CNA to get it right at creation time, and "an ADP will catch it" becomes a durable, unstated exception to Section 5's MUST requirements.
There's a second, related gap worth closing at the same time. Every sub-rule in 5.1 already carries an explicit MUST or SHOULD tag, and Section 1.4 defines those keywords unambiguously, so the mandatory floor for a CVE Record technically exists today. But it exists only as something a reader has to reconstruct by combing through all thirteen sub-rules of 5.1 and sorting them by keyword; there is no single place that states the floor as a checklist. A rule requiring the CNA container to "independently satisfy the requirements of this section" inherits that same diffuseness, and a CNA disputing a compliance finding could reasonably argue about what exactly the phrase covers. Stating the floor explicitly, in one place, removes that argument before it starts.
A third gap sits inside the floor itself. 5.1.4 requires at least one Product marked "affected" or "unknown," and 5.1.8 only forbids a record where every Product is marked "unaffected." Combined, these permit a CVE Record where every listed Product is "unknown" and none is ever definitively asserted as affected, a record that's technically compliant while failing to assert its own subject matter. This hedge isn't actually necessary to accommodate a CNA still investigating downstream exposure: the Product where the coding error itself lives, the one that gave the CNA reason to create the record in the first place, is always known to the CNA at creation time. The "unknown" status only has a legitimate function for additional Products beyond that anchor, when a CNA is building out a broader downstream manifest, which is a completeness question governed elsewhere (5.1.5, 5.1.6), not a floor question.
Proposed change: Amend 5.1.4 to read:
Add to the introduction of 5.1:
Add to 5.1:
Add a corresponding clarification to 4.5.1.1:
Rationale: This closes the specific loophole illustrated by GitHub issue #42 at the Program's own CNA-LR. It doesn't prohibit ADP enrichment, which remains valuable for adding detail a CNA may not have. It just prevents that enrichment from functioning as a substitute for the CNA doing its own required work, which is the upstream-versus-downstream distinction the whole review period should be organized around. Stating the minimum viable record explicitly also gives CNAs, Roots, and any future statutory Assessment of CVE record quality a single, checkable list rather than requiring each party to independently reconstruct the floor from scattered MUST and SHOULD tags. Phrasing the list as tracking the section's MUST-level requirements "as they stand at any given time" keeps it automatically consistent with any future changes that convert specific SHOULD requirements in 5.1 to MUST, rather than requiring this list to be manually kept in sync by hand. Tightening 5.1.4 closes the all-unknown loophole without touching the legitimate use of "unknown" for supplementary Products beyond the anchor: it asks a CNA to definitively assert the one thing it already knows, not to complete a downstream investigation before publishing.