In previous threads, I proposed the possibility that products should be identified by way of a "label" plus "version". I noted a minor issue with that due to the Cisco data using "service pack" in addition to product version, but I imagined that could be addressed.
In order to explore the feasibility of this approach, I wrote a program to consume existing cvrfdoc serialization, so that it could then be output as the CSAF JSON format. I have two cvrf documents to work from - one from Cisco, and the other from RedHat. I started with the Cisco one, and proposed a solution based on what I saw there. I should have looked at how the RedHat cvrfdoc looked as well.
A (slightly edited) snippet of the product tree:
  <Branch Type="Product Version" Name="ansible-asb-modules-0:0.1.1-1.el7">
   <FullProductName ProductID="ansible-asb-modules-0:0.1.1-1.el7">ansible-asb-modules-0.1.1-1.el7.src.rpm</FullProductName>
  </Branch>
  <Branch Type="Product Version" Name="ansible-kubernetes-modules-0:0.4.0-8.el7">
   <FullProductName ProductID="ansible-kubernetes-modules-0:0.4.0-8.el7">ansible-kubernetes-modules-0.4.0-8.el7.src.rpm</FullProductName>
  </Branch>
  ...
The above declares two products of a particular version. Note, however, that the "product version" of these products is "ansible-asb-modules-0:0.1.1-1.el7" or "ansible-kubernetes-modules-0:0.4.0-8.el7" - which also happens to be the product ID. I would be inclined to think that the product version would instead be something like "0:0.1.1-1.el7" or "0:0.4.0-8.el7". Oh, well.
Conclusion: The only anchor point in the model for migrating this to the CSAF JSON format is the ProductID attribute. Which means that the only way to faithfully convert this product representation is to make sure that the CSAF JSON document preserves the ProductID in some form, when the other necessary data (product name) is not available. Which means that identifying product instances by "product label"Â+ "version number" is not viable as the onlyÂoption based on current CVRF data. It could be used in addition toÂthe product id current supported by cvrfdoc.
One of my motivations has been the hope that the CSAF JSON document could be detailed enough that it could be a source document for generating the MITRE format data for CVEs. Looking at the RedHat CVRF document, it is now clear this isn't possible with an arbitrary version of the current CVRF specification. This is due to two limitations of CVRF format that I've identified so far:
- Product name, vendor, and version are not required
- Version ranges are not supported
Question:ÂDo we want the CSAF JSON format to be sufficient to generate the MITRE CVE data? If the answer to that question is yes, that moots my next question, as that would force the inclusion of vendor, name, and version.
Question:ÂDo we want the CSAF JSON format to be able to model the existing CVRF data (except for use of the xml:lang capabilities we've already addressed)? That is, is it possible to go CVRF --> JSON --> CVRF (and get equivalent output)? Note that the reverse JSON --> CVRF --> JSON (with equivalent output) will not be possible due to the likely enhancements of the JSON format, as well as the built-in extensibility of the JSON format.
The alternative to "yes", in this situation will require existing tools that generate CVRF to generate the eventual JSON documents using data from some other source.
And one last:
Question:Âdo we have a place where we're documenting the requirements of the JSON format?
Eric.
P.S. Happy New Year, all!