Security teams should not rely on a single required reviewer as a complete control. The stronger baseline is to require approval from the most recent pusher, require at least two reviewers for sensitive branches, and restrict who can push to matching branches. Those settings reduce the chance that a reviewer with push rights can modify and approve the same change set.
Why branch protection needs more than one approval gate
Pull request hijacking usually succeeds when a single control can be satisfied by the same person who can also influence the change set. If a reviewer can push, amend, or rebase the branch after approving it, the approval is no longer a meaningful independence check. Branch protection should therefore separate review authority from push authority and make that separation hard to bypass.
The practical goal is to stop the “approve, then alter” pattern. Requiring approval from the most recent pusher helps because it forces a fresh review after the last content-changing action. Requiring two reviewers for sensitive branches adds a second independent check, and restricting who can push to matching branches prevents the easy path of self-approval followed by a quiet rewrite. GitHub’s own branch protection model supports these controls, and hardening should be treated as a policy design problem, not a single setting.
Teams should also be careful about indirect ways branch protections get weakened. Reusable approvals, broad bypass permissions, and loosely scoped repository roles can all reintroduce the same conflict of interest in a different form. The control only works when the person who can change code is not also the person whose approval makes the change eligible to merge.
How to tune the policy for high-value repositories
For repositories that publish production code, infrastructure changes, or dependency updates, the default should be stricter than “one approval and merge.” Use branch patterns that match the real release branches, not just the obvious names, and apply the same policy to any branch that can reach a deployment path. If a branch feeds release automation, protect it like a production control point.
Where the repository has multiple maintainer groups, scope push rights narrowly and separate them from review rights. If the same team must both review and release, use enforced review freshness and a minimum reviewer count so that no single person can complete the full control loop alone. For especially sensitive branches, require status checks to pass before approval is considered valid, because code review without build or policy validation still leaves room for hidden branch tampering.
One useful operating rule is to treat bypass permissions as exceptions that need review. If someone can dismiss reviews, force push, or override protections, that capability should be limited, logged, and periodically recertified. The stronger the branch, the more important it is to understand who can defeat the control, not just who can satisfy it.
Risk and Threat Considerations
Pull request hijacking is risky because it exploits trust in the review process itself. The attacker does not need to defeat the whole pipeline if they can create a path where approval and code manipulation are controlled by the same actor or by colluding actors with excessive rights.
Failure mechanism: A reviewer with push rights, or a user with bypass privileges, can approve one version of a change and then alter the branch before merge. If branch protection does not require review freshness, independent reviewers, and tight push restrictions, the merge gate can be satisfied without meaningful separation of duties.
Impact: Malicious or unintended code can enter protected branches, including backdoored application logic, workflow changes, or dependency manipulations. Once that happens, the same path can also be used to seed downstream supply-chain compromise, which is why branch protection is as much about integrity assurance as it is about review workflow.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 5.3 — Account Management | Branch push and review rights must be separately assigned and limited. |
| 4.4 — Secure Configuration of Enterprise Assets and Software | Branch protection is a configuration control that must be hardened consistently across release branches. | |
| Recommendation — Limit branch push and bypass rights to the smallest necessary set of users. Enforce hardened branch protection settings on all production release branches. | ||
| NIST CSF 2.0 | PR.AA-01 — Identity and Access Control | The issue depends on separating who can approve from who can change protected code. |
| PR.DS-05 — Data is protected from unauthorized access, modification, and disclosure | Branch hijacking is an integrity problem that can modify protected source before release. | |
| Recommendation — Restrict code-change privileges so reviewers cannot silently alter protected branches. Require fresh review and status checks before protected branch merges. | ||
| MITRE ATT&CK | T1098 — Account Manipulation | Attackers abuse privileged repo settings or role changes to preserve access and approval paths. |
| Recommendation — Hunt for permission changes that let one account both approve and alter protected code. | ||
Practitioner Guidance
What to verify: Confirm that the most recent pusher must be re-approved, that protected branches actually cover every release path, and that push rights are narrower than review rights. If any maintainer can both modify and approve the same protected branch, the control is still too weak.
Common mistake: Treating “one required reviewer” as sufficient. That setting is easy to satisfy with a compromised reviewer account, a permissive maintainer role, or a late-stage branch edit that preserves the appearance of approval.
Practitioner takeaway: The hardening target is independence, not ceremony, make it impossible for a single actor to both shape the final code and satisfy the merge gate.
Related resources from NHI Mgmt Group
- How should security teams harden GitHub Actions against untrusted pull request content?
- How should security teams harden CI/CD build pipelines against untrusted pull requests and workflow abuse?
- What should security teams do first after a GitHub Actions workflow in a public repository is found vulnerable to pull request abuse?
- How should security teams harden containers against fileless execution and resource hijacking attacks?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
