Modify severity

[itaysk]

We're experimenting with OpenVEX in Aqua Trivy and trying to validate the use case for it (for VEX actually).
One thing that came up is that when a CVE analysis happens it's more common that the conclusion is modified severity and not binary "affected/non-affected" result. I think the goal of VEX is to improve the communication between different parties in the vulnerability assessment chain and in this case will you be open to accommodate this use case?

[itaysk]

coincidentally, I stumbled upon this article today: https://daniel.haxx.se/blog/2023/06/12/nvd-damage-continued/
In which curl's maintainer fights with NVD about the severity of a CVE in his software. If my suggestion is accepted, they can create an OpenVEX doc that simply ack the CVE (affected) but with a given severity.

[dlorenc]

I like this!

[luhring]

I love it... Would adjusting the "severity" imply possible adjustment of full CVSS analyses, too? E.g. if someone concluded that it was incorrect to cite a network attack vector

[itaysk]

I think metrics (e.g cvss) and severity goes hand in hand no?
If I had to suggest a basic implementation, I'd allow the VEX author to add their analysis however they prefer. the spec can clarify which type of analysis this is but not dictate the possible types. For example:

  {
      "vulnerability": "CVE-2023-12345",
      "products": [
        "pkg:apk/wolfi/product@1.23.0-r1?arch=armv7",
      ],
      "status": "affected",
      "analysis": [
        {
           "type": "cvss3.1",
           "value": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L"
        },
        {
           "type": "severity",
           "value": "HIGH"
        }
      ]
}

possibly the impact_statement belong here as well?

...
      "analysis": [
        {
           "type": "impact_statement",
           "value": "it's very unlikely that this code path is ever reach in normal circumstance"
        },
        {
           "type": "severity",
           "value": "LOW"
        }
      ]
}

[zmanion]

I read this issue and my first reaction was: VEX status (as defined today) has nothing to do with severity, CVSS or otherwise. A component is either affected or not_affected by a vulnerability. Yes, most of us want some futher severity, risk, or priority assessment, but that can and IMO should be elsewhere. I get concerned with what looks like every vulnerability-related format wanting to include all the other vulnerability information, which can lead to duplication, maintenance issues, and debt.

But after a few minutes of thought, I think the "modified severity" concept is important, although still not sure VEX is a good place for it. Severity should be applied to the closest upstream supply chain node to the person performing the security assessment.

• CVE 1 affects upstream libfoo, libfoo maintainers or NVD (or anyone) can provide severity, this assessment is more general because it's a library and can be used many ways.

• Product P uses libfoo. Maybe in a vulnerable way (VEX status affected), maybe not (VEX status not_affected). The owner of P can provide a severity assessment which is specific to P's use of libfoo. VEX status not_affected is still binary, CVSS 0.0, no vulnerability in P. But VEX status affected could carry a different (more specific) severity assessment (e.g., modified CVSS score).

I'm still mostly of the mind that there should be a security advisory for P with VEX, specific severity assessment, and other information relevant to CVE 1, P, and libfoo. The advisory can have CVSS, not VEX.

Lastly, I would not recommend burning too much time fighting about CVSS scores. Make a new one if you want, it's costly and of little impact to correct someone else's opinion. Also https://dl.acm.org/doi/10.1145/3491263 and https://resources.sei.cmu.edu/library/asset-view.cfm?assetID=538368.

[kcq]

This should be a no brainer to add. If there's any place where this info fits it's VEX :)

My recommendation would be to have the score vector and the score number. Obviously CVSS is not the only possible scoring framework (though the most commonly used). In my projects I use a "score" struct with these three fields: "type" (an enum representing the scoring framework), "data" (to hold the score number) and "context" (that's where the CVSS vector goes or it could be the text representation of the score for other scoring framework types that use numbers and names in their unique way).