Run a dependency scan on every pull request, make it a required status check, and define a rule for what fails: for example a new critical finding that is reachable, or anything on the exploited list. Pair the rule with an exception path, or developers will route around the gate.
What a gate is
A gate is an automated pass or fail decision in the merge path. The scan produces findings. The policy turns findings into a verdict. The required check makes the verdict binding.
Choose a rule you can defend
| Rule | Blocks | Trade off |
|---|---|---|
| Any finding | Everything, including old issues | Teams stall and add bypasses |
| New findings only | Problems this pull request introduces | Old debt stays, but flow continues |
| New critical or high | Serious additions | Misses medium issues that chain |
| New and reachable | Findings in code that can be called | Needs reachability data you trust |
| Exploited list match | Known exploited flaws | Narrow, low noise, easy to explain |
Most teams start with new findings only plus an exploited list match, then tightening over time.
Steps
- Pick the scanner and run it in CI on the pull request branch, scanning the manifest or lockfile diff.
- Compare against the base branch so the result shows only what the pull request adds.
- Write the rule in a policy file under version control, not in a scanner setting nobody reviews.
- Configure the check as required in branch protection.
- Show failures where developers already look: a comment on the pull request with package, version, fixed version and the reason it failed.
- Define the exception path: a documented request, an approver, an expiry date.
- Decide what happens if the scanner is down. Fail closed for critical repositories, fail open with an alert for the rest, and write the choice down.
Tuning
Measure how often the gate fires, how often the fix is a one line upgrade, and how often exceptions are requested. A gate that blocks daily with no clear fix will be disabled by someone eventually.
Try it yourself
Open the demo, introduce a vulnerable package in the sample pull request, and watch the verdict and the message the developer sees.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard provides policies, gates and guardrails that evaluate findings on pull requests, with reachability analysis to separate callable issues from the rest. Try a free scan to see findings before you set a rule.
Quick check
Should a gate block on existing vulnerabilities?
Usually not at first. Block on what the change introduces and manage the existing backlog separately, or the gate becomes a wall.
What if there is no fixed version?
Offer an exception with an expiry and a mitigation note, or require replacing the package. Do not leave the developer stuck with no option.
Sources
- CISA Known Exploited Vulnerabilities Catalog (feed formats and use as a prioritisation input).
- OSV schema, ossf.github.io/osv-schema (fixed versions in advisories).
Last reviewed: 19 October 2026.
