feature request: make products optional for a score

[jaccoNCSCNL]

According to section "3.2.3.13 Vulnerabilities Property - Scores" is products a mandatory property of the scores section of a vulnerability.
We notice however that (for instance) the NVD often publishes vulnerabilities with a CVSS score, but without products.

Thus, it is not possible to model the available data contained in that NVD vulnerability into a CSAF document.

We think that making products optional here would resolve this issue.

[tschmidtb51]

Thank you for your suggestion. As vulnerability does not exist without a product, I'm not convinced that this would be the right direction moving forward.

Can you point to an example?

[jaccoNCSCNL]

The one that I looked at yesterday was this one: https://nvd.nist.gov/vuln/detail/CVE-2024-4066

Here the CNA delivered a CVSS score that is shown by NVD. The CNA did not provide a CPE. Therefore there is no product in NVD's json.

Obviously there is a mention of a product in the description, so you are right in the statement that vulnerabilities always have a product associated. It is just that the structured form of the product might be added later.

[tschmidtb51]

The product is shown in the official CVE JSON:

"affected":[{"vendor":"Tenda","product":"AC8","versions":[{"version":"16.03.34.09","status":"affected"}]}]

I agree that their is no CPE - but that is not mandatory for CSAF. The data that is provided by the CVE JSON is sufficient to create a valid /product_tree:

  "product_tree": {
    "branches": [
      {
        "category": "vendor",
        "name": "Tenda",
        "branches": [
          {
            "name": "AC8",
            "category": "product_name",
            "branches": [
              {
                "name": "16.03.34.09",
                "category": "product_version",
                "product": {
                  "name": "Tenda AC8 16.03.34.09",
                  "product_id": "CSAFPID-0001"
                }
              }
            ]
          }
        ]
      }
    ]
  }

[jaccoNCSCNL]

I was looking at the NVD V2 Json: https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2024-4066
Here the "affected" section does not exist.

Thanks for pointing us to another source to include!

Over the weekend I was thinking about this issue. My conclusion was that your statement "vulnerabilities do not exist without products" should/could be reflected in "3.2.3.9 Vulnerabilities Property - Product Status".

You can now model a vulnerability in CSAF without products, but if you want to include a score to it, you do need a product.
On top of that, we do sometimes see different scores from different vendors/aggregators. We are under the impression that the differences are normally due to a different understanding of the vulnerability. It is - again in our experience - very seldom so that there are different scores for different products within one vulnerability.
The assumption "this score is relevant to all products in this vulnerability, unless explicitly stated otherwise" would normally work OK.

To summarize: I agree that vulnerabilities do not exist without products. I would not like products to be mandatory, because we often lack data. The link from scores to products is a strange method of making products mandatory. (IMHO)

[jaccoNCSCNL]

Researching into CVEProject, I came across this 2 year old item:
118955 CVE records don't have an affected product/vendor or version
CVEProject/cvelistV5#5

[jaccoNCSCNL]

Today we saw a vulnerability on a protocol rather than on a product: https://www.cve.org/CVERecord?id=CVE-2024-3661

[tschmidtb51]

That is not an issue as one can use the branch category specification which ends up as product. (Note: Everything in CSAF is a product 😉)

[santosomar]

During the CSAF TC monthly meeting on May 29, 2024, the TC discussed this issue and agreed that the current specification option under `3.1.2.2 Branches Type - Category' will address this use case.

https://docs.oasis-open.org/csaf/csaf/v2.0/os/csaf-v2.0-os.html#3122-branches-type---category

          "category": {
            "title": "Category of the branch",
            "description": "Describes the characteristics of the labeled branch.",
            "type": "string",
            "enum": [
              "architecture",
              "host_name",
              "language",
              "legacy",
              "patch_level",
              "product_family",
              "product_name",
              "product_version",
              "product_version_range",
              "service_pack",
              "specification",
              "vendor"
            ]
          },

[mprpic]

Perhaps a different take on this that supports the view of making the relationship to products optional: CVSS metrics (and the resulting score) communicate certain qualities of a vulnerability that can be used to determine whether an action should be taken or not. If a hypothetical security scanning tool processes a CSAF advisory file that contains information about fixed components, and detects that a component on the scanned system does not match the version of the fixed component in the CSAF file, it could present a choice to the user as to whether they want to update to the fixed one. At this point, the user should be provided with as much information about the vulnerability as possible to make the determination as to whether they should update. This includes CVSS metrics of any vulnerabilities addressed in the updated component.

But, according to the guidance in the spec, the relationship of a vulnerability to a product also affects the CVSS metrics even though a CVSS metric applies to the vulnerability, not a product. Presenting the user with a CVSS score of zero is less than useful in this scenario.

Disconnecting the mandatory relationship between products and CVSS metrics would allow the metrics to represent information about the vulnerability in general rather than making it specific to the product's status.