Are Decision Points always ordered sets?

[ahouseholder]

So far I believe all SSVC Decision Points are ordered sets. That is, they are not merely category labels, but there is an implied ordering e.g., Automatable Yes > No; Exposure Open > Controlled > Small.

This is also generally true of (I think) all CVSS vector elements to date. (Counterexamples hereby requested.)

But is this ordering property axiomatic to the defintion of a decision point that there must always be a value gradient to the decision point options, i.e., that they are directional and there is a "better" and "worse" end to the list?

Retaining this property would guarantee the ability to construct a partial order over all inputs and allow for consistency checks of the type "the priority of (a1,a2,a3) must be greater than or equal to the priority of (b1,b2,b3) if a1>b1, a2>b2, and a3>b3" where a1 and b1 are different values from decision point 1, a2 and b2 different values from decision point 2, and so on. That has turned out to be useful in evaluating the (literally) millions of possible CVSS v4 vectors, and seems like we'd be wise to consider instituting a similar approach.

I'm personally in favor of making this a rule about Decision Point construction, but I'm curious to hear others' thoughts on the matter.

If we were to decide to allow non-ordered categories as mere labels, then the decision point representation should include a way to indicate for each decision point whether it is ordered or not. That would still allow for a partial order over the orderable decision points to be constructed and the same consistency check applied, but we'd need to be able to tell which ones were ordered or not.

[j---]

I think we could declare them to need to be ordered by definition. I don't have any counterexamples for CVSS. I think when two values don't have a clear ordering relationship, they go in separate decision points (SSVC) / metrics (CVSS).

[ehatleback]

I don't think I'm opposed to forcing ordering upon the decision points, but I'll note that the Coordinator decision points (for both the "take a case?" and the "publish something?" decisions) don't necessarily have a "better" or "worse," unless we make the stipulation that "better" means you're more likely to do something (open a case, publish a report) and "worse" means you're less likely to do so.

I take that to be a little different that the "standard" trees, where there really is an inherent "better" and "worse" in terms of vul assessment.

[j---]

Good point. I think we can order things from "more likely to coordinate" to "less likely to coordinate" and that is a valid ordering. Similarly, we can order things from "more likely to mitigate or remediate a vulnerability" to "less likely..." without loss. We can avoid actually using "better" or "worse" as the criteria.

So I think we can declare that values within a decision point have an ordering as a design choice for SSVC.

[ahouseholder]

Given this comment

values within a decision point have an ordering

This part seems resolved.

Followup question: Does this extend to decision outcomes?

I think we'd agree that

• Defer < Scheduled < Out-of-Cycle < Immediate
• Decline < Track < Coordinate
• Don't Publish < Publish
• Low < Medium < High < Critical

But is this ordering axiomatic for SSVC decisions as well? Or do we anticipate the need to support unordered categories? Can anyone think of an example of an unordered categorization that we might want to support with SSVC?

[j---]

I'd say yes. Same logic -- if two outcomes are not ordered with relation to each other, they should be the result of different decisions.

[ahouseholder]

Captured in issue #299