What are the versioned objects in SSVC?

[ahouseholder]

Extending a discussion with @j--- and @sei-vsarvepalli

What are the versioned artifacts within SSVC?

Discussion should address: (at least)

• decision points
• trees
• documentation

[ahouseholder]

This discussion supersedes (or at least blocks) Issue #252 about the use of SemVer in versioning.

[ahouseholder]

On Decision Point Versioning

I think individual decision point definitions might be versionable objects, for example:

• Exploitation: None, PoC, Active
• Automatable: No, Yes

At present, these are "defined" not only in the text, but also in each tree .json they appear in. See for example these lines in the Deployer.json file.

But what I'm thinking is that if we refactored the .json files such that each decision point was a separate file, e.g.,

{
  "label": "Automatable",
  "key": "A",
  "decision_type": "simple",
  "options": [
    {
      "label": "no",
      "key": "N",
      "description": "Steps 1-4 of the kill chain..."
     },
     {
       "label": "yes",
       "key": "Y",
       "description": "Steps 1-4..."
        }
  ]
}

We could define a decision point's identity as the tuple of the decision point label and the labels of each of its options. So if any of those changed, we'd want to call it something else i.e., those changes are identity-breaking and therefore we're not talking about a new version of X, instead we're talking about a new thing Y that might replace X in future usage.

In summary:

• An SSVC "version" might introduce new decision points or new functions (trees) over existing decision points (or both)
• Strictly speaking, Decision Points might not need to be explicitly versioned because they're basically static once introduced. (Because any semantic change just forks into a new decision point.)
• However, for future-proofing purposes we might want to include a key-value pair in the decision point definition to represent a version ID.
• Semver probably makes sense for decision point versioning because we don't anticipate them changing much once they go 1.0 (and typo fixes etc. could just bump the fix version e.g., 1.0.2 -> 1.0.3)
• We could establish rules such as
  • version 0.x is reserved for pre-support Decision Points and their shorthand key, labels, number of labels, ordering of labels, descriptions, semantics, etc. are all subject to change
  • version 1.0 freezes the Decision Point labels, number of labels, and their ordering
  • version 1.0.x for x > 0 would be limited to description changes

So that also implies, I think, that we probably need to have a versioned schema for Decision Point definitions.

[ahouseholder]

I recommend we put all Decision Points in one JSON schema that is identified as part of SSVC version X. So we end up with a new JSON schema that snaps out all decision points

In this approach, would each Decision Point have a version or would the decision_points object have the version?

I think my preference would be that the individual decision points be versioned rather than the decision_points object. The rationale for this is that if the version is attached to the decision_points object, then any change to any decision point would require a version bump even if most of the decision points were unchanged. That seems like it has the potential for unnecessary version churn where Exploitation vX.x.x and Exploitation vY.x.x are in fact identical but the delta between Y-X is large.

[sei-vsarvepalli]

To be clear today Decision Points don't have a version.

The idea of Versioning each Decision Point brings its own set of troubles as well, Decision Tree will have to capture each Decision Point with versions. A Computed output that goes into CVE ADP (evaluated decisions), now have to show connection Decision Points, as discussed a Computed output does NOT necessarily have a relation to Decision Tree.

I think keeping a set of Decision Points immutable makes things a bit easier. My thought is to reference Decision Points version vX.x.x with a set. We won't talk about Exploitation vY.x.x but more like Decision Points vY.x.x->Exploitation. Is it also fair to imagine Decision Points may have relationship to other Decision Points in a SSVC version? For example change to Exploitation definition (and choices) changes can impact Automatable definition (and choices) ?

[ahouseholder]

I'm imagining a future where SSVC provides a library of dozens of decision points (or more). For example, we might include each element of a CVSS v4 vector as a Decision Point (CVSS v4 has 32 distinct elements, only a couple of which overlap exactly with SSVC v2.1, add one more if you want to represent the severity categories themselves as a decision point), or additional Decision Points to address various critical software lists (e.g., NIST, OSSF), regulatory relevance, etc.

Why might we do that?

• To allow stakeholders to construct their own decision functions based on a common library of enumerated decision points
• To demonstrate that other decision functions are possible on CVSS vectors
• To expand the utility of SSVC to other stakeholders and/or different decisions within already known stakeholder processes

My hunch is that at least in the near future, adding decision points will be more common than changing them, which might devolve from a versioning problem to a status flag indicating whether the decision point has been frozen or not. Decision Points by and large should be simple enough that we aren't really changing them once they're "done".

The set of decision points will grow over time, which means if you're versioning the set you're incrementing something at each change, even though most of the elements in the set aren't changing with each set version. On the other hand, an individual decision point might have some early churn while we're working out its semantics, but then it basically freezes and doesn't get more updates. A binary flag with semantics representing whether a decision point is in "draft" vs "frozen" status might be sufficient for "versioning" decision points.

Not sure if any of that affects your thinking.

[j---]

