Change Request: Prohibit CNA bypass of the CVE Record API and validation library
Section affected: 4.5.5 (CVE Record Formatting and Interfaces), specifically 4.5.5.1
Current text:
4.5.5.1 CNAs MUST submit CVE Records in the formats and through the mechanisms specified by the CVE Program.
Problem: GitHub issue #42, filed by Jerry Gamblin, documents the resulting failure rate at MITRE's own CNA-LR: roughly 84% of MITRE's CNA-assigned records carry placeholder "n/a" values in fields the rules mark MUST. That issue's proposed fix addresses the symptom: what the record should contain. It does not address the mechanism that made the failure possible. MITRE's records are written directly to the database, bypassing the validation library and the CVE Record Format API entirely. Whatever the validation library currently catches or fails to catch, records that never pass through it can't be caught by anything, today or after the library improves.
This matters beyond the specific MITRE numbers. Section 4.5.5.1 already says CNAs MUST submit CVE Records in the formats and through the mechanisms specified by the CVE Program, but the rules do not say direct database writes are out of bounds, and the largest CNA-LR is demonstrably doing exactly that. A validation-by-design strategy only works if submission through the validated path is universal. Every exception, even one, is a hole quality enforcement can't see through, and a CNA-LR bypassing it as routine practice sets the precedent that the requirement is optional for whoever has direct database access.
Proposed change: Add four new sub-sections after 4.5.5.3:
4.5.5.4 CNAs MUST submit CVE Records exclusively through the CVE Record Format API and its validation mechanisms.
4.5.5.5 Direct modification of CVE Record data outside the path described in 4.5.5.4 MUST NOT occur, except in documented exigent circumstances approved by the Secretariat.
4.5.5.6 The Secretariat MUST maintain a dated, itemized record of every exception permitted under 4.5.5.5, including the CNA involved, the CVE Record affected, and the stated exigent circumstance. This record MUST be reviewable by the CVE Board.
4.5.5.7 The API and validation library described in 4.5.5.4 MUST be built to handle infrequent, high-volume, or time-sensitive submission scenarios, so that an exception under 4.5.5.5 is never operationally necessary.
These four are severable, though 4.5.5.6 depends on 4.5.5.5 existing (there's nothing to log without an exception carve-out to log against). 4.5.5.4 and 4.5.5.7 stand independently of the other two and of each other.
Rationale: This is the enforcement precondition for the entire "Quality by Design" effort. Structured fields, validation rules, and DQAF-style measurement all assume records pass through a single, improvable choke point. If any CNA, especially the CNA-LR of last resort, can write around that choke point, then improving the validation library only raises quality for CNAs who were already complying, while doing nothing for the CNA whose noncompliance is currently the most visible and highest-volume example. The API needs to be good enough that bypassing it is never the practical answer to a time-sensitive or high-volume situation. If it isn't there yet, that's a roadmap item for the API team, not a standing justification for direct writes.
Change Request: Prohibit CNA bypass of the CVE Record API and validation library
Section affected: 4.5.5 (CVE Record Formatting and Interfaces), specifically 4.5.5.1
Current text:
Problem: GitHub issue #42, filed by Jerry Gamblin, documents the resulting failure rate at MITRE's own CNA-LR: roughly 84% of MITRE's CNA-assigned records carry placeholder "n/a" values in fields the rules mark MUST. That issue's proposed fix addresses the symptom: what the record should contain. It does not address the mechanism that made the failure possible. MITRE's records are written directly to the database, bypassing the validation library and the CVE Record Format API entirely. Whatever the validation library currently catches or fails to catch, records that never pass through it can't be caught by anything, today or after the library improves.
This matters beyond the specific MITRE numbers. Section 4.5.5.1 already says CNAs MUST submit CVE Records in the formats and through the mechanisms specified by the CVE Program, but the rules do not say direct database writes are out of bounds, and the largest CNA-LR is demonstrably doing exactly that. A validation-by-design strategy only works if submission through the validated path is universal. Every exception, even one, is a hole quality enforcement can't see through, and a CNA-LR bypassing it as routine practice sets the precedent that the requirement is optional for whoever has direct database access.
Proposed change: Add four new sub-sections after 4.5.5.3:
These four are severable, though 4.5.5.6 depends on 4.5.5.5 existing (there's nothing to log without an exception carve-out to log against). 4.5.5.4 and 4.5.5.7 stand independently of the other two and of each other.
Rationale: This is the enforcement precondition for the entire "Quality by Design" effort. Structured fields, validation rules, and DQAF-style measurement all assume records pass through a single, improvable choke point. If any CNA, especially the CNA-LR of last resort, can write around that choke point, then improving the validation library only raises quality for CNAs who were already complying, while doing nothing for the CNA whose noncompliance is currently the most visible and highest-volume example. The API needs to be good enough that bypassing it is never the practical answer to a time-sensitive or high-volume situation. If it isn't there yet, that's a roadmap item for the API team, not a standing justification for direct writes.