You can block vulnerable dependencies at pull request time with a required status check driven by a scanner and a written rule. Start in warn mode, move to blocking for the narrowest rule that matters, and give developers a documented exception path so the gate does not become a source of friction.
Four levels of enforcement
Inform. The scan posts a comment. Nothing blocks. Good for the first two weeks.
Warn with acknowledgement. The check passes but marks findings that need a reply. Builds habits without stopping work.
Block on a narrow rule. For example, fail on new critical vulnerabilities that have a fix and are reachable. Narrow rules keep the gate trusted.
Block broadly. Fail on any high or critical finding. Often too strict for existing code with a backlog.
Gate on new, not on existing
The most common mistake is failing every pull request because the repository already carries old findings. Compare against the base branch and block only on what the change introduces. Track the backlog separately.
Design the exception path
A gate with no exit gets bypassed in the worst way, such as admins disabling the check. Define:
- Who can approve an exception
- What reason is required
- How long it lasts
- Where it is recorded
Other rules worth considering
- Block packages with disallowed licences
- Block packages newer than a few days old, which gives time for malicious releases to be caught
- Block packages not in an approved list for sensitive services
Rollout plan
- Week 1 to 2: inform only, measure how many pull requests would fail.
- Week 3: warn.
- Week 4: block on the narrow rule.
- Review exceptions monthly and tune.
Communicating the gate
A gate that surprises people gets resented. Announce the rule, show the dry run results from the inform phase, and explain how to request an exception. Put the rule text in the message the check prints, so a developer who hits it sees what to do without searching a wiki. Measure time to resolve a failed check, because a gate that adds hours to every change will be bypassed.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at which finding triggers the gate and what the developer sees.
Where Safeguard fits
Safeguard supports policies, gates and guardrails, so a rule like the narrow one above can run as a pull request check. A free scan shows what a gate would catch on your code today.
Quick check
Should a gate block on every high severity finding?
Usually not at first. Block narrowly on new, fixable, reachable issues, then widen as the backlog shrinks.
Last reviewed: 19 October 2026.
