Check five things: the update level, the changelog, any new transitive packages, the CI result, and whether your code calls the changed part. That takes about five minutes for a typical pull request and catches most of what a quick merge would miss.
1. The update level
Read the old and new version. A patch should be a fix, a minor should add features, and a major may break your code. The Semantic Versioning specification defines those meanings, with one exception: in major version zero, anything may change at any time, so treat a 0.x minor like a major.
2. The changelog
Open the release notes. Look for words like removed, deprecated, renamed, default changed, minimum version raised. If there are no notes at all, that is information too. For a package you depend on heavily, consider reading the diff of the code, at least the file list.
3. New transitive packages
In the lockfile diff, scan for names that were not there before. A new package in your tree is new code you run, and a new publisher you trust. Check who maintains it and whether it has a repository you recognize.
4. CI
Green is good, but know what it covers. If tests are thin, run your smoke tests by hand. Check that the build actually ran against the new version, not a cached one.
5. Reachability
Ask whether your code calls the changed or fixed area. For a security fix, that tells you urgency. For a feature update, it tells you where to look for breakage.
Checklist
| Check | Question | Pass |
|---|---|---|
| Level | Patch, minor, major, or 0.x? | Reviewed accordingly |
| Notes | Anything removed or changed? | Read |
| Tree | New transitive names? | Checked |
| CI | Does it cover this change? | Yes |
| Reach | Does my code use it? | Known |
Signals to slow down
- A very new release published within the last few days.
- A sudden change of maintainer, or a long silent project that suddenly releases.
- A large lockfile diff for a small stated change.
- Install scripts that were not there before.
A delay setting on your bot, which holds back brand new releases for a few days, gives the community time to spot a bad version before it reaches you.
Record the decision
Write one line in the pull request: merged, why. If you decide not to merge, say why and add an ignore rule with a revisit date, so the bot does not reopen it next week.
Try it yourself
Click through it at your own pace, or open it full screen. Walk through how to judge whether a flagged issue can actually be exploited in your setup, the same question as check five above.
Quick check
Can I skip the changelog for patch updates?
For low risk packages with strong tests, often yes. For packages on a critical path, still skim it.
How long should a review take?
Around five minutes for routine updates. Majors and unusual lockfile diffs take longer.
Safeguard scans manifests and lockfiles into an SBOM, uses reachability analysis to show which flagged dependencies your code actually calls, and can open fix pull requests (off by default, every category on Manual). You can try a free scan on a public repository.
Sources
Last reviewed: 19 October 2026.
