Stale review dismissal is a GitHub protection that invalidates approvals when a pull request changes after review. It ensures the approval applies to the current diff, not an older revision, and helps prevent code from being merged without fresh evaluation after new commits are pushed.
What stale review dismissal does
Stale review dismissal keeps pull request approvals tied to the current code, not an older revision. When new commits are pushed after review, prior approvals are invalidated so the change must be re-evaluated before merge.
This protection is about review freshness. It reduces the chance that a meaningful code change slips through on the strength of a correct review of the wrong version, which is a common failure mode in fast-moving branches.
How it changes the merge control model
Without stale review dismissal, an approval can survive even after the diff has changed substantially. That creates a gap between what was reviewed and what is actually being merged, especially when authors amend code in response to feedback or add new commits after approval.
With dismissal enabled, the system forces a new approval cycle after post-review change. That makes the merge gate reflect the actual contents of the branch at merge time, which is the core control benefit.
The setting is most useful where review is meant to be a substantive security or quality check, not a ceremonial step. It works best alongside branch protections that also require the right reviewers, since stale dismissal only resets old approvals, it does not judge whether the new review is complete.
Why teams use it for review integrity
Stale review dismissal protects the meaning of an approval. It treats review as a statement about a specific diff, which matters because even small edits can alter control flow, permissions, error handling, or unsafe assumptions in ways a prior review did not see.
It also helps teams avoid approval drift in collaborative development, where comments and fixes often arrive in multiple rounds. By requiring a fresh approval after new commits, the policy aligns human review with the exact code state being merged.
For workflows that depend on change control, this is a practical safeguard against accidental overtrust in old sign-off.
When it can feel stricter than expected
Teams sometimes experience stale dismissal as friction because a helpful review must be repeated after a late patch. That friction is the point, but it should be understood as a trade-off: stricter merge assurance in exchange for extra review effort when the branch changes.
It is also important to recognise that this control does not replace substantive review quality. A stale approval reset cannot compensate for shallow feedback, missed test coverage, or reviewers approving too early.
Used well, it is a freshness control for human judgement, not a substitute for engineering discipline.
Risk and Threat Considerations
Without stale review dismissal, a repository can merge code that no longer matches the reviewed state. The risk is not only accidental error, but also deliberate abuse of trust in an approval that became stale after the diff changed.
Failure mechanism: A contributor obtains approval, then pushes additional commits that change behaviour, security checks, or dependencies while the original approval remains valid.
Impact: The merge gate can be bypassed in practice, allowing unreviewed or differently reviewed changes to enter the protected branch.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP SAMM set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V15 — Secure Coding and Architecture | Fresh review helps keep merged code aligned with the reviewed architecture and logic. |
| Recommendation — Require re-review after code changes so the approved design matches the current diff. | ||
| NIST SP 800-53 Rev 5 | CM-3 — Configuration Change Control | Stale dismissal enforces controlled review of branch changes before promotion. |
| Recommendation — Revalidate approvals after changes so controlled code states are the ones merged. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Branch protections support secure development by preventing stale sign-off on changed code. |
| Recommendation — Use branch protections that force fresh approval when code changes after review. | ||
| OWASP SAMM | GOV — Governance | Review freshness is a governance practice for ensuring code review decisions stay current. |
| Recommendation — Define review rules that invalidate approvals when the underlying change set changes. | ||
Practitioner Guidance
What to watch for: Enable stale review dismissal where approvals are meant to certify the exact branch state, especially on protected branches with security-sensitive changes. Treat it as part of the branch policy design, not as an isolated checkbox.
Governance implication: Pair it with reviewer requirements and merge rules that define who must re-approve after code changes, so teams do not assume an old approval still covers a new diff.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
