Consider support multiple value-selections via a “Selection Set” JSON schema

[sei-vsarvepalli]

The existing Decision_Point_Value_Selection-2-0-0.schema.json defines how to select a value for a single decision point for one vulnerability. In practical use, a consumer may need to submit selections for multiple vulnerabilities using multiple decision points at once. Currently, there's no built-in structure within the schema to package multiple such selections in a list or batch. Consider a schema that either references or re-uses Selection Schema to be replicated for multiple items that can be exported, shared and interpreted through the schema provided.

[tschmidtb51]

@sei-vsarvepalli There might be a CSAF impact in that suggestion but I think I didn't fully understand your suggestion. Could you please provide, how an instance could look like or provide an example?

[sei-vsarvepalli]

Hello @tschmidtb51

It does not impact CSAF. As each CSAF vulnerability report can copy and include multiple vulnerabilities with its own container. So there is no concern there. The use case is someone sharing a SSVC selection that is a bundle for distinct vulnerabilities.

[ahouseholder]

@sei-vsarvepalli We can already express the following, which I would interpret as "all four CVE IDs listed are ssvc:A:2.0.0=Y".

{
  "timestamp": "2025-08-27T14:15:41.062106",
  "schemaVersion": "2.0.0",
  "target_ids": [
    "CVE-1900-0001",
    "CVE-1900-0020",
    "CVE-1900-0300",
    "CVE-1900-4000"
  ],
  "selections": [
    {
      "namespace": "ssvc",
      "key": "A",
      "version": "2.0.0",
      "values": [
        {
          "key": "Y"
        }
      ]
    }
  ],
  "decision_point_resources": [],
  "references": []
}

So I think this might be a documentation-only thing? It doesn't seem like the data structure needs to change.

Granted, it would be weird for this to show up in the context of a CSAF document that was only about "CVE-1900-0001", but that seems more like a usage problem not necessarily a data problem.

[sei-vsarvepalli]

@sei-vsarvepalli We can already express the following, which I would interpret as "all four CVE IDs listed are ssvc:A:2.0.0=Y".

{ "timestamp": "2025-08-27T14:15:41.062106", "schemaVersion": "2.0.0", "target_ids": [ "CVE-1900-0001", "CVE-1900-0020", "CVE-1900-0300", "CVE-1900-4000" ], "selections": [ { "namespace": "ssvc", "key": "A", "version": "2.0.0", "values": [ { "key": "Y" } ] } ], "decision_point_resources": [], "references": [] } So I think this might be a documentation-only thing? It doesn't seem like the data structure needs to change.

Granted, it would be weird for this to show up in the context of a CSAF document that was only about "CVE-1900-0001", but that seems more like a usage problem not necessarily a data problem.

Yes, however.. What if we say Automatable is different value for each of the CVE's? I think the idea is to bundle multiple vulnerability evaluations into a larger selections array for a report. I am foreseeing potentially a structure where a SSVC Report template has multiple selections and even optionally Decision Trees embedded for convenience of not having to lookup. It may also help partners who do some of the offline patch management and may not have the Decision Tree that were used accessible/handy.

[ahouseholder]

What if we say Automatable is different value for each of the CVE's? I think the idea is to bundle multiple vulnerability evaluations into a larger selections array for a report. I am foreseeing potentially a structure where a SSVC Report template has multiple selections

What I think you're describing is just:

list(SelectionList)

so I'm not sure what else we'd do with that. (As in: list is already a valid python and json data object, so what else is there to be done?)

and even optionally Decision Trees embedded for convenience of not having to lookup. It may also help partners who do some of the offline patch management and may not have the Decision Tree that were used accessible/handy.

I'm really unclear on what this entails, and it sounds like a very different requirement than the simple "list of SelectionLists" from above. I'd suggest splitting this part off into a separate issue if it can be fleshed out better.

[sei-vsarvepalli]

As a solution I am considering a "SSVC Report" schema that will have the following objects. Just capturing it while I remember!

evaluations : list(SelectionList) contacts: Points of Contact (Emails, webforms URI's) context: Full Decision Trees