Check four things: which packages were added, removed or bumped; whether any new version has known vulnerabilities; whether the package is what its name suggests; and whether the change matches the pull request's stated purpose. A manifest edit in a typo fix is a signal to slow down.
Why dependency edits deserve attention
Dependency files are small, but they decide what code enters your build. A lockfile diff can be thousands of lines that nobody reads. Yet one changed entry can point to a different source or version. This is a common route for supply chain problems, because the reviewer trusts a short, tidy manifest.
GitHub describes dependency review as a view of dependency changes on a pull request, with added, removed and updated dependencies, release dates, how many projects use them, and vulnerability data. Its action can scan for vulnerable versions introduced by a change and warn or fail the run.
The checks
- Purpose match. Does the description explain why the dependency changed? An unexplained lockfile churn is a reason to ask.
- New names. Read each added package name slowly. Look for near misses of popular names.
- Version movement. Large jumps or downgrades deserve a reason. A downgrade can reintroduce a fixed vulnerability.
- Source. Look for git URLs, tarball links, or custom registries replacing registry versions.
- Vulnerabilities. Check each new or updated version against advisory data.
- Install scripts. Check whether a new package runs code during install.
- Transitive changes. Compare the full tree, not just the lines the contributor edited, since one direct bump can pull in several indirect updates.
A quick comparison of review methods
| Method | Catches | Misses |
|---|---|---|
| Reading the diff | Obvious odd names and sources | Deep transitive changes |
| Dependency review on the pull request | Added packages and known advisories | Packages with no advisory yet |
| Scanning the full SBOM | Everything in the tree | Intent behind the change |
| Reachability analysis | Which vulnerable code is actually called | New malicious packages with no advisory |
Use more than one. None is complete, which is why reading the intent still matters.
What to do with a suspicious change
- Do not approve fork workflow runs yet.
- Ask the contributor to explain and to split dependency edits from other work.
- If the answer is unsatisfying, close with a polite note.
- If you suspect a malicious package, report it to the registry instead of just closing the request.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how direct and indirect dependencies appear in one inventory, and what an added entry looks like.
Where Safeguard fits
Safeguard scans dependencies, generates SBOMs, and uses reachability analysis to show which vulnerable code your project calls. Run the free scan on a branch to compare.
Quick check
Is a lockfile change on its own safe to skip?
No. Lockfiles decide what is installed. Review what changed and why.
Does a clean advisory check prove a package is safe?
No. A new malicious package may have no advisory yet, so also check the name, source and purpose.
Sources
Last reviewed: 19 October 2026.
