. I've uncovered four design notes for discussion. This email discusses the first issue.
Please let me know if you have thoughts.
The first issue: Flipping the relationship between scores and lists of products.
Questions I have:
- Any problems with flipping the representation of the data model inside out? The new approach uses sets of product ids as primary, and CVSS scores secondary, rather than the current structure (which mirrors the XML approach) which puts the scores
as primary, and the sets of products as secondary.
- Any problems with the fact that this change means that round trip conversion of JSON --> XML --> JSON will, in some cases yield a different, but semantically equivalent result.
CVRF and CSAF associate product identifiers with specific scores. In the XML representation, an example instance might look like this (note that this is a bogus example snippet, I don't believe the scores are correct, for example):
Critical point is simply this - note how the ProductID element is adjacent to the details of the CVSS scoring. In the above example, the V2.0 score is associated with ProductA1, and the V3.0 score is associated with ProductB1.
In the initial cut of the JSON representation, we preserved this structure. However, that does not work if we adopt the CVSS schemas. Using the CVSS schemas, we can no longer put the product IDs adjacent to the CVSS scoring information, because
that portion of the schema is controlled by the
definitions. The products associated with the specific scores need to be in "objects" that wrap the specific scores. Here's the JSON example conversion of the above XML, using the new structure:
In the XML, a specific score (either V2 or V3) can be associated with an arbitrary list of products. In the JSON above, an arbitrary list of products is associated with CVSS scores - each of V2.0, V3.0, and V3.1 are allowed (cvss_v20, cvss_v30,
and cvss_v31 are sibling properties. This turns the model inside out a little bit.
This shouldn't be problematic, but it is worth noting that it is then possible in some cases that a round-trip JSON --> XML --> JSON will not yield the same JSON. It will yield the same meaning (specific versions of specific CVSS scores associated
with specific product IDs), but not the same JSON.
Why? Because the JSON structure is such that for a set of product ids, a CVSS V2.0, and V3.0 score can be assigned (a single object in the "scores" array). In the XML representation, this necessarily converts to a ScoreSetV2 and a ScoreSetV3 entry
in the XML. When converting these back, this will result in two objects under the "scores" array.
Also note as you may have inferred, adding CVSS3.1 scores was as simple as an additional property are supported in the proposed change to the JSON format. Obviously, those will not round-trip.
This new JSON representation for CSAF seems closer to an expected use case, as the natural use is to assign both a CVSS v2 and CVSS v3 score to a single set of products, not to associate a CVSS v2 score with one set of products, and a CVSS v3
score with another, as it is with the current CVRF XML format.