Decision process for whether coordinator assigns a CVE ID

[j---]

The CNA rules allow for a fair amount of flexibility for what an individual stakeholder decides about assigning CVE IDs. There are some basic rules here: https://cve.mitre.org/cve/cna/CNA_Rules_v3.0.pdf, section 7.

Within these constraints, it would be useful for a stakeholder to be able to define their own decision about when they assign a CVE ID.

To demonstrate this, we can prototype a coordinator of last resort's decision process for how that stakeholder assigns a CVE ID. Result is yes (assign) or no (do not assign) or insist (that vendor change their mind).

Some first ideas on the elements in the decision are:

• Is Vendor a CNA (CNA rules Section 7.3 CNA Scope) (yes/no)
• Whether reporter or vendor will assign (yes/no)
• Multivendor (yes/no) (existing coordination decision point)
• This question only makes sense if the coordination tree resulted in coordinate

It would make sense to call assigning a CVE ID as an option for coordination activity, just clear this up in the text about the coordination tree.

[ahouseholder]

Noting that a CVE assignment behavior tree logic is already described in Fig. 7.11 and Sec. 7.5.6 (p93) of Designing Vultron: A Protocol for Multi-Party Coordinated Vulnerability Disclosure.

[j---]

Perhaps the answer is a brief summary and reference within SSVC to the Vultron work then?

[cgyarbrough]

I am all for efficiency and for integrating SSVC terminology and processes with Vultron.

[ahouseholder]

Current relevant Vultron link:

https://certcc.github.io/Vultron/topics/behavior_logic/id_assignment_bt/

[sei-ahouseholder]

Capturing the cross-reference for posterity: todb/cve-documents#1 has a flow chart that could easily be turned into an AssignCVEID v1.0.0 DecisionTable.

[Santoshkumarpuppala]

The three decision points in the opening post — vendor-is-a-CNA, whether reporter or vendor will assign, multivendor — all resolve who assigns. None of them resolves whether the thing is assignable in the first place, and as a reporter that second question is where I find the disagreement actually sits.

The Vultron tree has the same shape. in scope? and Is CNA? are about the coordinator's position; assignable? is the only leaf carrying the substantive judgement, and it's the only one I can't find decomposed anywhere. The page resolves it by reference — the vulnerability "meets the criteria for assigning an ID", linking out to CNA Rules section 7 — rather than by breaking it down. If this becomes an AssignCVEID decision table, that leaf is where every argument will happen, and leaving it as a single boolean would relocate the ambiguity rather than resolve it.

sei-ahouseholder's cross-reference is the useful part here — todb's triage checklist is an attempt to decompose exactly that leaf, in prose, right now. I left a review on CVEProject/cve-documents#40 about what I think its section 1.3 is missing; I won't repeat it here. The point for this issue is that if the checklist becomes the source for an AssignCVEID table, whatever is missing from the checklist will be missing from the table too, and it is much cheaper to fix upstream of the encoding.

One question rather than a suggestion: is assignable? meant to be a single decision point in this table, or the outcome of its own sub-table feeding into it? The answer changes whether the checklist work belongs inside this issue or beside it.