For most teams, gate on new findings introduced by the change, and manage the existing backlog separately with its own deadlines. Failing every pull request on old issues punishes authors for debt they did not create. Failing only on new issues stops the pile from growing without freezing delivery.
The problem with failing on everything
Turn on a scanner in a mature codebase and it will report hundreds of existing issues. If the gate fails on all of them, every pull request is red. People respond rationally: they bypass the check, or they ask for it to be switched off.
The ratchet approach
A ratchet only turns one way. The rule: this change must not make things worse.
- Take a baseline of current findings and mark them as known.
- On each pull request, compare against the baseline.
- Fail only on findings the change introduces, above a priority threshold.
- Work down the baseline on a schedule, and shrink it as items are fixed.
This puts the cost where it belongs. New code meets the new standard right away. Old code gets a plan.
Where a pure new only gate falls short
| Case | Why new only misses it | What to add |
|---|---|---|
| A new advisory is published on a package you already use | The pull request did not add it | Scheduled scans and alerts outside the pull request |
| A change touches a vulnerable file but does not fix it | It is already in the baseline | Optional rule: findings in touched lines must be fixed |
| Baseline never shrinks | It becomes a permanent exemption | A dated target and a report to the team |
The first row is the important one. A dependency can become vulnerable without anyone changing code. Continuous scanning on a schedule covers that case, and the gate covers the change.
Set rules for the backlog
Give old findings a separate service level based on priority, such as exploited issues first. Use known exploitation lists like CISA's KEV catalog and exploit probability scores like EPSS as inputs for ordering, alongside whether the code is reachable. Avoid sorting by severity alone.
Review the baseline monthly. If the count is flat for three months, either the target is unrealistic or the work is not being scheduled.
Try it yourself
Click through it at your own pace, or open it full screen. See how filtering to reachable findings shrinks the list you would have to gate on.
Safeguard's reachability analysis helps narrow which findings affect code that actually runs, and policies can gate pull requests on the result. The free scan shows a report for your project.
Quick check
Will developers game a new only gate?
Some may try to move code to avoid findings. Review the baseline and scan on a schedule, so moved or renamed code is still seen.
What threshold should block a merge?
Start with the highest priority only, such as known exploited issues or reachable critical findings, and tighten once the dispute rate is low.
Sources
Last reviewed: 19 October 2026.
