Closed sei-vsarvepalli closed 3 weeks ago
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.
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
, andvalues
properties from the DP schema but only includes thename
(s) of the chosenvalues
. Note thatdescription
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.
Some more issues to be concerned about
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..
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.
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.
https://github.com/cisagov/vulnrichment/issues/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.