An approver should check different things for an OS patch ticket and a dependency pull request. For the OS, check scope, restart impact and the rollback path. For a dependency, check the version jump, the lockfile diff and the test results. Both need an owner and a verification step.
Checklist for an OS patch change
- Scope. Which groups and how many hosts? Is a pilot included?
- Severity and reason. Which advisory, and is it exploited or routine?
- Restart. Is one needed, and when? Who covers the capacity?
- Dependencies. Does it conflict with agents, drivers or third party packages?
- Rollback. Snapshot, previous image or uninstall path named?
- Verification. How will you confirm the new version is running?
- Exceptions. Any host skipped, with an owner and expiry?
NIST SP 800-40 Rev. 4 suggests phased deployment, where a small set of assets goes first as canaries. Reviewers should expect to see that in the plan unless the situation is a crisis.
Checklist for a dependency pull request
- What changed. Patch, minor or major? A major bump needs more attention. See semver patch, minor, major: how risky is this fix PR.
- Lockfile diff. Only the intended package and expected transitive changes. See what to check in a lockfile diff.
- Tests. Did CI pass, and do the tests touch the code that uses this library?
- Release notes. Removed APIs, changed defaults, new license terms.
- Source. Is the package and publisher the expected one? Watch for a name that looks almost right.
- Deployment. Which services will carry it, and is a rebuild needed?
- Rollback. Is a revert clean?
GitHub notes that its compatibility score is the share of CI runs that passed in other public repositories producing the same update. Treat it as context, not approval.
What both lists share
| Item | OS ticket | Dependency PR |
|---|---|---|
| Reason | Advisory and severity | Alert or routine bump |
| Test | Canary hosts | CI plus canary deploy |
| Undo | Snapshot or image | Revert commit |
| Proof | Version query, scan | Artifact scan |
Keep reviews proportionate
A routine patch version bump with green tests should take minutes. A major version bump on a core library deserves a real look. Set rules for what can merge on automation and what always needs a person.
Where Safeguard fits
Safeguard's gates can enforce parts of the dependency checklist on every pull request, for example blocking a known vulnerable version. Try the free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a failing check holds the merge.
Quick check
Who should approve an OS patch change?
The owner of the host group, plus a second person for broad or emergency changes.
Can a bot approve a dependency update?
You can allow automerge for low risk updates with strong tests. Decide the rule in advance and review it periodically.
Sources
Last reviewed: 19 October 2026.