I think there is a disconnect in what Allen (and largely also me) are trying to say and what Vijay is reading back as understanding us saying.
Building on the difference between an identity change and version change. A decision point is identified as the full group of {name:opion1,...optionX}. If the text string of the name, the labels for the options, the number of options, possibly the order of the options (unless we declare some sort of canonicalization sort order), changes then it's a different identity and not a new version. Versioning therefore only applies to the definitions that describe how those options are intended to be selected among. This is why "versioning decision points doesn't make sense" is mostly true. Version 1.0 on a decision point would just mean we've tested it enough that we are happy with the name and options as being viable. Then we tend to iterate on improving the descriptions.

SSVC probably doesn't need a version number at all. It's just the collection of viable decision points. However, it is convenient to slightly abuse versioning information on the document to signal that we, for example, significantly updated the introduction section and provided a lot of new guidance on how to customize trees, or added examples for a new stakeholder. But this is realistically an abuse of notation and we should not get hung up on what the fact the current doc is labeled v2.1 says about this conversation we're having here. If having the doc labeled with a version number is confusing, we can just switch to date-based versioning for the documentation writ large.

The schema for how decision points are captured once their identity is settled and we have descriptive text for them is a json object that needs a version. I expect this shouldn't change much. But it absolutely should be separable such that decision points are the atomic unit of description.

This is because trees also basically do not have versions. The same as decision points, most changes to a tree change it's identity. I see Allen's separate points below, but this is hard to break apart entirely because the decisions are related of course. I think trees also largely only have versions to fix typos, otherwise v1 just signals we did enough testing to declare them viable examples. But a tree should pretty much just be named by a canonical sort on its constituent decision points. For this reason, it would be convenient if no decision points change option names or sets without also changing their name (per above). This is the only sense in which tree versioning depends on decision point versioning. Otherwise, decision points should be managed as totally independent from trees. Trees are built out of decision points.

there would need to be a json schema for defining the lookup table that represents the function from a set of decision points to a set of outcomes. That schema also shouldn't change very often. Each lookup table is a "tree" and the only thing we have to talk about is related to changes to risk tolerance / risk appetite represented by the tree (that is, if two trees have identical decision points, and identical outcomes on 31 out of 32 lines, but on line 3 one has the outcome as defer and the other has it as scheduled, what do we call the relationship between those trees?)

[jeroenh]

I was thinking about possible use-cases for versioning in this context. It is helpful to have a version for the stable collection of decision points in SSVC to be able to reference a set of possibilities at a given moment.
So that someone can say: "I analysed my context and used the SSVC v2.1 set of decision points to make a decision tree for my context". This provides a reproducible context by identifying the realm of possibilities in that context.

I don't see a particular use-case for using decision points from different version sets. On the one hand because I agree that decision points will probably not change much once they're stable. And on the other hand, I have trouble imagining a situation where it would be helpful to combine differently versioned decision points.

[sei-vsarvepalli]

Extending a discussion with @j--- and @sei-vsarvepalli

What are the versioned artifacts within SSVC?

Discussion should address:

• decision points
• trees
• documentation

WE may need to version the schema itself, as we could think of schema making it more automation friendly as we get feedback.

[ahouseholder]

On Tree Versioning

I think a tree's identity is defined by

1. the set of Decision Points it includes e.g., {Exploitation, Exposure, Automatable, Human Impact}
2. the specific mapping of decision point value permutations to outcomes e.g., (none, small, no, medium) -> defer

Notably absent is that I do not believe the order of the decision points matters. Yes, any SSVC UI has to make a choice about how to display the decision points and outcomes, and the metaphor of a tree is useful for displaying it. But different Decision Point orderings do not make for different trees, they make for different presentations of the same tree. From a data standpoint the "tree" is just a lookup function that maps each permutation of decision point labels to an outcome.

Note that I'm talking about the order of the decision points themselves as in (1) above. {Exploitation, Exposure, Automatable, Human Impact} is the same as {Automatable, Human Impact, Exposure, Exploitation} (assuming the mapping to outcomes is unchanged). I am specifically not referring to the ordering of labels within a decision point e.g., none, PoC, active for Exploitation, because the ordering within a decision point is often (always?) significant.

The questions appear to include:

• Do trees need to be versioned at all?
• Do trees need to be versioned separately from the documentation?

Following is a summary of how the example tree targeted at system owners (patch appliers, deployers) has evolved:

Tree Name	SSVC Version	Decision Points Included	Outcomes changed?
Patch Applier	1.0	Exploitation, Exposure, Mission Impact, Safety Impact	n/a (new tree)
Patch Applier	1.1	Exploitation, Exposure, Mission Impact, Safety Impact	I didn't check
Deployer	2.0	Exploitation, Exposure, Utility, Human Impact	n/a (new tree)
Deployer	2.1	Exploitation, Exposure, Automatable, Human Impact	yes

I have not reviewed the outcomes of Patch Applier 1.1 compared to 1.0, but let's assume for argument's sake that they stayed the same. Which means that the SSVC v1.0 Patch Applier Tree is equivalent to the SSVC v1.1 Patch Applier Tree. It seems odd to me that we'd want to change the version of an unchanged thing.

