Most teams start by failing a CI build on High and Critical findings, meaning a CVSS base score of 7.0 or above, and warning on the rest. That is a sensible first threshold, not a final one. Tighten it over time and add context so the gate blocks real risk.
What the CVSS bands actually are
CVSS 3.1 defines a qualitative scale. Your gate threshold is a choice about where on this scale a build stops.
| 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 specification says the base score reflects intrinsic severity and that consumers should supplement it with temporal and environmental scores. Things like customer counts or breach losses are outside CVSS and belong in a separate prioritisation process. A threshold is therefore a blunt first filter, nothing more.
How to pick your first threshold
- Count your current findings at each band on your main branch.
- Pick the lowest band where the count is small enough that a team can clear it in a sprint.
- Set the gate to fail at that band for new code, and warn below it.
- Review monthly and lower the bar one band at a time.
If you have 400 High findings today, a gate set to High will fail every build and get disabled within a week. A gate set to Critical that is still enforced beats a High gate that was switched off.
Know what your tool's threshold flag really does
Tools differ. The npm audit command, for instance, documents its audit level as the minimum level for a non-zero exit code, and states that it does not filter the report output. The findings still print. Only the exit code changes. The GitHub dependency review action lets you set a minimum severity of low, moderate, high or critical, and defaults to low, which is strict.
Check the default before you assume you have a lenient gate.
Why severity alone is not enough
A High finding in a test helper that never ships is not the same as a High finding in an internet facing service. Two signals help:
- Is the vulnerable code reachable from your code?
- Is the flaw known to be exploited?
Gating on those, covered in other posts in this series, cuts noise without lowering the bar for real risk.
Try it yourself
Open the demo and watch how a pull request gate treats findings at different severities. Notice which ones block and which only warn.
Click through it at your own pace, or open it full screen.
Safeguard policies and gates can block merges on severity thresholds that you configure, and its dependency scanning feeds them. You can run a free scan at gold.safeguard.sh/scan to see your own counts per band.
Quick check
Is failing on Critical only too lenient?
It is a fine starting point if your backlog is large. Treat it as stage one, and move to High for new findings once the backlog is under control.
Does a Medium finding ever deserve a block?
Yes, if it is known to be exploited or reachable in a sensitive service. That is a context rule layered on top of severity.
Sources
- FIRST, CVSS v3.1 specification document
- npm documentation, npm audit
- GitHub, dependency review action
Last reviewed: 19 October 2026.
