Roll a gate out in four stages: observe, warn, block on new Critical findings, then widen the threshold. Move on only when the false positive rate and the time to unblock are acceptable. Announce each stage in advance and keep a rollback switch.
The four stages
| Stage | Behaviour | Exit criteria |
|---|---|---|
| 1. Observe | Run, record, never fail | Results stable for two weeks, owners known |
| 2. Warn | Comment on pull requests, build passes | Developers can act on the messages |
| 3. Block new Critical | Fail only on new Critical findings | Few overrides, quick unblocks |
| 4. Widen | Add High, exploited or license rules | Backlog trending down |
Stage 1: observe
Run the gate on every repository and collect results. Do not tell developers it will block yet. You are measuring: how many findings per repository, how long the scan takes, how many are noise. Fix scanner configuration here, not later.
Stage 2: warn
Turn on pull request comments. Many tools have a warn-only mode. The GitHub dependency review action, for instance, has a warn-only option that logs vulnerabilities as warnings and lets the run succeed. It overrides the severity setting, so your threshold has no effect while it is on. That is useful in stage 2, but remember to switch it off.
Ask developers what confused them. Rewrite messages so each one says what failed, why, and how to fix or request an exemption.
Stage 3: block new Critical findings
Pick a narrow rule that nobody can argue with, such as new Critical findings in shipped dependencies. Pair it with a documented, fast exemption route. Publish an owner and a response time, for instance one business day.
Watch two numbers: how often the gate blocks, and how long a blocked developer waits. If waits are long, the gate is a tax and people will route around it.
Stage 4: widen
Add rules one at a time: a High threshold for new findings, a known exploited rule, license checks. Give a two week notice before each. Keep the stage 1 reporting running for the old backlog.
Rollback
Write down how to step back a stage, and who may do it. A gate you cannot turn down during an incident will be disabled in a panic, with no record.
Try it yourself
Open the gate demo and notice how each decision is shown to the developer. Ask whether your messages would be as clear.
Click through it at your own pace, or open it full screen.
Safeguard policies can be tuned per repository, which suits a staged rollout. Run the free scan at gold.safeguard.sh/scan as your stage 1 baseline.
Quick check
How long should stage 1 last?
Two to four weeks is common, enough to see a full release cycle. Shorten it for small repositories.
Do I roll out to every repository at once?
Start with a few willing teams, learn from them, then expand.
Sources
Last reviewed: 19 October 2026.
