Rules Change Request: Mandatory functioning vulnerability intake mechanism
Section affected: 3.2.6 (CVE ID Assignment and Vulnerability Disclosure), specifically 3.2.6.1; also relevant to 3.2.3 (Public Point of Contact)
Current text:
3.2.3.1 CNAs MUST provide public POC information that is published in the List of Partners. The public POC is used for requests related to CVE ID assignment, CVE Record content, and other CVE-related issues.
3.2.6.1 CNAs MUST publish guidance that describes how the CNA assigns CVE IDs and publishes CVE Records within the context of Vulnerability disclosure.
3.2.6.2 CNAs MUST provide a URL to their CVE ID assignment and Vulnerability disclosure policies that will be included in the List of Partners.
Problem: 3.2.3.1 requires a public POC (point of contact), but its stated purpose is requests related to CVE ID assignment, CVE Record content, and other CVE-related issues, not reports from someone who has found a security defect and hasn't yet determined whether a CVE is warranted. 3.2.6.1 requires a CNA to publish guidance describing how it assigns CVE IDs within the context of Vulnerability disclosure, and 3.2.6.2 requires a URL to that guidance, but neither requires the guidance to describe an actual functioning intake mechanism: a dedicated security contact, a defined scope of what's covered, or any commitment to acknowledge a report. A CNA can satisfy 3.2.6.1 and 3.2.6.2 today by publishing a page that says almost nothing operationally useful, since the rules never require the affirmative existence of a working front door for someone who discovers a defect.
This isn't a stretch requirement. Structured, working intake practices are already common among mature CNAs across the ecosystem, not a bar unique to any one type of participant: large software manufacturers, national CSIRTs, and well-run open source projects and foundations alike typically have some real way to receive a report, even if the form it takes varies widely by size and resources. Many organizations already align with ISO/IEC 29147, the internationally recognized standard for vulnerability disclosure processes, and many open source projects already meet the same underlying goal through lighter-weight tools such as a published SECURITY.md, a platform's private vulnerability reporting feature, or a third-party bug bounty platform, which the CNA Operational Rules already recognize as a category of CNA and a common element of disclosure policy. Requiring this doesn't ask CNAs to invent something new; it asks the CNAs that haven't yet reached this baseline, whatever their size or structure, to catch up to practice that's already normal elsewhere in the ecosystem.
At the same time, the CNA population includes far more than commercial software manufacturers. The rules' own introduction lists open source software projects, maintainers, and foundations as a core category of CNA, and a rule written with only resourced organizations in mind risks being unworkable, or simply ignored, by a volunteer maintaining a project alone. The proposed change accounts for this directly rather than assuming one size fits all.
Proposed change: Add 3.2.6.5:
A CNA's published Vulnerability disclosure guidance MUST describe a functioning intake mechanism for receiving Vulnerability reports, including at minimum: (1) a contact method dedicated to receiving security Vulnerability reports, which MAY be the same as the public POC required under 3.2.3 if clearly identified as serving this purpose; (2) a stated scope describing which Products or systems are covered; and (3) a stated expectation for acknowledging receipt of a report, which the CNA MAY define in terms appropriate to its own capacity and resources.
Add 3.2.6.5.1:
A CNA's Vulnerability disclosure guidance satisfies 3.2.6.5 if it is consistent with an established framework for Vulnerability disclosure intake, such as ISO/IEC 29147, or a lightweight equivalent appropriate to the CNA's scale and resources, such as a published SECURITY.md file, a platform-provided private vulnerability reporting feature, or a third-party bug bounty platform.
Rationale: This closes the gap between what the rules currently require (publish some guidance, provide a URL) and what that guidance is actually required to contain. Splitting the base requirement (3.2.6.5) from its conformance path (3.2.6.5.1) keeps each piece independently checkable: a Root evaluating a CNA's guidance can confirm the three-part test in 3.2.6.5 on its own, then confirm separately whether 3.2.6.5.1's named frameworks or lightweight equivalents were met, rather than treating the whole thing as one undifferentiated block of text. 3.2.6.5.1 doesn't mandate a specific software manufacturer's template or legal framework; it points to an internationally recognized, manufacturer-neutral standard as one accepted way to satisfy 3.2.6.5, alongside lightweight alternatives explicitly named as sufficient for CNAs without the resources of a large organization. Many CNAs, of every size, already meet this bar in practice by using one of these paths; the requirement mainly closes a gap for participants, regardless of size, who haven't set up any of them yet. Naming both a formal standard and a lightweight equivalent keeps the accountability goal, an actual working way to report a problem, universal across the CNA population, without implicitly asking a volunteer maintainer to operate like a commercial software manufacturer.
Rules Change Request: Mandatory functioning vulnerability intake mechanism
Section affected: 3.2.6 (CVE ID Assignment and Vulnerability Disclosure), specifically 3.2.6.1; also relevant to 3.2.3 (Public Point of Contact)
Current text:
Problem: 3.2.3.1 requires a public POC (point of contact), but its stated purpose is requests related to CVE ID assignment, CVE Record content, and other CVE-related issues, not reports from someone who has found a security defect and hasn't yet determined whether a CVE is warranted. 3.2.6.1 requires a CNA to publish guidance describing how it assigns CVE IDs within the context of Vulnerability disclosure, and 3.2.6.2 requires a URL to that guidance, but neither requires the guidance to describe an actual functioning intake mechanism: a dedicated security contact, a defined scope of what's covered, or any commitment to acknowledge a report. A CNA can satisfy 3.2.6.1 and 3.2.6.2 today by publishing a page that says almost nothing operationally useful, since the rules never require the affirmative existence of a working front door for someone who discovers a defect.
This isn't a stretch requirement. Structured, working intake practices are already common among mature CNAs across the ecosystem, not a bar unique to any one type of participant: large software manufacturers, national CSIRTs, and well-run open source projects and foundations alike typically have some real way to receive a report, even if the form it takes varies widely by size and resources. Many organizations already align with ISO/IEC 29147, the internationally recognized standard for vulnerability disclosure processes, and many open source projects already meet the same underlying goal through lighter-weight tools such as a published
SECURITY.md, a platform's private vulnerability reporting feature, or a third-party bug bounty platform, which the CNA Operational Rules already recognize as a category of CNA and a common element of disclosure policy. Requiring this doesn't ask CNAs to invent something new; it asks the CNAs that haven't yet reached this baseline, whatever their size or structure, to catch up to practice that's already normal elsewhere in the ecosystem.At the same time, the CNA population includes far more than commercial software manufacturers. The rules' own introduction lists open source software projects, maintainers, and foundations as a core category of CNA, and a rule written with only resourced organizations in mind risks being unworkable, or simply ignored, by a volunteer maintaining a project alone. The proposed change accounts for this directly rather than assuming one size fits all.
Proposed change: Add 3.2.6.5:
Add 3.2.6.5.1:
Rationale: This closes the gap between what the rules currently require (publish some guidance, provide a URL) and what that guidance is actually required to contain. Splitting the base requirement (3.2.6.5) from its conformance path (3.2.6.5.1) keeps each piece independently checkable: a Root evaluating a CNA's guidance can confirm the three-part test in 3.2.6.5 on its own, then confirm separately whether 3.2.6.5.1's named frameworks or lightweight equivalents were met, rather than treating the whole thing as one undifferentiated block of text. 3.2.6.5.1 doesn't mandate a specific software manufacturer's template or legal framework; it points to an internationally recognized, manufacturer-neutral standard as one accepted way to satisfy 3.2.6.5, alongside lightweight alternatives explicitly named as sufficient for CNAs without the resources of a large organization. Many CNAs, of every size, already meet this bar in practice by using one of these paths; the requirement mainly closes a gap for participants, regardless of size, who haven't set up any of them yet. Naming both a formal standard and a lightweight equivalent keeps the accountability goal, an actual working way to report a problem, universal across the CNA population, without implicitly asking a volunteer maintainer to operate like a commercial software manufacturer.