To fail a pull request only on new vulnerabilities, compare the dependency set at the head of the branch with the base branch, then block on findings in packages the change adds or upgrades. Existing findings stay visible in a separate backlog instead of blocking unrelated work.
Why full scans make bad gates on old code
A full scan on a mature repository returns every known issue, including ones from years ago. If that result decides whether a typo fix can merge, developers learn to bypass the gate. A diff based gate asks a narrower question: did this change make things worse?
The GitHub dependency review action works this way. It looks at the dependencies a pull request introduces, compares base and head refs, and fails based on the severity you set. The base and head ref options exist for event types other than pull requests, such as a merge group or a push.
Steps to set it up
- Produce a dependency list for the base commit and the head commit.
- Compute the difference: added packages, and packages with a changed version.
- Look up advisories for the added and changed entries only.
- Fail the check if any finding meets your threshold.
- Run a separate scheduled scan of the whole repository and send results to a backlog, not to the merge button.
What a diff gate misses
| Situation | Caught by diff gate? | What catches it |
|---|---|---|
| A new dependency with a known flaw | Yes | The gate |
| A version bump that fixes one flaw and adds another | Yes | The gate |
| A new advisory published for a package already in use | No | Scheduled scan |
| A vulnerable transitive package pulled by an unchanged direct one | Depends on tool | Lockfile aware scan |
| Flaws in your own code | No | Code scanning |
The third row is the one teams forget. The diff is clean, the repository is not. This is why the scheduled scan in step 5 is part of the design and not an extra.
Keep the backlog honest
Report the old findings with an owner and a target date. If the backlog never shrinks, the diff gate has become a way to avoid the problem. A simple rule helps: every sprint, fix or formally except a fixed number of old findings, starting with those that are known to be exploited.
Try it yourself
Open the dependency inventory demo and look at how components, versions and findings relate. Think about which rows a pull request would add.
Click through it at your own pace, or open it full screen.
Safeguard's SBOM and dependency scanning can feed a merge gate for new findings, with policies you control. Start with the free scan at gold.safeguard.sh/scan to see the size of your existing backlog.
Quick check
Does a diff gate let old vulnerabilities live forever?
It can if nobody owns the backlog. Pair it with a scheduled full scan and a regular fix or exception review.
What if a pull request upgrades a package and the new version has a flaw?
A diff gate sees the changed version and checks it, so it will flag the new flaw.
Sources
Last reviewed: 19 October 2026.
