Modify severity

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?

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.

I like this!

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

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"
        }
      ]
}

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.

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).

Hi, are there any updates on this issue?
I recently opened a proposal that could be related to this one.
The point in my case is that a vulnerability could be partially affected due to the reduced attack surface offered by the infrastructure on which the application is running.
I leave the link to the issue here, if anyone is interested: #61

Speaking from SUSE's Rancher Security team here, as we rely heavily on automated and manual VEXing of CVEs (hundreds per week) and provide our own VEX Hub (following Trivy's spec) in rancher/vexhub, for us it would be very important if we could add a severity re-scoring information inside a VEX statement. This is a similar ask like #60.

By using the VEX report, that is already supported by multiple security scanners, a vendor doesn't need to provide its own CVE database (in CSAF, CVRF, OVAL etc.) and integrate it with each security scanner just to re-score CVEs. This is important, because a lot of CVEs tend to be overrated or simply have a lower severity depending on the affected product and context.

This is also useful for security teams and end-user consumers that can have the ability to easily re-score CVEs on their own environments following a standard spec.

I believe that a CVSS re-scoring is allowed according to the main VEX specification from NTIA.

We (myself) can commit to help writing the extension to the spec and then help integrate it in Trivy and Grype.

PS: Personally we prefer to use OpenVEX for this, instead of other specs (CSAF-VEX, CycloneDX etc.), because OpenVEX is more concise, simpler and less complex, and human editable/readable. Essentially, OpenVEX rules!

This would be especially helpful for CVEs like CVE-2026-68121 which was scored a 10.0 from NVD but a 4.8 by CISA

@puerco

Hi @puerco. We went ahead and drafted an OPEV for adding vulnerability score data. If you want to take a look, please see https://github.com/macedogm/fork-openvex-community/blob/opev-0016/enhancements/opev-0016.md. Perhaps this can be used as the base for this enhancement. If you agree, I'm happy to open a PR with the doc.

Great to see OpenVEX moving toward supporting severity re-scoring in VEX statements.

On my side, I’m pushing adoption by working on consumer support across tools: Trivy discussion, Grype issue and Dependency-Track issue.

Trivy maintainers explicitly asked for more community demand before adding VEX ratings, so having a clear OpenVEX way to express these ratings (and more tools consuming them) will help unblock implementation.

Please see the proposal for what we have been discussing here - openvex/community#24.

Navigation Menu

Repository navigation

Modify severity #31

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Modify severity #31

Description

Activity

itaysk commented on Jun 22, 2023

dlorenc commented on Jun 22, 2023

luhring commented on Jun 22, 2023

itaysk commented on Jun 22, 2023

zmanion commented on Jul 10, 2023

kcq commented on Nov 6, 2023

alegrey91 commented on Jan 14, 2026

macedogm commented on Mar 12, 2026

cwayne18 commented on Mar 12, 2026

macedogm commented on Mar 19, 2026

fahedouch commented on Mar 19, 2026

macedogm commented on Apr 13, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions