Follow-up thoughts from meeting today. This is mostly just to capture the points to make sure what was discussed during the call doesn't get lost, and also so that those that didn't make the meeting get the same context.
These are just the questions that came up surrounding how product information is captured in the JSON data. Of course other stuff was covered in the call.
Question: Does the JSON CSAF document capture product information, or are references via CPE/SWID/SPDX sufficient?
Conclusion from the call this morning seems to be universally, "yes, store product information in JSON". Scenarios that make this essential:
- when it is useful to have textual descriptions available for products for human consumption, in addition to CPE/SWID/SPDX.
- when a report wants to capture additional information about a product that isn't relevant to CPE/SWID/SPDX, such as platform / architecture / vendor attributes.
- when SWID/SPDX/CPE might not yet exist (brief aside - we were unable to identify on the call how to even register a CPE for a product).
- even if we pick one, as that is adopted, a new identifier will emerge, thus leading to scenarios where a product may have no identifier, the old one, or the new one. This may lead to scenarios where the appropriate identifier cannot be found, reinforcing the value of the current form of textual identification.
- open source projects may never dedicate the resources to properly identify their artifacts with any particular standard.
Next question: How should the JSON capture and refer to the product information in the JSON file?
The overall structure of the current CVRF document is document metadata, vulnerabilities, and product data. I believe we agreed on today's call:
- Product information in the JSON document will continue to be stored apart from vulnerabilities. This eliminates the need to repeat information about products, in cases where multiple vulnerabilities relating to the same product are reported in one JSON file.
- Once product information is stored separate from vulnerabilities, there's a need to reference it via a some identity.
- Product identity within the JSON will be guaranteed to be unique only within the scoped of the JSON document. (In contrast, note for example, that Cisco apparently uses identifiers that remain the same across CVRF documents, but that is out of scope.) There are two directions we can go here:
- Generated unique IDs
- Product labelÂ+ version #
Question:ÂHow does the JSON capture the product information?
The CVRF model defines an effective model of an entity as a modeled object with a product ID, plus a collection of properties. Examples of properties include product name, version number, vendor. In the simplest form, this could be stored in a de-normalized, flat manner in JSON - an array of entries, where each entry captures all the properties such as vendor, product family, product name, version number. Denormalizing has risks (changes in one place but not another), takes space, and probably adds confusion. We can take a few paths to renormalizing the data, all of which we discussed in the call:
- Group by hierarchical attributes - within the JSON document, perhaps all products are from the same vendor, in which case, a parent JSON object that defines the vendor would be sufficient. Likewise, a parent object for a particular product name might contain children for each version of the product. This works well for some attributes, but not others, such as cross-cutting concerns like "platform" or "architecture".
- Define sets of attributes that can then be referenced (this proposal in my previous email).
- Treat version numbers as special in some way
- A combination of the above three approaches
My proposal from the other day suggested using attribute sets, to the exclusion of hierarchical attribute declarations. I've had more thoughts on that. More on that in a separate email.
Question: How do we deal with product groups?
My somewhat glib answer to this question during the call was that this ends up being relatively simple, once we've defined the reference to a product. I still think that's true.
Eric