On the other hand, it seems like SSVC v2.0 Deployer and SSVC v2.1 Deployer are actually significantly different, perhaps enough to bump a major version of the tree if we were to version trees separately (and depending on what versioning ruleset we eventually come to).

However, if we were to posit that a future major version of SSVC (say, v3.0) were to leave both the structure and outcomes of the Deployer tree unchanged, would it warrant calling that the SSVC v3.0 Deployer tree even though nothing had changed from SSVC v2.1?

I think this argues in favor of having versioning rules for trees, and that those versions are distinct from the "SSVC version", whatever that becomes.

The next question is whether outcome changes (e.g., risk shift adjustments) constitute versioned events). But this essay is long enough for now, so I'll leave that for a potential follow-up post.

[jeroenh]

I agree that it makes sense to have versions for trees that can be independent from the documentation version.

The documentation is probably something that changes more quickly than trees. And some trees can stay stable over different versions, so that it is helpful to say that a specific tree is still the same.

[ahouseholder]

In this comment I contradict what I said above:

I think a tree's identity is defined by

1. the set of Decision Points it includes e.g., {Exploitation, Exposure, Automatable, Human Impact}
2. the specific mapping of decision point value permutations to outcomes e.g., (none, small, no, medium) -> defer

Specifically, I can no longer assert that (2) is part of the tree identity, and I'm thinking of the tree as more of a pinned set of versioned decision points.

The distinction between 1 and 2 also seems to delineate the idea that 2 is a policy choice whereas 1 is based on an attempt to isolate and identify the relevant information content to which a decision policy could be applied.

[j---]

Extending a discussion with @j--- and @sei-vsarvepalli

What are the versioned artifacts within SSVC?

Discussion should address: (at least)

* decision points

* trees

* documentation

So adding to this, there is at least one other thing that might need to be versioned, and that is SSVC the system. Where the system is a collection of decision points. Documentation is separate from the system, because documentation is about how to use the system, as well as documentation of what the decision points and example trees are.

[jeroenh]

I think we need to be clear on definitions here and should probably introduce some terms in the documentation as well.

• Decision Points are the different elements introduced in SSVC on which decisions are made, an example of a Decision Point is "Technical Impact".
• Decision Values are the enumerated set of values that a particular Decision Point can take. Following the example of "Technical Impact", a possible Decision Value is "Partial".
• Outcomes are the enumerated set of outcomes that are suggested actions to take based on the specific Decision Values of a set of relevant Decision Points. An example outcome is "Scheduled".
• Decision Set is an unordered set of pairs of Decision Point and Decision Values. A Decision Set does not necessarily include all possible Decision Points, nor does it necessarily include an Outcome. So for example using the Abbreviated Form: SSVCv2/Ps:Nm/T:T/U:E/
• Decision Tree is a collection of Decision Sets with Outcomes that cover the range of all the different permutations over a selected set of (Decision Point, Decision Value) possibilities. They are called a Tree, because that is a helpful way of visualising the concept. An example of a Tree is the SSVC2 Deployer Tree.
• Computed Decision Set is the outcome of the analysis of a specific vulnerability, scoring that vulnerability on a set of Decision Points, for example: SSVCv2/Ps:Nm/T:T/U:E/2018-11-13T20:20:00Z/

[jeroenh]

With regards to versioning documentation: yes, we really need to do that. There will be cases where someone points to a documentation saying "the definition of Decision Point A was B in version X.Y", small changes can affect the interpretation of that, so we need to version that.

This can be as simple as having a timestamp of the last change, but then it should include a changelog somewhere in the document.

[sei-vsarvepalli]

@jeroenh

Very good.. Thanks for your feedback. Some clarifications

Decision Set is an unordered set of pairs of Decision Point and Decision Values. A Decision Set does not necessarily include all possible Decision Points, nor does it necessarily include an Outcome. So for example using the Abbreviated Form: SSVCv2/Ps:Nm/T:T/U:E/

Clarification :

1. Ideally the Decision Set has all the Decision Points frozen by a version - so sharing of Decision Values across Decision Trees is possible. For example a Coordinator and a Deployer far apart in the CVD lifecycle can all use the same Decision Point, especially the Stakeholder Agnostic ones like Exploitability. Note: This is sharing of an evaluation with other stakeholders distinct from sharing of Decision Tree itself.
2. In the example Abbreviated Form, what you are describing here is more of an "evaluated" or "computed" Decision Set and not just an ordered Decision Points. This can basically go in the Computed Decision Set (discussed below) and be shared. The Computed Decision Set can use a Decision Tree or a Decision Set and provide only some of the evaluations optionally include the Outcome if deemed to do so.

Computed Decision Set is the outcome of the analysis of a specific vulnerability, scoring that vulnerability on a set of Decision Points, for example: SSVCv2/Ps:Nm/T:T/U:E/2018-11-13T20:20:00Z/

Clarification:

