add support for CPE applicability statements

[ElectricNroff]

The 5.1 schema allows a cpes array defined as "Affected products defined by CPE" with additional explanation. Some enterprise vulnerability management efforts instead expect data to be composed of CPE applicability statements, either because the effort had been relying on NVD data directly or had been using private-sector tools that work with CPE applicability statements (the https://apidocs.emergingthreats.net website is one example). Also, suppliers that want to provide CPE information in CVE Records (as required by the https://www.cisa.gov/sites/default/files/2024-05/CISA%20Secure%20by%20Design%20Pledge_508c.pdf document) may be looking at the NVD JSON data for examples of how CPE has been used in the past to describe their products. In some cases, a CNA may be able to support CPE more quickly by working (by analogy) with NVD-authored CPE applicability statements, rather than by separating CPE information into multiple CVE Record fields. Also, such an approach may have a stronger internal business justification because the CNA's customers may already be set up to use CPE applicability statements directly during vulnerability scanning.

In other words, the suggestion is to allow CPE applicability statements directly in a to-be-determined property within a later 5.x schema.

Example of NVD JSON showing an AND relationship (Chrome is vulnerable only on Chrome OS in CVE-2023-0128):

      "description" : {
        "description_data" : [ {
          "lang" : "en",
          "value" : "Use after free in Overview Mode in Google Chrome on Chrome OS prior to 109.0.5414.74
                     allowed a remote attacker who convinced a user to engage in specific UI interactions to
                     potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)"
        } ]
      }
    },
    "configurations" : {
      "CVE_data_version" : "4.0",
      "nodes" : [ {
        "operator" : "AND",
        "children" : [ {
          "operator" : "OR",
          "children" : [ ],
          "cpe_match" : [ {
            "vulnerable" : true,
            "cpe23Uri" : "cpe:2.3:a:google:chrome:*:*:*:*:*:*:*:*",
            "versionEndExcluding" : "109.0.5414.74",
            "cpe_name" : [ ]
          } ]
        }, {
          "operator" : "OR",
          "children" : [ ],
          "cpe_match" : [ {
            "vulnerable" : false,
            "cpe23Uri" : "cpe:2.3:o:google:chrome_os:-:*:*:*:*:*:*:*",
            "cpe_name" : [ ]
          } ]
        } ],
        "cpe_match" : [ ]
      } ]
    }

In the CVE Record Format 5.1, one could add

platforms: [
   "ChromeOS"
]

and thiis would still be arguably machine readable. The problem is that platforms is simply a list of strings and cannot provide machine readability in anything beyond the simplest cases. For example, suppose the vulnerability only applies to Chrome running on ChromeOS versions 100 through 115. Would I write:

platforms: [
   "ChromeOS 110-115"
]

or

platforms: [
   "ChromeOS 110 through 115"
]

or maybe even:

platforms: [
   "ChromeOS version 110 lessThanOrEqual 115"
]

? Suppose the vulnerability only affects Chrome when used with ChromeOS on the x64-64 architecture (and not ChromeOS on ARM). Do I write:

platforms: [
   "ChromeOS",
   "x64-64"
]

or would that mean "Chrome is affected with ChromeOS running on any processor architecture, and also Chrome is affected on any x64-64 operating system"? In other words, the schema is ambiguous about whether the different strings in the platforms array should be interpreted as AND or OR (but the CVE Record examples imply OR).

Adding support for CPE applicability statements allows machine readability in a much wider variety of cases. Also, even if CPE isn't the best way to identify software, it is likely to be widely used for a while because of the CISA document above.