quota enforcement violates User Story 515 scenario 5

[ElectricNroff]

If an organization has an ID quota of zero and has one rejected CVE ID (with no associated CVE Record), then a user in that organization can change the CVE ID to RESERVED. Once this is done, the GET /org/{shortname}/id_quota endpoint returns

{"id_quota":0,"total_reserved":1,"available":-1}

Example:

% curl http://127.1:3000/api/cve-id/CVE-2022-20061
{"cve_id":"CVE-2022-20061","cve_year":"2022","state":"REJECTED","owning_cna":"companyy","dateUpdated":"2022-07-20T07:19:49.680Z"}

use PUT /api/cve-id/CVE-2022-20061?state=RESERVED when authenticated as a user
in the companyy organization

HTTP/1.1 200 OK
{"message":"CVE-2022-20061 was successfully updated.","updated":{"requested_by":
{"user":"admin2@mitre.org","cna":"mitre"},"time":{"created":
"2022-07-20T05:56:54.803Z","modified":"2022-07-20T07:27:07.799Z"},"cve_id":
"CVE-2022-20061","cve_year":"2022","state":"RESERVED","reserved":
"2022-07-20T05:56:54.801Z","owning_cna":"companyy"}}

% curl http://127.1:3000/api/cve-id/CVE-2022-20061
{"cve_id":"CVE-2022-20061","cve_year":"2022","state":"RESERVED","owning_cna":"[REDACTED]"}

The above "HTTP/1.1 200 OK" is not allowed by User Story 515 scenario 5. The status must be 403, not 200.

[slubar]

only allow updating rejected ids to be reserved or published if there is id quota available

[slubar]

discuss appropriate fix with AWG

[david-waltermire]

I agree with the fix here. Unless the quota is checked prior to the reserved or published transition, a CNA can reject a bunch of ids and use this as "extra quota", circumventing the quota concept.

[ElectricNroff]

I don't think there should be a quota check before any transition to the PUBLISHED state. Denying a CNA's ability to publish a CVE Record hurts consumers, and doesn't effectively disincentivize bad behavior. The behavior we're trying to discourage is a CNA taking an inordinately long time to publish CVE Records (which is how they exceeded their intended quota of RESERVED CVE IDs) and also proceeding to use a Scenario 5 scheme to associate some more vulnerabilities with RESERVED CVE IDs, even though we have no confidence that CVE Records for those vulnerabilities will be submitted promptly. By contrast, whenever a CNA is attempting to move something to the PUBLISHED state, they are generally heading in the right direction in terms of compliance with CVE Program policies, and they are not exacerbating a timeliness problem. Similarly, the Secretariat once developed a "one for one" policy in which a penalized CNA would be given one new RESERVED CVE ID whenever they published the CVE Record for one RBP CVE ID (bottom of the https://cve.mitre.org/cve/cna/CVE_Program_RBP_Policy_v1-2.pdf document). This is, in effect, very similar to a policy in which we allow this type of REJECTED CVE ID (belonging to an over-quota CNA) to be transitioned, as long as that transition immediately publishes a CVE Record.

A CNA could, of course, use this type of REJECTED CVE ID to publish a CVE Record about a fake vulnerability, but that doesn't help them to subvert the quota system, and is an entirely separate abuse of the CVE Program that would have its own consequences.

In summary, I believe that User Story 515 scenario 5 was correct as originally written. "Transition to published" is not a gap that the author of scenario 5 failed to consider.

[jdaigneau5]

For modifyCVEId in cve-id.controller don't allow transition to RESERVED if there is no quota.