Add Product Specific CVSS Metrics

[silvafilipa]

We would like to suggest adding product specific metrics such as cvss score 3.1 and 4.0.
This would allow us to score/describe a vulnerability according to the way our products are actually affected.
We would propose that this information would be placed as a property of each affected entry. Naming would be x_metrics or just metrics, and it would have the same validations as the metrics already present for the cve.
We have also suggested this new property in the sadp pilot: CVEProject/sadp-pilot#13
Example:

   {
      "vendor":"XXXX",
      "product":"Product X",
      "versions":[
         {
            "status":"affected",
            "version":"0",
            "lessThan":"VX",
            "versionType":"custom"
         }
      ],
      "defaultStatus":"unknown",
      "x_metrics":[
         {
            "cvssV3_1":{
               "version":"3.1",
               "vectorString":"CVSS:3.0/AV:L/AC:H/PR:N/UI:R/S:C/C:L/I:L/A:L",
               "baseScore":5.2,
               "baseSeverity":"MEDIUM"
            }
         },
         {
            "cvssV4_0":{
               "version":"4.0",
               "vectorString":"CVSS:4.0/AV:A/AC:L/AT:P/PR:L/UI:A/VC:L/VI:N/VA:L/SC:H/SI:N/SA:L",
               "baseScore":2.0,
               "baseSeverity":"LOW"
            }
         }
      ]
   }
]

[sei-vsarvepalli]

We would like to suggest adding product specific metrics such as cvss score 3.1 and 4.0. This would allow us to score/describe a vulnerability according to the way our products are actually affected. We would propose that this information would be placed as a property of each affected entry. Naming would be x_metrics or just metrics, and it would have the same validations as the metrics already present for the cve. We have also suggested this new property in the sadp pilot: CVEProject/sadp-pilot#13 Example:

   {
      "vendor":"XXXX",
      "product":"Product X",
      "versions":[
         {
            "status":"affected",
            "version":"0",
            "lessThan":"VX",
            "versionType":"custom"
         }
      ],
      "defaultStatus":"unknown",
      "x_metrics":[
         {
            "cvssV3_1":{
               "version":"3.1",
               "vectorString":"CVSS:3.0/AV:L/AC:H/PR:N/UI:R/S:C/C:L/I:L/A:L",
               "baseScore":5.2,
               "baseSeverity":"MEDIUM"
            }
         },
         {
            "cvssV4_0":{
               "version":"4.0",
               "vectorString":"CVSS:4.0/AV:A/AC:L/AT:P/PR:L/UI:A/VC:L/VI:N/VA:L/SC:H/SI:N/SA:L",
               "baseScore":2.0,
               "baseSeverity":"LOW"
            }
         }
      ]
   }
]

Will different product have different baseSeverity score in your example for the same vulnerability? Can you share such an example so it is clear for the QWG to consider and discuss.

[silvafilipa]

Yes, here is an SSA from siemens where for the same CVE, three products have different CVSS scores: https://cert-portal.siemens.com/productcert/html/ssa-225840.html
See CVE-2024-22041

[darakian]

This makes intuitive sense to me and could be especially useful for cves for which the root vulnerability exists in a library.
ex. https://www.cve.org/CVERecord?id=CVE-2021-44228

I don't have an example on hand, but it seems within the realm of possibility that some org might ship two or more customer facing products which share an internal library and also use the shared library in different enough ways to meaningfully impact the severity. I guess this would move the metrics field to be a subordinate to an affect.

[nickleali]

Definitely something we have discussed in the CVSS SIG and a model we support.

https://www.first.org/cvss/v4.0/faq#What-are-best-practices-for-vulnerability-assessments-that-differ-depending-on-the-platform

Probably many ways on how the data should be represented in the JSON.

[ccoffin]

Another option might be to update the affected array to include a product identifier. For example, CSAF VEX documents allow you to define a product_id property for a set of products which then can be referenced later in the json when defining affected status and CVSS. See https://github.com/oasis-tcs/csaf/blob/master/csaf_2.0/examples/csaf/csaf_vex/2022-evd-uc-06-001.json. The upside of using a product identifier is that it could be useful in other parts of the schema as well, e.g., product specific solutions, references, etc.