A stacked pull request is a sequence of smaller, dependent changes built on top of one another instead of being combined into one large review. This approach reduces review burden, clarifies intent, and helps teams isolate risk in complex work.
Expanded Definition
A stacked pull request is a review workflow where a large change is split into a chain of smaller pull requests, each dependent on the one before it. The technique is common in software delivery because it keeps each review narrow, preserves commit history, and makes it easier to identify which change introduced a defect. In security-sensitive engineering, that traceability matters because reviewers can inspect configuration, code, and policy changes in smaller increments instead of approving a broad diff at once.
Stacked pull requests are not the same as simply opening many unrelated pull requests. Each item in the stack has a clear dependency order, so the sequence must be merged carefully to avoid breaking builds or shifting context during review. Usage in the industry is still evolving, and teams differ on whether they manage stacks through branch tooling, release trains, or temporary feature branches. For governance purposes, the relevant question is whether the workflow improves accountability, review quality, and rollback clarity. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it frames change control, access review, and secure development expectations that stacked review processes are often used to support.
The most common misapplication is treating stacked pull requests as a way to hide unfinished work, which occurs when teams merge dependent changes without preserving clear review boundaries or traceable commit relationships.
Examples and Use Cases
Implementing stacked pull requests rigorously often introduces branch-management overhead, requiring organisations to weigh faster, more targeted review against the cost of coordinating dependencies.
- A platform team splits a risky infrastructure update into separate pull requests for authentication changes, policy updates, and deployment logic so each reviewer can focus on one control plane at a time.
- A security engineering team uses a stack to introduce logging, alerting, and rollback safeguards in stages, which helps validate each safeguard before the next layer is merged.
- A product team handling a large refactor creates dependent pull requests to keep the feature functional while reviewers check each unit of change against test coverage and secure coding expectations.
- A compliance-sensitive environment uses stacked changes to document approval order, making it easier to show who reviewed which step when auditors ask how a release was controlled.
- Teams following guidance from the NIST control catalog often pair stacked review with change approvals, branch protection, and restricted merge rights to reduce the risk of unreviewed code reaching production.
Stacked pull requests are especially useful when one change depends on another but the combined diff would be too large for reliable review. They also help reviewers understand intent when code touches identity flows, secrets handling, or privileged automation. In practice, the value comes from making each layer small enough to be debated, tested, and reverted independently.
Why It Matters for Security Teams
Security teams care about stacked pull requests because review discipline is part of change control, and weak change control is a common route to accidental exposure. When a single pull request contains authentication logic, infrastructure updates, and secrets handling, reviewers are more likely to miss a privilege escalation path or an unsafe default. Stacks reduce that concentration of risk by forcing decision points throughout the delivery chain. They also improve evidence quality for security assurance, because each step can be linked to a specific reviewer, test result, or approval event.
The identity connection is practical rather than theoretical. If a change affects NHI credentials, service-to-service permissions, or agent tool access, a stacked workflow can help separate the policy change from the implementation change. That separation makes it easier to validate least privilege, rollback impact, and approval scope. It also aligns with the way modern engineering teams manage secure development and controlled releases under NIST SP 800-53 Rev 5.
Organisations typically encounter the cost of poor review structure only after a rushed merge causes a service failure, an access misconfiguration, or a security incident, at which point stacked pull requests become operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5, NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.IP-1 | Secure development and change management map well to stacked review workflows. |
| NIST SP 800-53 Rev 5 | CM-3 | Configuration change control is directly supported by smaller, traceable pull requests. |
| OWASP Non-Human Identity Top 10 | Stacked reviews help reduce risky changes to NHI credentials and service permissions. | |
| NIST SP 800-63 | IAL2 | Identity assurance principles support traceable approvals for sensitive change actions. |
| NIST AI RMF | AI RMF governance encourages accountable, reviewable change processes for AI-adjacent code. |
Treat high-impact change approvals as identity-assured actions with clear reviewer accountability.
Related resources from NHI Mgmt Group
- Should organisations allow pull_request_target for automated dependency workflows?
- What breaks when untrusted pull request content is executed in a workflow?
- What do security teams get wrong about pull_request_target workflows?
- Why do pull_request_target workflows create more risk than standard pull request workflows?
