Add Product Specific CVSS Metrics #486

Activity

1. github-project-automation

   added this to QWG Work Boardon Jun 8, 2026
2. sei-vsarvepalli commented on Jun 8, 2026

   

   sei-vsarvepalli

   on Jun 8, 2026

   Contributor

   More actions

   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.
3. silvafilipa commented on Jun 9, 2026

   

   silvafilipa

   on Jun 9, 2026

   Author

   More actions

   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
4. darakian commented on Jun 24, 2026

   

   darakian

   on Jun 24, 2026

   Contributor

   More actions

   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.
5. nickleali commented on Jul 16, 2026

   

   nickleali

   on Jul 16, 2026

   More actions

   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.
6. ccoffin commented on Jul 22, 2026

   

   ccoffin

   on Jul 22, 2026

   Collaborator

   More actions

   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.