The JSON for "other" (SSVC) "options" is not succinct json

[jayjacobs]

This is purely a suggestion, but the way data is stored in the "containers.adp.metrics.other.content.options" is suboptimal. All of the records at the time I created this issue are encoded this way, but I will use CVE-2007-3484 as an example.

The current encoding looks like this:

                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],

Right now there is only one value in the "options" array across the 6500 or so CVEs so that could just be a json object instead of array, but maybe you want future expansion. However, the separation of the three key-values into their own object is unnecessary and could be simplified to look like this:

                "options": [
                  {
                    "Exploitation": "none",
                    "Automatable": "no",
                    "Technical Impact": "partial"
                  }
                ],

The current method causes some headache when flattening the JSON since it treats each of those objects as unique array entries and the missing keys as unset values:

 options_id Exploitation Automatable `Technical Impact`
          1 none         NA          NA                
          2 NA           no          NA                
          3 NA           NA          partial           

But like I mentioned, you only ever have one array entry currently, so the whole thing could just be a single object (but your schema would have to be updated, since it allows for .* as a string or an array):

                "options":  {
                  "Exploitation": "none",
                  "Automatable": "no",
                  "Technical Impact": "partial"
                }

And if you don't need the array in options, you could copy the way CVSS data is encoded and just drop the whole "options" section and just have keys for the three SSVC values:

              "content": {
                "id": "CVE-2007-3484",
                "role": "CISA Coordinator",
                "Exploitation": "none",
                "Automatable": "no",
                "Technical Impact": "partial",
                "version": "2.0.3",
                "timestamp": "2024-05-24T19:33:37.182425Z"
              }

which would make the SSVC content simple and not nested JSON.

[jwoytek-cisa]

@jayjacobs and @todb-cisa the schema used inside the SSVC metrics object follows the SSVC JSON schema (example). We don't define that, but wanted to use existing standards where applicable.

[jayjacobs]

I opened a related issue in SSVC, fixing this would make it much easier to parse into structured data.

Plus, If I'm reading the SSVC schema correctly, the options is required to be an array of objects, but the object can be any names but must be either a string or array (FYI to JSON creators: having both as an option makes parsing out structured data a challenge).

Therefore, this options object should validate against the schema (I think):

                "options": [
                  {
                    "Exploitation": "none",
                    "Automatable": "no",
                    "Technical Impact": "partial"
                  }
                ],

[todb-cisa]

Near as I can tell, this is blocked by CERTCC/SSVC#576

[todb-cisa]

Still blocked by CERTCC/SSVC#576

[todb-cisa]

I have thoughts. BRB.

[ahouseholder]

AFAICT, the JSON fragment used in vulnrichment for SSVC decision point values doesn't validate against any current schema in SSVC. It's a fragment of a valid JSON object, but there's no standalone schema to verify it. We've created CERTCC/SSVC#595 to create a schema to represent a downselect from a list of decision points. That issue includes some requirements for SSVC that aren't represented in any of our existing schemas as well (decision point namespacing and versioning was added after the SSVC computed schema, for example). So there is a bit of engineering we're working through to sort this out. We'd be happy to have further discussion on that in CERTCC/SSVC#595 or any subsequent PRs.

A number of other issues have spawned out of CERTCC/SSVC#576, so I think CERTCC/SSVC#595 is more focused specifically on how to represent a list of selected values.

[ahouseholder]

We've merged CERTCC/SSVC#599 which resolves CERTCC/SSVC#595. We're interested to have CISA's feedback on any subsequent implementation concerns.