A policy gate checks a pull request against written rules, such as no new critical findings or no banned packages, and then passes, warns or blocks the merge. Used well, gates stop new problems from entering code while leaving existing ones to be scheduled.
The parts of a gate
A gate has four pieces:
- A rule. A plain statement, for example "no new dependency with a known exploited vulnerability."
- A scope. Which repositories or branches it applies to.
- An action. Pass, warn, or block.
- An exception path. How a developer asks for an override, who approves, and when it expires.
If any of the four is vague, developers will experience the gate as arbitrary.
Warn first, block later
The usual rollout has three stages.
| Stage | Action | Purpose |
|---|---|---|
| Observe | Log only, no message | See how often the rule would fire |
| Warn | Comment on the pull request | Teach developers the rule |
| Block | Fail the check | Enforce once false alarms are rare |
Spend at least a few weeks in the first two stages. Check the log for rules that would have blocked legitimate work. Fix the rule, not the developers.
Rules that tend to work early
- New dependencies must not have a vulnerability that appears in the CISA KEV catalog.
- New dependencies must come from approved registries.
- Licenses on a deny list are blocked.
- A change must not lower an existing coverage threshold you have already agreed on.
Rules about existing findings are harder, because they punish developers for old debt. Keep gates focused on what the pull request introduces.
Design for the developer
- Say what failed and why, in the pull request itself.
- Link to the fix, such as the patched version.
- Keep the check fast. A gate that adds ten minutes will be bypassed.
- Make the override process quick, with a named approver.
Exceptions and expiry
Every exception should carry a reason, an owner and an end date. Review the list monthly. An exception with no end date is a permanent hole.
NIST's SSDF, SP 800-218, includes practices on verifying third party components and reviewing code before release. A gate is one way to make those practices repeatable, though you do not need to adopt the framework formally to use the idea.
Measuring a gate
Track how many pull requests it blocked, how many overrides were requested, and how long a blocked developer waited. If overrides are high, the rule is probably wrong or too broad.
A worked example: a banned package
Take a hypothetical rule: "No new dependency may appear in the CISA KEV catalog." Here is a pull request flow.
- A developer opens a pull request that adds a library.
- The gate resolves the library and its nested dependencies.
- One nested dependency has a known exploited vulnerability.
- The check fails with a message: which package, which advisory, and the patched version if one exists.
- The developer upgrades to the patched version and pushes.
- The check passes and the merge proceeds.
The whole loop takes minutes, and it happens where the developer already works. That is the main advantage of a gate: it moves the decision to the moment the change is cheapest to fix.
Step by step: introducing your first gate
- Pick one rule that is easy to explain, such as the one above.
- Run it in observe mode for two weeks and collect data on how often it would have fired.
- Review every would be failure. Was it a true problem, or a false alarm?
- Move to warn mode and announce it in the engineering channel, with the rule text and the exception process.
- After a few weeks of low false alarms, switch to block mode on a small set of repositories.
- Expand gradually, and review the override log monthly.
Rule categories to consider over time
| Category | Example rule | Difficulty |
|---|---|---|
| Dependency risk | No known exploited vulnerabilities in new packages | Easy |
| Source | Packages only from approved registries | Easy |
| License | Deny list of license types | Medium |
| Provenance | New packages must meet a minimum age or popularity | Harder |
| Existing debt | No increase in open high priority findings | Hardest |
Start at the top of the table and work down as your team gains confidence.
Handling emergencies
Sometimes a gate blocks an urgent fix. Define an emergency path in advance: a named approver reachable at short notice, a short form and a rule that every emergency override gets reviewed within a few days. Without it, developers will invent their own path, usually by disabling the check.
Communicating changes
Announce each new rule or change in advance, say what problem it solves and share the exception process. Developers tolerate rules they understand. They resent surprise failures.
Where Safeguard fits
Safeguard provides policies, gates and guardrails, plus autonomous remediation with fix PRs. That feature is off by default, and every category starts on Manual. A free scan is at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look at the message a developer receives when a rule fails.
Quick check
Should a gate block on every high severity finding?
Not at first. Start with narrow rules about what the pull request adds, and widen only when false alarms are rare.
Who approves an override?
A named person other than the requester, such as a team lead or security reviewer.
What if a gate slows down builds?
Measure the added time and set a target. If a check is too slow, run heavy analysis in parallel or on a schedule and keep only quick checks as blocking gates.
Sources
Last reviewed: 19 October 2026.
