Rules Change Request: Mandatory assignment and disclosure for vulnerabilities affecting downstream operators, users, or customers
Section affected: 4.2.2 (Primary Assignment), specifically 4.2.2.2; also implicates 4.2.5
Current text:
4.2.2.2 CNAs SHOULD Publicly Disclose and assign a CVE ID if the Vulnerability: 1. has the potential to cause significant harm, or 2. requires action or risk assessment by parties other than the CNA or Supplier.
4.2.5 CNAs MUST NOT assign CVE IDs for Vulnerabilities the CNA does not intend to Publicly Disclose unless the Vulnerabilities are already or are expected to be Publicly Disclosed.
Problem: 4.2.2.2 says CNAs SHOULD publicly disclose and assign a CVE ID when a vulnerability has the potential to cause significant harm, or requires action or risk assessment by parties other than the CNA or Supplier. This is precisely the scenario where downstream operators, users, or customers need to know a vulnerability exists so they can assess and manage their own risk, and it is written as a recommendation, not a requirement. Compounding this, 4.2.5 prohibits a CNA from assigning a CVE ID at all for a vulnerability it does not intend to publicly disclose, unless disclosure is already happening or expected through some other channel. Together, these two rules mean a Supplier CNA can determine internally that a vulnerability meets the significant-harm or third-party-risk threshold in 4.2.2.2, and still have no obligation under the rules to ever disclose it or assign it a CVE ID, regardless of how severely downstream parties could be affected. The current framework leaves full discretion with the party that created or discovered the vulnerability over whether the people relying on the affected product ever find out.
Proposed change: Upgrade 4.2.2.2 from SHOULD to MUST:
CNAs MUST Publicly Disclose and assign a CVE ID if the Vulnerability: 1. has the potential to cause significant harm, or 2. requires action or risk assessment by parties other than the CNA or Supplier.
Add a corresponding carve-out to 4.2.5 so the disclosure-avoidance gate cannot be used to override this obligation:
This prohibition does not apply to Vulnerabilities meeting the criteria in 4.2.2.2, which MUST be Publicly Disclosed regardless of the CNA's or Supplier's independent disclosure intentions.
Rationale: The CVE Program exists so that downstream parties, operators, users, customers, and the tools and processes they depend on, can identify and manage risk with confidence that they are working from complete information. A discretionary standard for exactly the vulnerabilities most likely to cause real harm undermines that purpose where it matters most. This proposal establishes a bias toward protecting the people who bear the consequences of a vulnerability, rather than toward the convenience or preference of the party that created or discovered it. It extends a principle already present elsewhere in the rules, such as 4.1.4 ("Insecure default configuration settings SHOULD be determined to be Vulnerabilities") and 4.4.3 ("err on the side of assignment"), applying MUST-level force to the specific cases the rules already recognize as highest-stakes.
This isn't an isolated concern. GitHub issue #47, filed independently by Jay Jacobs, makes a parallel argument at a different point in the rules: upgrading 4.2.6 from SHOULD to MUST so CNAs can't lump separate vulnerabilities into fewer CVE IDs than they warrant. That's a different mechanism than this proposal and not a duplicate of it, but it's evidence of the same underlying pattern: SHOULD-level language in the rules currently lets a CNA's discretion make a vulnerability's existence or true scope look smaller than it is, whether by not disclosing it at all or by undercounting how many there are.
Rules Change Request: Mandatory assignment and disclosure for vulnerabilities affecting downstream operators, users, or customers
Section affected: 4.2.2 (Primary Assignment), specifically 4.2.2.2; also implicates 4.2.5
Current text:
Problem: 4.2.2.2 says CNAs SHOULD publicly disclose and assign a CVE ID when a vulnerability has the potential to cause significant harm, or requires action or risk assessment by parties other than the CNA or Supplier. This is precisely the scenario where downstream operators, users, or customers need to know a vulnerability exists so they can assess and manage their own risk, and it is written as a recommendation, not a requirement. Compounding this, 4.2.5 prohibits a CNA from assigning a CVE ID at all for a vulnerability it does not intend to publicly disclose, unless disclosure is already happening or expected through some other channel. Together, these two rules mean a Supplier CNA can determine internally that a vulnerability meets the significant-harm or third-party-risk threshold in 4.2.2.2, and still have no obligation under the rules to ever disclose it or assign it a CVE ID, regardless of how severely downstream parties could be affected. The current framework leaves full discretion with the party that created or discovered the vulnerability over whether the people relying on the affected product ever find out.
Proposed change: Upgrade 4.2.2.2 from SHOULD to MUST:
Add a corresponding carve-out to 4.2.5 so the disclosure-avoidance gate cannot be used to override this obligation:
Rationale: The CVE Program exists so that downstream parties, operators, users, customers, and the tools and processes they depend on, can identify and manage risk with confidence that they are working from complete information. A discretionary standard for exactly the vulnerabilities most likely to cause real harm undermines that purpose where it matters most. This proposal establishes a bias toward protecting the people who bear the consequences of a vulnerability, rather than toward the convenience or preference of the party that created or discovered it. It extends a principle already present elsewhere in the rules, such as 4.1.4 ("Insecure default configuration settings SHOULD be determined to be Vulnerabilities") and 4.4.3 ("err on the side of assignment"), applying MUST-level force to the specific cases the rules already recognize as highest-stakes.
This isn't an isolated concern. GitHub issue #47, filed independently by Jay Jacobs, makes a parallel argument at a different point in the rules: upgrading 4.2.6 from SHOULD to MUST so CNAs can't lump separate vulnerabilities into fewer CVE IDs than they warrant. That's a different mechanism than this proposal and not a duplicate of it, but it's evidence of the same underlying pattern: SHOULD-level language in the rules currently lets a CNA's discretion make a vulnerability's existence or true scope look smaller than it is, whether by not disclosing it at all or by undercounting how many there are.