Rules Change Request: Structured, machine-resolvable product and version identification
Section affected: 5.1.2, 5.1.3
Current text:
5.1.2 SHOULD identify the vulnerable Products, versions, dates, components, sub-components, features, modules, APIs, functions, function calls, commands, utilities, or programs, to the degree necessary to uniquely identify the Vulnerability.
5.1.3 MUST identify at least one affected Product using information such as Supplier and Product names, versions, and dates.
Problem: Product and version identification is the most frequently cited failure mode in stakeholder interviews conducted by the CVE Consumer Working Group (CWG), a CVE Program working group focused on how well CVE Records actually serve the downstream tools and people who depend on them, ahead of every other category. The rules as written don't require a structured, machine-resolvable identifier at all: 5.1.3's "using information such as" language permits free text, and CNAs commonly encode version ranges as free-text hyphenated strings in the affected array even though structured range fields already exist elsewhere in the schema. A record can pass schema validation while still being unusable by automated pipelines that need to know precisely which versions are affected, because the structured fields designed for that purpose go unused in favor of prose that has to be re-parsed downstream.
A universal machine-resolvable identifier requirement runs into a real gap, though. Package URL (PURL) works well for software distributed through a package manager, which covers most open source, but there is no equivalent self-service, federated identifier for commercial software generally. CPE is the closest existing option, but it is centrally authored by NIST rather than owned by the Supplier whose product it describes, and that centralization is a large part of why CPE adoption and data quality have been persistently poor. Requiring a PURL-equivalent that doesn't exist for the commercial case would be an aspirational requirement without a realistic mechanism behind it.
Proposed change: Upgrade 5.1.3 to require consistent identification rather than allowing the vendor and product fields (the schema calls this field vendor, even though the rules prose uses "Supplier") to be absent or filled with placeholder text:
MUST identify at least one affected Product using distinct, non-empty values for Supplier name and Product name in their respective fields. These fields MUST NOT be left blank and MUST NOT contain placeholder values such as "n/a" or "unknown" outside the circumstances described in 5.1.6.
Add 5.1.3.1 for the cases where a stronger identifier is genuinely available:
Where the affected Product is published to a package manager or similar package registry, the CNA MUST additionally provide at least one Package URL (PURL) identifying the originating package, if a PURL type is defined for that registry, in addition to the Supplier and Product name fields required above. A single PURL identifying the package as published by its Supplier satisfies this requirement; the CNA is not required to enumerate every downstream repackaging, vendoring, or redistribution of the same code. If the Product is published to a package manager or similar registry for which no PURL type is yet defined, the CNA MUST supply the reserved value indicating this, rather than omitting the field or fabricating an identifier. Where the Product is not distributed through a package manager or similar registry, but a canonical source code repository exists, the CNA MUST instead provide that repository's URL using the CVE Record Format's existing repositoryUrl field. This sub-rule does not apply, and no structured identifier is required, only where neither a package-manager identifier nor a canonical source repository exists.
Add 5.1.3.2:
Version ranges MUST be expressed using the structured version range fields provided by the CVE Record Format. Free-text version ranges (for example, hyphenated strings in prose) MUST NOT be used in place of the structured fields when structured fields are available for the same information.
These three additions are severable. The Board could adopt the 5.1.3 naming floor on its own, or adopt 5.1.3.2's version-range requirement without 5.1.3.1's identifier requirements, or any other combination; none depends on the others being adopted.
Rationale: This is one of the most consequential fixes available for closing the gap between schema validity and machine usability, since it targets the single biggest driver of downstream confusion by the CWG's own research. The requirement has three parts, each addressing a different piece of the machine-usability gap: a universal floor of consistent vendor and product naming at 5.1.3 itself, a stronger identifier layered on top at 5.1.3.1 only where one genuinely exists, whether that's a PURL for package-manager-distributed software or a source repository URL where it isn't, and structured version ranges at 5.1.3.2, replacing the free-text hyphenated strings CNAs currently default to. Keeping these separate keeps the requirement honest about what's actually achievable today, across every kind of CNA.
For a Supplier CNA, correctly naming its own product is self-attestation: no central registry required, since a Supplier is definitionally the authoritative source for its own name and its own product's name. That's first-party accountability applied to identity: the entity closest to the product is also the entity best positioned to name it correctly. For a coordinator, aggregator, or researcher CNA, a bug bounty platform coordinating a report on behalf of a Supplier is a representative case, or any CNA that also holds Supplier status for some products but is coordinating on behalf of another organization in this instance, the task is different: correctly identifying who made the affected product and what it's called, even though the CNA doesn't own it. That's accurate third-party attribution, not self-attestation, but it's still achievable without a structured universal identifier, since it's the same due diligence already implicit in determining that a vulnerability exists in a specific product in the first place (4.2.2.1).
Either way, populating two plain-text fields correctly doesn't require a namespace authority the way PURL or CPE does. PURL is layered on top as an additional requirement only where a genuine package-manager identifier exists, rather than being asked to stand in for an identifier system that doesn't exist for commercial software generally.
5.1.3.1 is scoped to Products actually distributed through a package manager or similar registry, or that have a canonical source code repository even without one. The reserved not-applicable value, for the package-manager case, is for the narrow situation where such a registry exists but PURL hasn't defined a type for it yet, not for the much larger set of commercial products with no package-manager distribution at all. Those products fall to the repository case instead where a canonical repository exists, and to no structured identifier at all only where neither applies. The repository requirement doesn't need a schema change, repositoryUrl already exists in the CVE Record Format specifically for identifying source code repositories, so this closes the C/C++ gap immediately rather than waiting on infrastructure that doesn't exist yet. C/C++ projects without a package-manager identifier often do have a canonical repository worth capturing, and the OSV vulnerability format independently reaches the same conclusion, defaulting to git-based repository and commit-range identification specifically for ecosystems without a defined packaging system. That convergence is useful corroboration that this isn't a one-off accommodation but an established, sound pattern for exactly this case.
Rules Change Request: Structured, machine-resolvable product and version identification
Section affected: 5.1.2, 5.1.3
Current text:
Problem: Product and version identification is the most frequently cited failure mode in stakeholder interviews conducted by the CVE Consumer Working Group (CWG), a CVE Program working group focused on how well CVE Records actually serve the downstream tools and people who depend on them, ahead of every other category. The rules as written don't require a structured, machine-resolvable identifier at all: 5.1.3's "using information such as" language permits free text, and CNAs commonly encode version ranges as free-text hyphenated strings in the
affectedarray even though structured range fields already exist elsewhere in the schema. A record can pass schema validation while still being unusable by automated pipelines that need to know precisely which versions are affected, because the structured fields designed for that purpose go unused in favor of prose that has to be re-parsed downstream.A universal machine-resolvable identifier requirement runs into a real gap, though. Package URL (PURL) works well for software distributed through a package manager, which covers most open source, but there is no equivalent self-service, federated identifier for commercial software generally. CPE is the closest existing option, but it is centrally authored by NIST rather than owned by the Supplier whose product it describes, and that centralization is a large part of why CPE adoption and data quality have been persistently poor. Requiring a PURL-equivalent that doesn't exist for the commercial case would be an aspirational requirement without a realistic mechanism behind it.
Proposed change: Upgrade 5.1.3 to require consistent identification rather than allowing the vendor and product fields (the schema calls this field
vendor, even though the rules prose uses "Supplier") to be absent or filled with placeholder text:Add 5.1.3.1 for the cases where a stronger identifier is genuinely available:
Add 5.1.3.2:
These three additions are severable. The Board could adopt the 5.1.3 naming floor on its own, or adopt 5.1.3.2's version-range requirement without 5.1.3.1's identifier requirements, or any other combination; none depends on the others being adopted.
Rationale: This is one of the most consequential fixes available for closing the gap between schema validity and machine usability, since it targets the single biggest driver of downstream confusion by the CWG's own research. The requirement has three parts, each addressing a different piece of the machine-usability gap: a universal floor of consistent vendor and product naming at 5.1.3 itself, a stronger identifier layered on top at 5.1.3.1 only where one genuinely exists, whether that's a PURL for package-manager-distributed software or a source repository URL where it isn't, and structured version ranges at 5.1.3.2, replacing the free-text hyphenated strings CNAs currently default to. Keeping these separate keeps the requirement honest about what's actually achievable today, across every kind of CNA.
For a Supplier CNA, correctly naming its own product is self-attestation: no central registry required, since a Supplier is definitionally the authoritative source for its own name and its own product's name. That's first-party accountability applied to identity: the entity closest to the product is also the entity best positioned to name it correctly. For a coordinator, aggregator, or researcher CNA, a bug bounty platform coordinating a report on behalf of a Supplier is a representative case, or any CNA that also holds Supplier status for some products but is coordinating on behalf of another organization in this instance, the task is different: correctly identifying who made the affected product and what it's called, even though the CNA doesn't own it. That's accurate third-party attribution, not self-attestation, but it's still achievable without a structured universal identifier, since it's the same due diligence already implicit in determining that a vulnerability exists in a specific product in the first place (4.2.2.1).
Either way, populating two plain-text fields correctly doesn't require a namespace authority the way PURL or CPE does. PURL is layered on top as an additional requirement only where a genuine package-manager identifier exists, rather than being asked to stand in for an identifier system that doesn't exist for commercial software generally.
5.1.3.1 is scoped to Products actually distributed through a package manager or similar registry, or that have a canonical source code repository even without one. The reserved not-applicable value, for the package-manager case, is for the narrow situation where such a registry exists but PURL hasn't defined a type for it yet, not for the much larger set of commercial products with no package-manager distribution at all. Those products fall to the repository case instead where a canonical repository exists, and to no structured identifier at all only where neither applies. The repository requirement doesn't need a schema change,
repositoryUrlalready exists in the CVE Record Format specifically for identifying source code repositories, so this closes the C/C++ gap immediately rather than waiting on infrastructure that doesn't exist yet. C/C++ projects without a package-manager identifier often do have a canonical repository worth capturing, and the OSV vulnerability format independently reaches the same conclusion, defaulting to git-based repository and commit-range identification specifically for ecosystems without a defined packaging system. That convergence is useful corroboration that this isn't a one-off accommodation but an established, sound pattern for exactly this case.