Roll out gates in stages: run checks in advisory mode, tune with developers, then block only newly introduced severe issues, and widen later. Give every block a clear reason, a fast fix path and an exception route with an expiry. Developers accept gates they understand and can get past legitimately.
Why gates cause friction
A gate that blocks a release for a reason the developer cannot see or fix is experienced as an obstacle. A gate that blocks something real and says how to fix it is experienced as help. The difference is mostly rollout.
Four stages
| Stage | Behavior | Exit condition |
|---|---|---|
| 1. Advisory | Comment or status, no block | False positive rate is understood |
| 2. Tuned | Same, with agreed suppressions | Developers trust the output |
| 3. Block new severe | Fails only on newly added severe issues | Block rate is low and fixes are quick |
| 4. Widen | Add rules or severities | Backlog under control |
Design rules for a good gate
- Fast. Results should arrive before the review ends.
- Clear. The message names the rule, the file and the fix.
- Fair. Only block on what the change introduced.
- Escapable. An exception route with a named approver, a reason and an expiry.
- Visible. Publish rules in advance and announce changes.
Handling exceptions
Exceptions are not failure. They show the rule meets reality. Log each one with a reason and a review date. If the same exception recurs, fix the rule or the underlying issue.
Communicate early
Tell teams what is coming and when, ask for feedback during advisory mode and report what you changed because of it. A short note beats a surprise block on a Friday release.
Useful first rules
- A secret in the diff.
- A dependency with a known exploited vulnerability.
- A critical issue in code the change added.
CISA's Known Exploited Vulnerabilities catalog is a recognised source for the second rule, and CISA advises using it as an input to prioritization.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at the message a developer sees when a change fails. Ask if it names the rule and the fix.
Quick check
Should gates apply to old code?
Start with new issues only. Handle old debt through scheduled fixes so teams are not punished for the past.
What if developers keep requesting exceptions?
Review the rule. Repeated exceptions often point to a rule that is too broad or to a missing fix path.
Safeguard policies and gates can be set up to start lenient, and its guardrails and reachability analysis help keep blocks relevant. A free scan previews findings.
Sources
- CISA Known Exploited Vulnerabilities Catalog (cisa.gov). Paraphrased.
Last reviewed: 19 October 2026.
