A pull request dependency check sees the change itself: which packages were added, removed or updated, including indirect ones in lock files. A nightly scan sees only the resulting state. The first tells you what a change introduced and can block it. The second tells you what is there after the fact.
Two different questions
A nightly scan asks: what is in the default branch right now, and does any of it have a known problem? A pull request check asks: what does this change add or alter, and is any of that a problem?
The difference sounds small, but it changes what you can do with the answer.
What the diff view adds
GitHub's documentation describes dependency review as showing which dependencies were added, removed or updated, with release dates, how many projects use them, and vulnerability data. It includes changes to indirect dependencies in lock files. It also notes a common surprise: updating one direct dependency can pull in updated dependencies of its own, so a pull request can contain more change than expected.
That last point is the heart of it. Reviewers cannot see transitive changes by reading a manifest diff. A tool that expands them does the reading for you.
Side by side
| Aspect | Pull request check | Nightly scan |
|---|---|---|
| Timing | Before merge | After merge, on a schedule |
| Output | Changes introduced by this PR | Everything currently present |
| Can block | Yes, as a required check | No, it reports |
| Catches new advisories on old packages | No | Yes |
| Attribution | Points to the change and author | Points to the repository |
| Noise | Low, scoped to the diff | Higher, includes the backlog |
Why you want both
They cover opposite weaknesses. The pull request check stops new problems at the door but is blind to anything published later about packages already accepted. The nightly scan sees those later advisories but cannot stop anything. GitHub's own text makes this point: it says Dependabot alerts find vulnerabilities already in your dependencies, while it is much better to avoid introducing problems than to fix them later.
How to set the pull request check up well
- Make it a required check on the protected branch. GitHub's action fails by default when it finds vulnerable packages, and that only blocks a merge if the check is required.
- Scope it to the diff so existing debt does not block unrelated work.
- Decide how to handle licences too, if your policy covers them.
- Add an exception path with an expiry date.
- Keep the nightly scan for the backlog and for new advisories.
Try it yourself
Click through it at your own pace, or open it full screen. Notice that the gate looks at the change, not the whole repository.
Where Safeguard fits
Safeguard provides dependency scanning with policies and gates that can block a pull request, plus a free scan at gold.safeguard.sh/scan.
Quick check
Will a pull request check find old vulnerable packages?
Only if the pull request touches them. Old packages need a scheduled scan of the whole branch.
Does the check see transitive dependencies?
GitHub's dependency review includes indirect dependencies when they appear in a lock file change. Without a lock file, you see far less.
Sources
- GitHub Docs, About dependency review
Last reviewed: 19 October 2026.
