Two person review stops a single compromised or rogue account from merging a change alone. It does not stop two colluding people, a reviewer who misses the diff, or an attack that happens after merge in the build or registry. It is a strong control for one entry point, not a complete defense.
What the control is
Two person review means no change reaches the protected branch without approval from someone other than the author. On GitHub, protected branch settings include requiring pull request reviews before merging, requiring status checks and requiring conversation resolution. Code owners can be required to approve changes to the files they own.
SLSA describes source integrity as ensuring all changes reflect the producer's intent, and says it approximates intent as approval from two authorized representatives.
What it would have helped with
The SLSA overview uses a contractor with repository access who pushed a malicious commit as an example of an unauthorized change, and says two person review could have caught it. That is the clean case: one person acting alone.
Where it falls short
| Scenario | Does review help? |
|---|---|
| One stolen account pushes a change | Yes, if review is enforced |
| Attacker controls two accounts | No |
| Reviewer approves without reading | No |
| Admin bypasses the rule | Depends on settings |
| Build server altered after merge | No, that is build integrity |
| Package uploaded with a leaked credential | No |
Review also depends on the diff being readable. A change hidden in a generated file, a minified blob or a large unrelated refactor is easy to approve by accident.
Making review work
- Enforce it with settings, not policy documents. Include administrators where you can.
- Require code owner review for workflows, release scripts and dependency manifests.
- Keep pull requests small, so a reviewer can actually read them.
- Treat dependency changes as code changes. Look at lockfile diffs.
- Pair review with automated status checks that run before merge.
- Watch for new committers earning trust slowly. Review gets weaker if the second person is always the same friend.
For a solo maintainer
If you are the only person, you cannot have a second reviewer. Alternatives include delayed self review, an automated check on every change, and a trusted outside reviewer for release changes only. Be honest in your documentation about what review exists.
Try it yourself
Click through it at your own pace, or open it full screen. Look at which checks run before a merge is allowed.
Where Safeguard fits
Safeguard's policies, gates and guardrails can add automated checks at the pull request alongside human review. See our guide to configuring branch protection rules for the platform side.
Quick check
Is one reviewer enough?
One reviewer is the minimum for two person review. Sensitive paths may deserve a code owner as well.
Does review catch malicious dependencies?
Only if reviewers read the lockfile changes. Add dependency review to make those changes visible.
Sources
Last reviewed: 19 October 2026.
