Add configuration_tree

[tschmidtb51]

Regarding the required configuration: This is a very good point. However, I think that it should not be part of the vulnerability section. To me that should be addressed somewhere else, e.g. the product_tree or a new sibling property configuration_tree. This would allow to form a new product_id which than can be referenced in multiple fields across the vulnerability section. See example:

  "product_tree": {
    "branches": [
     // ...
                    "name": "C.D",
                    "type": "product_version",
                    "product": {
                      "product_id": "CSAFPID-0001",
                      "name": "Example Company Family A Product B C.D"
                    }
    ],
     // ...
    "configurations": [
      {
        "full_product_name": {
          "name": "Example Company Family A Product B C.D with configuration E",
          "product_id": "CSAFPID-0002"
        },
        "product_reference": "CSAFPID-0001",
        "relates_to_configuration_reference": "CSAFCID-0002",
        "relationship_type": "installed_with"
      }
    ],
     // ...
   },
   "configurations": [
     // ...
    {
       "configuration_id": "CSAFCID-0002",
       "name": "Configuration E",
       "type": "user"
       // other configuration information here
     }

I remember that configuration management is not an easy task - are there any standard that we can refer to?

Originally posted by @tschmidtb51 in #186 (comment)

[tschmidtb51]

[...]

With regard to the configuration_tree: I am totally in favor of a new property which can be referenced elsewhere in the document. Your point regarding configuration types makes sense to me as well-- thanks for explaining that. I'm still stuck on the unified-configuration-model point. We don't really want to just push raw config in here since that won't make much sense to a system reading the JSON file, and we could make the argument that such text is executable content and therefore should be omitted from the JSON file, period. The sheer number of devices to which CSAF will be applicable, combined with the number of competing configuration standards results in a huge potential matrix. We need to specify just enough detail to allow a human operator to determine which configuration applies to them and how to apply it.

I think the best way to accomplish this may be to make the configurations entry discussed here, named "CSAFCID-0002", contain a references_t object which points to configuration as provided (ideally with instructions for using said config) by the issuing authority.

Thoughts? Again, apologies for the time-delay since my last participation here.

Originally posted by @wrideout in #186 (comment)