Feature/issue 576

[sei-vsarvepalli]

This is a major change in Schemas to resolve #576 and try to create new schemas that can be processed by third parties efficiently. This requires some changes to vulnrichment project with ADP exports. Our schema has been updated, but there are external dependencies.

cisagov/vulnrichment#40

There is a new option in the schema called outcome which is optional and can be used represent the comprehensive outcomes of the current Decision Tree. This can provide outcomes of the full decision tree, just like the outcomes from a decision point, so the next consumer can use this values to restrict outputs from the decision tree.

The JavaScript code also has been updated. This requires a bit of thorough review as there may be other dependencies that are impacted by this schema comprehesnive update. Currently there is a version number in the Computed Schema, but that should be managed before parsers are written to read Computed schema when used alongside of ADP or other data providers.

@j--- may need to help coordinate with CISA developers to ensure the new schema is adopted by CISA developers.

[ahouseholder]

Following up on this comment and expanding on this comment from #576:

It seems like we need the list of chosen items to include more specificity about what decision point they're drawn from. I was thinking something like:

{
  "decision_points": [
    {
      "namespace": "ssvc",
      "name": "Exploitation",
      "version": "1.0.0",
      "key": "E",
      "values": [ "None" ]
    },
    {
      "namespace": "ssvc",
      "name": "Automatable",
      "version": "2.0.0",
      "key": "A",
      "values": [ "Yes" ]
    }
  ]
}

Which shares the namespace, name, version, key, and values properties from the DP schema but only includes the name(s) of the chosen values. Note that description is present in the DP schema but omitted in the example, as I don't think it's necessary in this case, we're not defining the decision point with this record we're just downselecting from the available options. Since each decision point has a namespace, a name, and a version, it seems important to fully identify them though.

In the current Computed example we have

{
"Exploitation": "active"
},
{
  "Automatable": "no"
}

which is now underspecified since there can be different versions of Exploitation and Automatable.

[sei-vsarvepalli]

Following up on this comment and expanding on this comment from #576:

It seems like we need the list of chosen items to include more specificity about what decision point they're drawn from. I was thinking something like:

{
  "decision_points": [
    {
      "namespace": "ssvc",
      "name": "Exploitation",
      "version": "1.0.0",
      "key": "E",
      "values": [ "None" ]
    },
    {
      "namespace": "ssvc",
      "name": "Automatable",
      "version": "2.0.0",
      "key": "A",
      "values": [ "Yes" ]
    }
  ]
}

Which shares the namespace, name, version, key, and values properties from the DP schema but only includes the name(s) of the chosen values. Note that description is present in the DP schema but omitted in the example, as I don't think it's necessary in this case, we're not defining the decision point with this record we're just downselecting from the available options. Since each decision point has a namespace, a name, and a version, it seems important to fully identify them though.

In the current Computed example we have

{
"Exploitation": "active"
},
{
  "Automatable": "no"
}

which is now underspecified since there can be different versions of Exploitation and Automatable.

Optionally the full Decision Tree ordered with outcomes (compliant to Provisioned schema) can be embedded to show all the information. In the compressed form, the chained version pedigree will be the way to be clear about what DP's are being used.

[sei-vsarvepalli]

Some more issues to be concerned about

• Depends on Consider versioning Outcomes like Decision Points #454
• Outcome groups should be a schema perhaps ? Need json schema for outcome groups #589
• Small bug src/ssvc/policy_generator.py PolicyGenerator sample fix AUTOMATABLE_1 to be AUTOMATABLE_2 Policy generator uses AUTOMATABLE_1, should be AUTOMATABLE_2 #590
• Should Policy have a schema that consumes Outcome Groups and should it be versioned? Consider adding a json schema to represent a policy #591 We need a Policy object #592
• Provision schema is essentially a full Policy, which is a full Decision Tree. If Policy is versioned, there is no concern about versioning this distinctly, if not this may also need versioning
• Computed schema is essentially to communicate an evaluated instance of a Policy for a specific vulnerability or group of vulnerabilities. It should also be versioned and can optionally include the full Policy.
• All schemas should have a version as well to ensure any new JSON schema - may also need distinct $id fields and folder/locations in url. JSON Schemas should be versioned #596

[sei-vsarvepalli]

The example
https://github.com/CERTCC/SSVC/blob/7d5aadf71fec2f388f483d50856ab5384a665c8f/data/schema_examples/Decision_Point_Group_Selection.json
does not have an identifier such as a CVE or VU# or GHSA etc. This needs to be discussed further too..

[ahouseholder]

After discussion, we've recognized a number of spinoff issues inherent to this PR. I think we should split this PR apart into smaller chunks to address those issues individually

• Need json schema for outcome groups #589
• Policy generator uses AUTOMATABLE_1, should be AUTOMATABLE_2 #590
• Consider adding a json schema to represent a policy #591
• We need a Policy object #592
• We need a schema for an array of decision point downselects #595
• JSON Schemas should be versioned #596

[ahouseholder]

I think we've already addressed the base issue #576 sufficiently, and the other issues in this PR were split up (see comments above). So I'm closing this PR as unmerged. Smaller chunks of it might still be relevant to future PRs of course.