Add mandatory test: CPE vs. `product_version_range`

[tschmidtb51]

Currently, I see a lot of files that use the following structure:

  "product_tree" : {
    "branches" : [ {
      "branches" : [ {
        "branches" : [ {
          "category" : "product_version_range",
          "name" : "<47.11",
          "product" : {
            "name" : "Example Company Product A < 47.11",
            "product_id" : "CSAFPID-0001",
            "product_identification_helper" : {
              "cpe" : "cpe:/o:example:product_a:47.11"
            }
          }
        } ],
        "category" : "product_name",
        "name" : "Product A"
      } ],
      "category" : "vendor",
      "name" : "Example Company"
    } ]
  },

This is misleading in the matching as the cpe does not reflect what is given by the categorized strings in branches. In fact, there is only one situation where the combination of product_version_range and cpe is valid:

  "product_tree" : {
    "branches" : [ {
      "branches" : [ {
        "branches" : [ {
          "category" : "product_version_range",
          "name" : "vers:all/*",
          "product" : {
            "name" : "Example Company Product A - all versions",
            "product_id" : "CSAFPID-0001",
            "product_identification_helper" : {
              "cpe" : "cpe:/o:example:product_a:*"
            }
          }
        } ],
        "category" : "product_name",
        "name" : "Product A"
      } ],
      "category" : "vendor",
      "name" : "Example Company"
    } ]
  },

Therefore, I suggest to add a mandatory test to prevent this mistake.

[tschmidtb51]

6.1.X Combination of product version range with CPE

For each path in branches that contains an object with category of product_version_range it MUST be tested that the product_identification_helper has no cpe. If the cpe object is present, the value of the name in the product version range MUST be vers:all/*.

The relevant paths for this test are:

  /product_tree/branches[]

Example 1 which fails the test:

  "product_tree" : {
    "branches" : [ {
      "branches" : [ {
        "branches" : [ {
          "category" : "product_version_range",
          "name" : "<47.11",
          "product" : {
            "name" : "Example Company Product A < 47.11",
            "product_id" : "CSAFPID-0001",
            "product_identification_helper" : {
              "cpe" : "cpe:/o:example:product_a:47.11"
            }
          }
        } ],
        "category" : "product_name",
        "name" : "Product A"
      } ],
      "category" : "vendor",
      "name" : "Example Company"
    } ]
  },

A cpe was defined for a product version range.

[tschmidtb51]

Maybe, we can simplify the description a bit... Feedback welcome.

[tschmidtb51]

Checklist:

• [ ] Add test
• [ ] Add valid test files
• [ ] Add invalid test files
• [ ] Add conversion rule

[santosomar]

Ensuring the accuracy of CPEs is definitely important for effective product identification and vulnerability management. I understand your concern that the current structure might lead to misleading matches.

Implementing a mandatory test to validate the consistency between the product_version_range and CPE is a prudent step. However, it's important to consider that not all vendors or suppliers might support or use CPE. In such cases, enforcing a mandatory CPE validation could introduce challenges and potentially exclude some valid product information. To address this, I propose the following:

• Conditional Validation: Make the CPE validation test mandatory only if CPE information is provided. This allows flexibility for those who do not use CPE while maintaining strict validation for those who do.
• Alternative Identification Methods: Encourage the use of other identification methods for vendors/suppliers who do not support CPE. As a separate effort, we (industry) should provide clear guidelines and examples in the documentation to help vendors and suppliers understand how to structure their product information accurately, whether they use CPE or not.

[tschmidtb51]

@santosomar

• Conditional Validation: Make the CPE validation test mandatory only if CPE information is provided. This allows flexibility for those who do not use CPE while maintaining strict validation for those who do.

This is considered in the text as the test fails only if a product_version_range (that is not vers:all/*) was used and a cpe was given.

• Alternative Identification Methods: Encourage the use of other identification methods for vendors/suppliers who do not support CPE. As a separate effort, we (industry) should provide clear guidelines and examples in the documentation to help vendors and suppliers understand how to structure their product information accurately, whether they use CPE or not.

Parts of this are already implemented into CSAF 2.0 with the optional test 6.2.16. However, example and guidance are still missing. If you think that is important, feel free to split up into a separate issue.