3. In this statement is the "outcome" distinct from the Outcome that we defined earlier? In my mind the Computed value is either from a Decision Tree or from a Decision Set and it optionally contains the Outcome. So a Computed value can be shared between stakeholders as mentioned earlier. Even if a Coordinator Tree stakeholder provides his full Decision Tree, a Deployer can still consume part of the Decision Tree if he trusts the Coordinator's evaluations.

---

Now just throwing some scenarios specifically for this concern of sharing evaluations between Stakeholders.

Scenario A: A Coordinator-1 uses Coordinator Tree version Coordinator-20230801.0.0 with a Decision Set versioned "Rambo-2023080801.0.0" and provides an SSVC evaluation of SSVCv2/E:N/A:N/T:P/P:M/B:M/M:L/D:T/2023-08-10T16:06:47Z/ for a CVE-0001-0001

In this situation, any stakeholder using Decision Set "Rambo-2023080801.0.0" can choose to trust the Coordinator-X and absorb all the computed values for the shared Decision Points with the Coordinator-1. They could use the Exploitability and Automatability readily from E:N/A:N values and ignore the rest of the computed Decision Values and the Outcome for this CVE-0001-0001

Scenario B: A Coordinator-2 uses a Decision Set versioned "Rambo-2023080801.0.0" and provides an SSVC evaluation of SSVCv2/E:N/A:N/2023-08-10T16:06:47Z/ for a CVE-0001-0001

This situation is identical however any stakeholders wanting to trust Coordinator-2 can basically absorb these evaluations into their Decision Tree if they use Decision Set versioned "Rambo-2023080801.0.0" as part of their Tree.

Scenario C: A Supplier-1 uses a customized version of Decision Tree "Supplier-20230801.0.0-Acme" which includes Decision Set versioned "Rambo-2023080801.0.0-Acme" customized from "Rambo-2023080801.0.0" provides a completed SSVC evaluation SSVCv2/E:P/A:N/V:D/U:L/T:P/P:M/R:C/2023-08-10T16:22:51Z/ for CVE-0001-0001

In this situation, say Supplier-2, who uses the default Supplier Decision Tree versions "Supplier-20230801.0.0", is in the supply-chain using Supplier-1's impacted product can accept the full evaluation from Supplier-1 and use it as is for this decision to do a "Scheduled" as the evaluated action/outcome of the default Supplier Decision Tree .

Other stakeholders such as Deployer-1, who uses any Decision Tree built to include the Decision Set "Rambo-2023080801.0.0", and has the Supplier-1 product identified in CVE-0001-0001 and trusts the Supplier-1's evaluation, can consume SSVCv2/E:P/A:N/V:D/ portion of the Computed Decision Values.

Stakeholders such as Supplier-3 who also uses Supplier-1 but has the default Decision Tree "Supplier-20210801.0.0" that uses a default Decision Set versioned "Wonka-20210301.0.0" is forced to redo the evaluation done by the Supplier-1. There are few options on how to consume Supplier-1's data - ideally if the Supplier-3 accepts/upgrades to Decision Set "Rambo-2023080801.0.0" - the sharing is made easier. Till then some rework may result.

[ahouseholder]

I am finding this comment and its replies hard to follow because it seems to muddy the water by mixing data representation and implementation choices like whether the data structure supports i18n (which it should, imo), or how to represent computed outcomes, with the identity discussion about decision points, "trees", "decision sets" etc.

@sei-vsarvepalli I think many of your ideas here are well-thought out, but it feels like many of them are out ahead of where I'm at in thinking about what the core object are and what determines their identity.

@jeroenh Your point about defining terms is well-put.

• I'm with you on Decision Points being constructed from Decision Values
• I might differ in thinking of an Outcome as the Outcome Value returned by a Decision Function in reflection of a policy
• The thing you're calling Outcomes I'd probably call an Outcome Set
• I'm skeptical on Decision Set as a useful construct because it seems like an opportunity to just version a lot of combinatorics
• I think the concepts of Decision Set and Computed Decision Set are too far apart to have such similar names

[jeroenh]

The Decision Set and Computed Decision Set is probably the hardest thing to pin down, because similar constructs are used in different contexts:

• A Decision Tree (such as SSVC2 example Deployer) consists of an enumeration of Decision Points with specific Decision Values, possibly with an Outcome Value depending on this discussion.
• CTI Providers will analyse specific vulnerabilities and provide a subset of Decision Points with Values to summarise their analysis, and provide it as machine-readable input for customers/constituents.
• The result of an analysis within an organisation for a specific vulnerability will include a set of Decision Points with specific Decision Values and an Outcome Value, which they will likely log as the action to take on a specific vulnerability.

It probably makes sense to have terminology to distinguish between these three different cases.

[ahouseholder]

This comment was written prior to reading @sei-vsarvepalli's previous comment so please forgive any redunancies or contradictions

I needed to make the "decision point version" idea more concrete. But we don't have a lot of examples of decision points changing over time within SSVC. So instead, I'm going to use CVSS elements as a proxy, acting as if CVSS vector elements are functionally equivalent to an SSVC decision point. I'm not trying to model all elements from all versions of CVSS, just a few that serve as good examples.

