Track five numbers: block rate, override rate, time to clear a block, waiver age, and findings discovered after release. Read them together. A working gate blocks the right things, is rarely bypassed, clears quickly and leaves few surprises in production.
The five metrics
| Metric | What it shows | Warning sign |
|---|---|---|
| Block rate | Share of releases the gate stops | Near zero for months, or very high |
| Override rate | Share of blocks bypassed | Rising steadily |
| Time to clear a block | Hours from fail to pass | Growing, which means teams are stuck |
| Waiver age | Days since each open waiver was created | Waivers past expiry |
| Post-release findings | Findings on shipped releases that the gate could have caught | Repeated misses |
No single number works alone. A low block rate could mean good code or a blind gate. A high override rate could mean a broken rule or a pressured team.
How to read them
- Block rate near zero. Run the gate test described elsewhere in this series, and check the scope. It may be scanning the wrong thing.
- High block rate. Look at what rules fire. A few noisy rules usually cause most blocks. Tune them with review.
- Rising overrides. Talk to the teams. The fix path may be slow or the rule unclear.
- Long clearing time. Look for missing fix guidance or slow approvals.
- Old waivers. Escalate to the risk owners. Expired waivers should fail the gate.
- Post-release misses. Ask whether the data was stale, the scope was wrong, or the finding was new after release.
Avoid vanity numbers
Total vulnerabilities found is a poor measure, because it rises when you scan more and says nothing about control quality. The same goes for raw counts of scans run. Prefer rates and ages, which describe behavior.
Put numbers beside context
The EPSS score and the CISA KEV catalog change over time, so a metric like "known exploited findings in released versions" moves for reasons outside your control. Note that when you present it, so nobody reads a rise as team failure.
Report to the right people
Engineering leads need block and clearing time by team. The risk owner needs waiver age and overrides. Auditors need the evidence trail. One dashboard rarely serves all three, so build small views for each.
Review cadence
Look monthly, and after any incident involving a shipped release. Record what you changed and why, as a policy change with review.
Quick check
What is a good block rate?
There is no universal target. Look at trend and cause, and compare against override rate and post-release findings.
Should we publish these numbers to teams?
Yes, by team, framed as support rather than ranking. Visibility tends to shorten clearing time.
Sources
Safeguard offers policies, gates and dependency scanning, and a free scan is available at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
