Roll a security gate out in phases: report only, warn on new findings, then block on a narrow, high confidence rule. Gate on what a pull request introduces, not on the whole backlog, and give developers a fast, owned exception path. A gate people route around protects nothing.
Why gates fail
The usual story is a team switches on a scanner in blocking mode on day one. Every pull request fails on old findings nobody caused. Developers learn the gate is noise, someone adds a bypass, and the bypass becomes the process.
The fix is not a weaker tool. It is a better rollout.
Phase one: observe
Run the scan on every pull request and the default branch, but do not block. Publish the results where developers already look, such as a pull request comment.
Goals for this phase, which might last two to four weeks:
- learn the baseline: how many findings exist today,
- measure how long the scan takes,
- find false positives and tune them out,
- confirm every repository can run it.
Phase two: warn on new findings only
Separate old from new. A finding that exists on the target branch is backlog. A finding the pull request introduces is the author's to fix.
Show only new findings in the pull request. Track the backlog separately with owners and dates. This single choice removes most of the resentment.
Phase three: block narrowly
Pick a rule that is both important and reliable. Examples of sensible first blocks:
- a newly added dependency with a known critical vulnerability that has a fix available,
- a committed credential,
- a dependency pulled from an unexpected source.
Whether a vulnerable function is actually reachable from your code is a useful filter here, since it separates urgent from theoretical. The reachability demo shows the idea.
Click through it at your own pace, or open it full screen.
Expand the blocking set slowly, one rule per month.
The exception path
Every gate needs one. Write it down:
- The developer requests an exception in the pull request, with a reason.
- A named owner approves or declines within one business day.
- Exceptions carry an expiry date.
- A weekly list of open exceptions goes to the team lead.
An exception with no expiry is a permanent hole.
Keep it fast
If the gate takes ten minutes, people will push less often or batch changes. Aim for a few minutes. Run slow checks on merge or nightly, and keep the pull request gate for fast ones.
Protect the gate itself
If anyone can edit the pipeline file, they can remove the gate. Put workflow files under code owner review, and make the gate a required status check in branch rules or GitLab protected branches.
Measure
Track three numbers: median time to fix a blocked pull request, exceptions requested per month, and the share of blocks later judged false positives. If the third is high, tune the rule before widening it.
Safeguard policies, gates and guardrails support this staged approach, and the free scan at gold.safeguard.sh/scan lets you see your baseline first.
Quick check
Should the gate block on every high severity finding?
Not at first. Start with new, fixable, high confidence issues and widen from there.
How long should the observe phase last?
Long enough to learn the baseline and tune false positives. Two to four weeks is a reasonable guess for most teams.
Last reviewed: 19 October 2026.