CVSS Version -->	v1	v2	v3	v4
Access Vector	local remote	local adjacent network	physical local adjacent network	physical local adjacent network
How I'd version it	1.0	2.0	2.1	2.1
Attack Complexity	high low	high medium low	high low	high low
How I'd version it	1.0	1.1	1.0	1.0
Authentication	required not required	multiple single none	n/a	n/a
How I'd version it	1.0	2.0	-	-
Privileges Required	n/a	n/a	none low high	none low high
How I'd version it	-	-	1.0	1.0
Exploitability	unproven poc functional high	unproven poc functional high not defined	unproven poc functional high not defined	n/a
How I'd version it	1.0	1.1	1.1	-
Exploit Maturity	n/a	n/a	n/a	unreported poc attacked not defined
How I'd version it	-	-	-	1.0
Report Confidence	unconfirmed uncorroborated confirmed	unconfirmed uncorroborated confirmed not defined	unknown reasonable confirmed not defined	n/a
How I'd version it (if unknown and reasonable are semantically different from unconfirmed and uncorroborated)	1.0	1.1	2.0	-
How I'd version it (if unknown and reasonable simply renames of unconfirmed and uncorroborated)	1.0	1.1	1.2	-

The versioning principles that emerged for me from this exercise are:

Do this...	...when...
New Object	A different or new concept is being represented Note: new objects get new names
Major Version	Existing options are removed Option semantics change in a way that older answers are no longer usable New options are added that divide previous semantics ambiguously Note: The ability to map old to new semantics is encouraged byt not required
Minor Version	New options are added Option names are changed while semantics are _retained AND all existing options are retained with compatible semantics
Fix Version	No changes to number of options No changes to semantics of options Typo fixes in option names or decision point name

[ahouseholder]

The next thing to observe about this is that if we extend the analogy to claim that CVSS versions are just functions on the decision points and analogous to SSVC trees and the functions that they enable, then we could describe CVSS versions as:

CVSS Version	Pinned Decision Points
v1	Access Vector 1.0, Attack Complexity 1.0, Authentication 1.0, Exploitability 1.0, Report Confidence 1.0, etc.
v2	Access Vector 2.0, Attack Complexity 1.1, Authentication 2.0, Exploitability 1.1, Report Confidence 1.1, etc.
v3	Access Vector 2.1, Attack Complexity 1.0, Privileges Required 1.0, Exploitability 1.1, Report Confidence 2.0, etc.
v4	Access Vector 2.1, Attack Complexity 1.0, Privileges Required 1.0, Exploit Maturity 1.0, etc.

(Note this does not define the policy, i.e., the mapping of each combinatorial input to the function to an output. Which in the case of CVSS might be a score or a L/M/H/C category.)

[jeroenh]

It feels like a bad practice to lower a version number, even when you're reverting to a previous version.

I can understand that it makes sense to signal how much specific Decision Points have changed between versions.
But I have a hard time imagining the usefulness of that version outside of the documentation of a specific CVSS version. I mean, is it really likely that someone will mix Access Vector 2.1 from v4 with Authentication 1.0 and Report Confidence 1.1 ?

[ahouseholder]

I think this is the difference between thinking of Decision Points as belonging to sets vs as a monotonically growing library of blocks from which decision functions can be built. So in my original thought in laying this out, Attack Complexity 1.0 and Attack Complexity 1.1 remain available for future use in perpetuity.

However, it appears to be the case with Attack Complexity that a change was introduced in CVSSv2 and then reverted in v3. This highlights the possibility that we might want to include a way of deprecating a version, in which case the likely advice would be to always use the highest non-deprecated version in new trees. The strength of that advice would be dictated by whether or not we impose an automatic deprecation rule or not.

For example: in the AC case, there would have been three epochs.

My original thought was that it'd go like this:

Epoch	AC 1.0 status	AC 1.1 Status
1	In Use	Did not exist
2	Available for Use	In Use
3	In Use	Available for Use

But if a deprecation flag were introduced, maybe 1.1 got deprecated when CVSSv3 came out:

Epoch	AC 1.0 status	AC 1.1 Status
1	In Use	Did not exist
2	Available for Use	In Use
3	In Use	Deprecated

Does Introducing a new version automatically deprecate the older version?

If not, then the decision to deprecate AC 1.1 in CVSSv3 would have to be a deliberate choice, while AC 1.0 would have remained available throughout by default.

If either

• introducing a new decision point version automatically deprecates the old one, or
• deprecation is not automatic but the designers chose to deprecate AC 1.0 when AC 1.1 was introduced

and assuming deprecation is forever, then the history would have been forced into:

Epoch	AC 1.0 status	AC 1.1 Status	AC 2.0 Status
1	In Use	Did not exist	Did not exist
2	Deprecated	In Use	Did not exist
3	Deprecated	Deprecated	In Use

Where AC 1.0 and AC 2.0 are identical. At which point we're now basically in Theseus' Shipyard debating the relevance of history to the identity of two otherwise indistinguishable data objects. I don't think that history matters in this case.

