No. A 7.0 and a 6.9 differ by a tenth of a point, and the labels High and Medium only reflect where a line was drawn. Use bands to sort findings roughly, then separate them with exploit evidence, reachability and your own exposure rather than the label.
The bands
FIRST publishes the same qualitative scale for CVSS 3.1 and 4.0.
| Rating | Score range |
|---|---|
| None | 0.0 |
| Low | 0.1 to 3.9 |
| Medium | 4.0 to 6.9 |
| High | 7.0 to 8.9 |
| Critical | 9.0 to 10.0 |
The 4.0 specification notes that its boundaries were chosen to stay backwards compatible with the 3.x boundaries. So a label means the same range in both versions, even though the underlying metrics differ.
Why the edge cases mislead
A scanner dashboard counts findings by label. Move a threshold from 7.0 to 6.9 and a finding changes colour, yet nothing about the flaw changed. Teams that gate builds on "High and above" are making a policy decision at a hard line. That is fine if they know it. It is a trap if they believe the label measures danger.
Three effects follow.
- Findings just under a line get ignored in a backlog while findings just over it get urgent tickets. Ranking by band alone treats a 6.9 and a 2.0 alike, since both sit below High.
- Different tools may show different scores for the same flaw because they use different versions or sources. A GitHub-hosted advisory database, for instance, supports CVSS 3.1 and 4.0 and may carry 3.0 on imported records. One advisory can sit on either side of a line depending on the source.
- Base scores assume a reasonable worst case. The spec says they reflect intrinsic characteristics, not your environment.
A better sort order
Within each band, add information that CVSS does not carry.
- Is there evidence of exploitation in the wild?
- How likely is exploitation soon? EPSS gives a 0 to 1 probability of exploitation activity in the next 30 days, and FIRST states it is not a complete risk score.
- Does your code reach the vulnerable function?
- Is the component exposed to untrusted input?
A 6.9 with known exploitation and reachable code outranks a 7.5 in an unused test dependency. The band is where you start, not where you finish.
Setting thresholds you can defend
If you gate on severity, pick the cut deliberately and say why. Consider these choices.
- Gate on Critical only, and handle High through a time-bound backlog.
- Gate on High and above, but allow documented exceptions with an expiry date.
- Use the band as one input, and add an override for known exploited or reachable findings.
Whichever you pick, record that the line is a convention. When someone asks why a 6.9 shipped and a 7.0 did not, the answer should be your policy, not a surprise.
Reading ranges honestly in reports
When you report counts by band, show the trend and the exceptions. A bar chart of Highs hides the 6.9s and the reachable Mediums. If a manager asks "how many Highs", the honest answer includes "and here are the Mediums we are treating as urgent, and why".
Safeguard's policies, gates and guardrails let you combine severity with other signals when deciding what blocks a pull request, and a free scan is available at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. See how findings can be sorted by more than their label.
Quick check
Do CVSS 3.1 and 4.0 use the same severity bands?
Yes, both publish None 0.0, Low 0.1 to 3.9, Medium 4.0 to 6.9, High 7.0 to 8.9 and Critical 9.0 to 10.0.
Is EPSS a replacement for CVSS?
No. EPSS estimates the likelihood of exploitation in the next 30 days, while CVSS describes severity. FIRST says EPSS is not a complete risk score.
Sources
- FIRST, CVSS v3.1 Specification Document
- FIRST, CVSS v4.0 Specification Document
- FIRST, EPSS FAQ
- GitHub Docs, About the GitHub Advisory database
Last reviewed: 19 October 2026.
