Not every automated fix deserves the same scrutiny. A practical approach is three tiers: light review for lockfile or patch level dependency fixes, standard review for minor upgrades and small code changes, and heavy review for major upgrades, configuration changes and anything touching authentication or build pipelines.
Why tiers beat one rule
If every fix needs two senior approvals, people route around the process. If every fix needs none, you learn about problems in production. Tiers match effort to risk, and they make the exceptions visible.
The tiers below are a starting point. Adjust them to your own incident history and test coverage.
Tier 1: light review
Typical content: a patch version bump of a direct dependency, or a lockfile only change that moves a transitive package within its allowed range.
Suggested rule: one approval from a code owner, required checks green, no unexpected packages in the lockfile diff. Semantic versioning describes a patch release as backward compatible bug fixes, which is why this tier is lower risk. It is a convention, so the lockfile check still applies.
Tier 2: standard review
Typical content: a minor version bump, a small code change that replaces a vulnerable call, a new override for a transitive dependency.
Suggested rule: one approval from a code owner who knows the module, required checks green, and a named test or manual check that covers the changed behavior. Minor releases add functionality and may deprecate features, so read the release notes for the changed packages.
Tier 3: heavy review
Typical content: a major version bump, a change to security configuration, edits to authentication or authorization code, CI workflow changes, anything that changes how artifacts are built or signed.
Suggested rule: two approvals including a code owner, a staging deployment before merge, an explicit rollback owner, and a pause before release if the change is large.
Mapping tiers to branch rules
GitHub branch protection can require a number of approving reviews, review from code owners, passing status checks, and conversation resolution. It can also dismiss approvals if new commits arrive after review. Those settings let you express each tier as configuration rather than as a wiki page nobody reads. Different branches or rulesets can carry different rules.
Two settings matter for bots. First, require approval of the most recent push so that nobody, human or bot, can add commits after approval unseen. Second, require code owner review so the right team sees the change. The post on CODEOWNERS for bot opened pull requests shows how.
How to classify automatically
Classification can be mechanical: version distance from the old to the new version, paths changed, labels. Anything that does not fit a tier cleanly defaults to the higher tier. Review the classification rules every quarter against incidents and reverts. The revert rate tells you if tier 1 is too loose.
Pitfalls
- Treating "security fix" as a reason to skip tiers. Urgent fixes can use an expedited path, but they should still get a named approver.
- Letting one person approve their own bot's PRs without any other check.
- Forgetting to re-approve after the bot rebases or force pushes.
If you use Safeguard, autonomous remediation categories ship set to Manual, and policies and gates can enforce checks on a PR before it merges.
Quick check
Should a security fix ever skip review?
Skip nothing silently. An emergency path with one named approver and a recorded reason is fine. No approver at all is a gap an auditor will notice.
Sources and further reading are below.
Sources
Last reviewed: 19 October 2026.