That said, I'm more inclined to think that the second table above would have been preferable to the third. And both seem superior to the first because the first exists in a world in which there is no way to revoke a poorly formed decision point from future use.

Summarizing:

• I'm ok with decision point versions moving in either direction when used repeatedly in other versioned objects
• I'm also ok with multiple versions of decision points being "live and available for use" by folks modeling decisions
• However, I also think that Decision Points SHOULD have a way to indicate a deprecated status as a means to stave off future regrets

[ahouseholder]

Second, orthogonal thought from the above:
If decision points are provided by one entity and decision functions are defined by another, then the decision function provider may not have the ability to dictate the decision point versioning at all.

Say that we provide a library of versioned decision points, which includes both AC 1.0 and AC 1.1 as above.

Someone elsewhere working on an SSVC/CVSS hybrid started out using AC 1.1 in version 1 of the decision function they define for some stakeholder-relevant decision they are modeling. Later they come to regret that choice and their function version bumps from 1-2 while repinning to the AC 1.0 decision point.

In turn, they come to us with a PR to create an AC 2.0 that is identical to AC 1.0 because they want decision point versions in version n+1 of their function to be >= to decision point versions in version n of their function.

If the decision point provider is distinct from the decision function provider, this seems like a weak argument for increasing version numbers for what amounts to reverting to a previous version.

I don't think this scenario is too far fetched. Imagine: Someday an SSVC consortium owns the decision point library, but cyber threat intelligence and vulnerability management providers are building decision functions for their respective constituencies. It seems to me that a rule that creates a dependency on component versions never decreasing becomes difficult to sustain.

[ahouseholder]

This comment is addressing the "what is a tree?" and related "what do you mean by policy?" topics that weave through this discussion.

This was also composed independently of the thread begun in @sei-vsarvepalli's comment above. It's lifted from an internal chat conversation at CERT earlier today

I'll start with a diagram in which overlapping subsets of 5 decision points are used as input to two distinct decision functions which map policy decisions and return an outcome.

graph LR
  dp1[decision point 1]
  dp2[decision point 2]
  dp3[decision point 3]
  dp4[decision point 4]
  dp5[decision point 5]
  subgraph df1[decision func. A]
	  df1i[inputs]
	  df1p[policy]
  end
  subgraph df2[decision func. B]
	df2i[inputs]
	df2p[policy]
  end
  df1o[outcome]
  df2o[outcome]
  dp1 --> df1
  dp2 --> df1
  dp3 --> df1
  dp2 --> df2
  dp3 --> df2
  dp4 --> df2
  dp5 --> df2
  df1 -->|returns| df1o
  df2 -->|returns| df2o
  df1i -->|maps onto| df1p
  df2i -->|maps onto| df2p

Loading

Say we use the usual four-option outcome set {defer, scheduled, out-of-cycle, immediate}. Also, for this exercise imagine that each decision point is a coin toss (to keep the input space small). The task is to define a mapping from the eight possible input triplets onto the four outcome options. I'm calling that mapping itself a policy.

In the table below, I'll show two possible policies (the specific order of the outcome columns as aligned to the input values).

DP1	DP2	DP3	DF Policy 1	DF Policy 2
T	T	T	defer	defer
H	T	T	scheduled	out-of-cycle
T	H	T	out-of-cycle	scheduled
H	H	T	immediate	immediate
T	T	H	scheduled	out-of-cycle
H	T	H	out-of-cycle	out-of-cycle
T	H	H	immediate	immediate
H	H	H	immediate	immediate

This highlights an ambiguity that I think has been impeding a lot of the conversation so far:

1. One definition of "a tree" (which is a decision function) that if you specify (DP1, DP2, DP3) where each of them is well defined (e.g., a coin toss), then that's the "identity" of a tree. So if we used that definition, then the table above represents one tree but two policies. (Also note: The table only shows possible Decision Function A implementations from the diagram.)
2. A second interpretation of "a tree" is that the combinations of columns (DP1, DP2, DP3, DF Policy 1) describes one tree while (DP1, DP2, DP3, DF Policy 2) represents a different tree.

I am strongly in favor of (1), because it preserves the idea that if you fully specify the pinned versions of decision points as I describe in this comment we can easily have a conversation about the structure of a decision's inputs and the relevant dimensions without also having to address the policy outcomes that are inherent to (2).

[ahouseholder]

Cross-referencing this comment to note that what I wrote here contradicts something I said earlier about a tree's identity including the policy mapping. I'm no longer so confident about that as I was previously.

[jeroenh]

I agree that a Decision Tree should be separate from the DF Policy. In my opinion DF Policies are context specific and will have to be defined by the organisation applying it for their context.

But the relevant Decision Points are generally the same.

[laurie-tyz]

I have a concern regarding the word policy. I believe policy is set first and then Procedures implement the policy.

Vision-mission-policy.docx

[ahouseholder]

