Feature: Option to use CVSS 4.0 for severity classification when available

[nitishtw]

Description

Summary

Add an option (e.g., a CLI flag or config) so Trivy can use CVSS 4.0 (when present) to determine the vulnerability Severity (Critical / High / Medium / Low), instead of always using CVSS 3.x (or the current logic).

Problem

Trivy already returns CVSS v4 score and vector in the scan response (#7968), but the Severity label is still derived from CVSS 3.x (or a single score from the chosen source). When a CVE has both CVSS 3.x and 4.0 in NVD, we only see the 3.x-driven severity.

Example

• CVE-2026-1229 (e.g. in github.com/cloudflare/circl):
  • NVD CVSS 3.x: 9.8 → Critical
  • NVD CVSS 4.0: 2.9 → Low
• Trivy (current): reports Critical

So the same CVE is scored once as Critical and once as Low, depending on which CVSS version you use. We want to base our gates and reporting on the 4.0 score (Low), but Trivy has no option to use CVSS 4.0 for severity, so we have to treat it as Critical or add it to .trivyignore. That’s the problem: a single CVE has two legitimate scores, and we cannot tell Trivy to use the 4.0 one for the Severity field.

• Inconsistent results between scanners
• False-positive "Critical" in Trivy when we want to align with CVSS 4.0
• Needing to add such CVEs to .trivyignore as a workaround

Proposed solution

Introduce a way to prefer CVSS 4.0 for severity when it exists, for example:

• Option A: A CLI flag, e.g., --vuln-cvss-version 4 (or prefer-v4), so severity is derived from CVSS 4.0 when available, otherwise fall back to current behavior.
• Option B: A config option (e.g., in trivy.yaml) with the same semantics.

When the option is not set, keep current behavior (no breaking change).

Why this matters

• NVD and others now publish CVSS 4.0; teams want to align with the newer standard.
• CVSS 4.0 often reflects more accurate, contextual scoring and reduces noisy "Critical" findings where 4.0 is Low.
• Today, the only workaround is to ignore those CVEs (e.g. in .trivyignore), which is opaque and hard to maintain.

References

• CVSS v4 in scan response: #7968
• CVSS 4.0 discussion: #5404, #4586
• NVD CVSS 4.0 support: https://www.nist.gov/itl/nvd/nvd-news

Target

Container Image

Scanner

Vulnerability

[yusuke-koyoshi]

I'd like to add an important concern about the data quality of CVSS 4.0 scores sourced from GHSA, which is directly relevant to the example cited here.
The CVSS 4.0 score of 2.9 (Low) for CVE-2026-1229 is likely underestimated.
The current GHSA vector for this CVE is:
CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:L/SI:L/SA:L/E:P/S:N/AU:Y/U:Amber

It includes E:P (Exploit Maturity: Proof-of-Concept), which is a Threat Metric. Threat Metrics are designed to reflect the current threat landscape and are intended to be updated over time. However, GHSA does not have a process to continuously update Threat Metrics after initial publication. A stale E:P value will suppress the Base score indefinitely, resulting in a misleadingly low severity.
Furthermore, GHSA's advisory submission form and UI do not expose Threat Metrics (CVSS v4) or Temporal Score Metrics (CVSS v3) to reporters. This strongly suggests that these values are being introduced unintentionally — likely injected automatically during advisory processing — and were never intended to be part of the published score.