[FEATURE]: Make VEX Ratings Actionable in CycloneDX Consumers

[fahedouch]

Describe the feature

Many CycloneDX VEX consumers (e.g Dependency-Track, Trivy..) consider only analysis.state (e.g., not_affected, exploitable, resolved) and ignore vulnerabilities[].ratings[] (e.g., CVSS, OWASP Risk Rating). Ratings carry essential exploitability and risk context and should be first-class inputs for prioritization.

Why this matters: ratings are especially important when analysis.state is exploitable or in_triage. In these cases, ratings (e.g., OWASP Risk Rating, CVSS) provide the precision needed to assess exploitability and prioritize remediation. VEX is currently the most effective community mechanism to exchange this information.

Request: Provide clear guidance or a mechanism in CycloneDX so that ratings are consistently interpreted and used by scanners alongside analysis.state.

Possible solutions

• Spec clarification: Normative language that consumers SHOULD/MUST consider ratings with analysis.state, with basic precedence guidance.
• Introduce new specification to exchange ratings: Vulnerability Rating Exchange (VRX)

Additional context

Observed behavior: tools often ignore OWASP/CVSS entries in VEX ratings.

Example intent:

{
  "vulnerabilities": [
    {
      "id": "DEBIAN-CVE-XXX",
      "ratings": [{ "method": "OWASP", "score": 5.0, "severity": "critical" }],
      "analysis": {
        "state": "in_triage",
        "detail": "Severity via OWASP Risk Rating (score 5.0 → critical)"
      }
    }
  ]
}

Questions

• Should ratings be normative inputs for prioritization in VEX consumers?
• Should we introduce a new specification for ratings exchange (VRX)?

[stevespringett]

Request: Provide clear guidance or a mechanism in CycloneDX so that ratings are consistently interpreted and used by scanners alongside analysis.state.

Ratings are commonly used in VDRs where you need to convey what is exploitable (1st and 3rd party code) and the severity and/or risk. VEX on the other hand, did not adopt this approach even though the group was presented with this as an option.

Additional normative language may be useful in future versions of the spec. I would support the use of the word "should".

Should ratings be normative inputs for prioritization in VEX consumers?

Yes, they should be. It is widely known that the NVD has historically overrated vulnerabilities (on purpose). So the ratings from the NVD and those from the manufactures are often different. CycloneDX can convey this information which can aid in prioritization.

Should we introduce a new specification for ratings exchange (VRX)?

No, VDR's typically always have this information. While the term "VDR" is relatively new-ish, there has been long standing requirements to share all known vulnerability information with specific types of customers - typically governments or critical infrastructure. I have never seem hard requirements on VEX (yet, and hopefully never will).

Why this matters: ratings are especially important when analysis.state is exploitable or in_triage. In these cases, ratings (e.g., OWASP Risk Rating, CVSS) provide the precision needed to assess exploitability and prioritize remediation. VEX is currently the most effective community mechanism to exchange this information.

Many tools do not have the ability to calculate risk, as that requires context the tool does not have. In the case of something not being exploitable, a tool could create its own CVSS vector that clearly states that there are no impact to confidentiality, integrity, or availability, and therefore the CVSS score would be 0.0.

[fahedouch]

Yes, they should be. It is widely known that the NVD has historically overrated vulnerabilities (on purpose). So the ratings from the NVD and those from the manufactures are often different. CycloneDX can convey this information which can aid in prioritization.

👍. I opened a PR to reflect this.

Many tools do not have the ability to calculate risk, as that requires context the tool does not have

We are working on a tool that helps gather context and make RBVM. We to share this contextual information with scanners and platforms like yours in a standardized way.