I think our usage of policy is consistent with Lobo, Jorge, Randeep Bhatia, and Shamim Naqvi. "A policy description language." AAAI/IAAI 1999 (1999): 291-298. https://cdn.aaai.org/AAAI/1999/AAAI99-043.pdf

(I chose that article because it was the most cited hit on Google Scholar for the phrase "we define a policy as")

From their introduction:

In AI, a policy is usually defined as a complete mapping from states (of the world) to actions (Russell Norvig 1995). In system
management, a policy describes principles or strategies for a plan of action designed to achieve a particular set of goals identified by the managers of the system. This high level description of management applies to very general situations such as establishing policies to increase inter-departmental interactions in a company to more technical situations such as defining traffic policies to reduce overload in a computer network. Policies can be specified at different levels of abstraction. At a very elementary level we find policies specified using production rules as in the standard AI definition. At a very high level we can find policies specified using natural language. In this document we are interested in some intermediate point for which we still have an effective computational model.

We define a policy as a function that maps a series of events into a set of actions. In contrast to the standard AI definition of policies, we assume that there is an intermediate service (with sensors) between the policy server and the environment that continuously polls the environment and communicates to the policy server only the changes in the environment (events) that may
require the enforcement of a policy. This concept is not new, and it has been informally used in network management.

(emphasis added)

We're using it at the lower-end of the abstraction scale because we're ultimately talking about functions designed to be implemented in software, but I think it's a good point that most folks will think of policy at the higher abstraction levels mentioned in the quote above. If we wind up using policy more in the SSVC docs we should clarify that usage in light of the above.

[laurie-tyz]

I agree with this statement: "We define a policy as a function that maps a series of events into a set of actions. " And we should spell it out what we mean when we say "policy".

[ahouseholder]

Was this discussion closed intentionally? It doesn't seem fully resolved to me.

[j---]

I was also confused by it being closed.

[sei-vsarvepalli]

The consensus so far leans on using version number to track individual Decision Point. For now we can

1. Capture Decision Points (without a Decision Tree) as independent items with their own versioning
2. We can use The versioning principles mentioned earlier to decide how these are managed
3. No need to capture a Decision Set that brings together a number of Decision Points into a distinct unit with its own versioning

My biggest concern remains traceability of a number of items (Decision Points) with their own version numbers and no association as a set or integrated into a Decision Tree. We can always use it for sometime to see how it works out.

Some questions that come at least immediately.

1. How to handle versions for "Combined Value" like Human Impact https://github.com/CERTCC/SSVC/blob/main/doc/md_src_files/05_08_human_impact.md - Does the version of Situated Safety Impact also change Human Impact version? or Do we treat things like Human Impact as a single Decision Point?
2. Seems like Decision Tree is a collection of Decision Point(s) along with "Policy" as Outcomes. Are Outcomes part of the Decision Tree only? There is no relevance of these Outcomes outside a Decision Tree?
3. Does a Decision Trees included in each SSVC release needs a versioning too?
4. Do we need to restrict Decision Points to any structured schema like JSON schema for sharing OR can we just use unique labels and unique vector identifiers (single letter identifier) use the vector form as they are declared to be unique anyway.

There is probably more questions that will come up as we try to implement this into a practical application.

[ahouseholder]

Replying here only to your first point:

How to handle versions for "Combined Value" like Human Impact
https://github.com/CERTCC/SSVC/blob/main/doc/md_src_files/05_08_human_impact.md - Does the version of Situated Safety Impact also change Human Impact version? or Do we treat things like Human Impact as a single Decision Point?

Based on recent conversations, I think we concluded that "compound decision points" like Human Impact and Utility only exist for notational convenience. That is, they were created in order to provide a visual compression of a tree representation so that it could fit into a single PDF page. In terms of data representation, they are entirely substitutable with their component atomic decision points' values.

Because of this, we are leaning toward not versioning compound decision points, and instead recasting them as examples of how atomic decision points can be combined into new features for ease of communication when needed.

[ahouseholder]

Public Safety Impact is another such example

[sei-vsarvepalli]

Use Cases and such for a more productive discussions on next meeting.

Scenario A:
Say we have solved question (1) above on Decision Points being versioned object, can we take the current Deployer Decision Tree and as a mock exercise create a new Decision Tree (. using Decision Points versioned and made into a Decision Point Set)? what will this look like? Where will Outcomes be identified and come from? How are the Outcomes identified?

Scenario B:
Similar to Scenario A for a different Decision Tree say Supplier Decision Tree.

Scenario C:

Alice (supplier/vendor) and Bob (deployer) would like to use Exploitability information published by CISA to work out the Decision Trees they will use. If Alice and Bob want to use default Decision Trees provided as “examples” part of the SSVC documentations version X.

What is Alice’s recommended Decision Tree named?
What is Bob’s recommended Decision Tree named?
Can we represent Alice’s decision in a SSVC vector form?
Can Alice’s SSVC data be shared with Bob? How? What will it look like?
Bob would like to customize the Decision Tree with a new Outcome - what are the steps?

[ahouseholder]

@sei-vsarvepalli I think discussion #303 might be a better place to continue this line of thought. Not because it doesn't belong here too, just that I think this discussion thread has grown to the point that we probably ought to be thinking of this thread as about versioning decision points and #303 as about versioning decision trees.

• I think I've addressed scenario A in Defining tree versions #303 already. I'm curious to see if you agree.
• I'm happy to address Scenario B if there are open questions given what's in Defining tree versions #303.

Summarizing #303 as it relates to the questions in Scenario C:

What is Alice’s recommended Decision Tree named?
What is Bob’s recommended Decision Tree named?

Your setup for the scenario doesn't say what default tree they're starting from. Let me propose the Deployer Tree since we're already talking about it in #303. I'd say the name of both Alice and Bob's tree is the "Deployer Priority Tree" or whatever alias we give that construct.

Can we represent Alice’s decision in a SSVC vector form?

I'd expect we can represent the inputs to her decision in vector form.

Now the question of whether the vector form represents the outcome label too is (I think) either unresolved or no.

Can Alice’s SSVC data be shared with Bob? How? What will it look like?

Decision point values associated with a specific vulnerability should be sharable, yes. Vector form, JSON, text, are all viable means of conveyance.

What do you mean when you say "SSVC data" though? It seems like we might have different things in mind here.

Bob would like to customize the Decision Tree with a new Outcome - what are the steps?

I think it'd be something like:

1. Choose a starting decision tree that is close to the role/decision Bob is making
2. Decide whether the tree (whose identity, if my opening suggestion in Defining tree versions #303 survives, is defined as the set of pinned versions of the specific decision points that fully define its combinatorial inputs)
3. Let's assume for argument's sake that 2 is satisfied, and Bob just wants to relabel a few leaf nodes with different outcomes.
4. Bob takes the csv file for the decision tree, and updates the outcome column.

I think this is pretty much what Bob would do today, and that it's been consistent since day one. I'm not clear what concern you have that prompted this question.

[sei-vsarvepalli]

Sample Decision Points schema being iterated in very early stages - here https://gist.github.com/sei-vsarvepalli/de2cd7dae33e1e1dc906d50846becb45

[ahouseholder]

I've also been playing with this with Python dataclass_json objects.

A bunch of examples here: https://github.com/ahouseholder/SSVC/tree/feature/pyjson/src/ssvc/decision_points

(I went ahead and modeled CVSS 1, 2, and 3 to exercise some of the versioning ideas.)

With some example .json outputs here https://github.com/ahouseholder/SSVC/tree/feature/pyjson/docs/reference/examples

[sei-vsarvepalli]

This looks good with examples. Personally I am not a fan of "Data Classes" - software seems to go where people adoption goes. I have preferred keeping data and code designation distinct. But I think these fields are not so regularly changing Data Classes will be fine.

On the JSON schema itself, it is not quite ready for final lap yet. At least one thing, I didn't quite do was to make the description fields to become arrays called descriptions with tuple of Language + UTF-8 Text so we can support multiple language contribution to the Decision Points.

[ahouseholder]

Yeah, I recognize that we're converging on a format not just matching an already-done json to a python implementation.

As for dataclasses: in python they save a ton of boilerplate which simplifies the json-python roundtrip. Inheritance used to be a problem with default values in parent dataclasses, but with the kw_only=True option that's now largely no longer a problem.

[sei-vsarvepalli]

Few things I noticed after looking into @ahouseholder SSVC repository https://github.com/ahouseholder/SSVC/tree/feature/pyjson/src/ssvc/decision_points

1. Looks like python3.10 is required for this version of dataclasses - the default python on Mac is 3.9 looks like. Should we mention this somewhere? Python3.9 throws an error for dataclass(kw_only=True) .
2. The https://github.com/ahouseholder/SSVC/blob/a254e9c926385049162c1f9284072d9dfab5c451/docs/reference/examples/human_impact.json#L9 calls the "values" output as "name" shouldn't this be labeled "value"? This we can disambiguate the "name" that is used for the Decision Point itself.
3. The Decision Point Group should not have any of the following fields https://github.com/ahouseholder/SSVC/blob/a254e9c926385049162c1f9284072d9dfab5c451/src/ssvc/dp_groups/coordinator_publication.py#L14C1-L17C21 - it is only a collection of decision points. These seem like they belong in the Decision Tree and not in a Decision Point Group as I understand from our discussions.

[ahouseholder]

This is now a draft PR #328. Still work to be done of course, that's why it's a draft.

Comments above captured where relevant in the PR.

[ahouseholder]

The decision regarding the versioning of decision points is covered in PR #350.

A separate PR for versioning of decision point groups will be forthcoming.

[ahouseholder]

Based on

• add ADR proposals for decision point versioning. #350
• Add Decision Point Group Versioning ADRs #368
• ADRs for Decision Points and Outcomes as ordered sets #440
• ADR: Outcome sets are separate from decision point group (tree) identity #444

I'm marking this discussion closed.

We may need to consider the question of outcome set versioning separately. I've created #454 to capture that as its own issue.