No universal failure rate is right for security gates, so any single number you read elsewhere should not be your target. Judge your own rate with four checks: cause mix, trend, overrides and developer response. A rate is too high when most failures are not real findings or when people route around it.
Why a number alone fails
A gate on a codebase full of old debt might fail often and be doing exactly its job. A gate on a clean, small codebase might rarely fail and still be too lenient. The same rate can be healthy in one place and broken in another. What matters is why builds fail and what people do about it.
Four checks
1. Cause mix. Split failures by cause: real finding, policy, tool error, timeout, environment. If most failures are tool, timeout or environment, the rate is too high for reasons that have nothing to do with security. Fix those first.
2. Trend. A steady rate after a rollout is normal. A spike after a rule or scanner change suggests noise. A slow rise could mean growing risk or a creeping false positive problem, so read samples.
3. Overrides and bypasses. If overrides, skips and disabled jobs rise along with failures, the gate is being avoided. A high failure rate with few overrides and quick fixes usually means developers see it as fair.
4. Developer response. Look at re-run rate, time to unblock and survey answers. If failures are fixed quickly with few retries, the gate has trust. If failures sit, get retried or draw complaints, trust is low.
A simple decision table
| What you see | Reading | Next step |
|---|---|---|
| High failures, mostly real findings, fast fixes | Gate working, backlog being paid down | Keep going, watch age of findings |
| High failures, mostly noise | Gate too noisy | Tune rules, report-only first |
| Low failures, low coverage | Gate not seeing enough | Expand scope |
| Low failures, many skips or overrides | Gate being avoided | Examine skip rules and approvals |
| Rising failures after tool change | Change effect | Compare with change log |
Sampling beats arguing
Take twenty recent failures and read each. Ask: was it a real problem, was the message clear, and how long did it take to resolve? Doing this once a quarter gives you a grounded view that numbers cannot.
Tuning without weakening
- Gate on what a change introduces, not inherited debt, so developers are not blocked by problems they did not cause.
- Set blocking thresholds by risk, and warn on the rest.
- Use reachability and exploitability information where available to separate urgent from theoretical.
- Roll changes out in report-only mode first, then enforce.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how filtering by reachability changes the number of findings that would block a build.
Quick check
Is zero failures the goal?
No. Zero failures can mean the gate checks nothing. Aim for failures that are real, clear and quickly resolved.
Who should set the target?
Security and engineering together, based on your own data, and reviewed on a schedule.
How Safeguard fits
Safeguard provides reachability analysis, policies and gates, so blocking decisions can focus on findings that matter. A free scan is available at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
