The reviewed head commit SHA is the exact commit identifier that was approved for a pull request. Including it in a merge request binds the merge to the reviewed revision, so if the branch changes, GitHub can reject the merge with a conflict instead of allowing stale approval to cover new code.
What the reviewed head commit SHA actually does
The reviewed head commit sha is not just a label, it is the exact revision that approval was given for. By binding review to a specific commit, it preserves the security meaning of the approval and prevents later branch changes from silently inheriting that approval.
This matters because a pull request is a moving target until merge. If the reviewed revision is no longer the current head, the approval no longer proves that the code being merged is the code that was inspected.
Why commit binding protects review integrity
The core value of a reviewed head commit SHA is integrity of review. It creates a verifiable link between human approval and the source state that was examined, which is especially important when developers push new commits after review or when automation updates the branch.
Without that binding, review becomes vulnerable to stale approval, where a merge appears authorized even though the final code differs from what reviewers saw. The SHA gives the system a concrete reference point for deciding whether the approval is still valid.
In practice, this is a control for change integrity rather than a general repository setting. It helps preserve the trust boundary between reviewed code and unreviewed code.
How merge systems use the SHA to block stale approvals
When the branch head changes after approval, merge tooling can compare the stored reviewed head commit SHA with the current tip. If they differ, the merge should fail or require re-review because the approved revision is no longer current.
This is one of the simplest ways to prevent approval drift in pull request workflows. The mechanism does not try to infer whether the new commits are harmless; it treats any change to the reviewed head as a reason to re-establish review on the updated revision.
That behavior also supports auditability. A merge record that includes the reviewed SHA makes it easier to explain exactly which commit was approved and whether the merged code matched that approval.
Where this fits in secure code review workflows
The reviewed head commit SHA is most useful in environments that care about branch protection, merge gating, and reproducible review decisions. It works best when approvals are tied to immutable revisions and when automation enforces that the reviewed state and merge state stay aligned.
The concept is closely related to supply-chain hygiene for software delivery, because it reduces the chance that unreviewed code slips in under an old approval. NHIMG’s CI/CD Pipeline Identity Security Guide covers the adjacent control problem in CI/CD systems, where pinned revisions, trusted publishing, and build provenance all depend on knowing exactly what was approved and executed.
For teams working at scale, the SHA becomes part of the evidence chain that connects review, merge, build, and release to the same source revision.
What can go wrong when the reviewed SHA is ignored
If a merge process does not enforce the reviewed head commit SHA, approval can be detached from the code actually merged. That creates a stale-approval problem in which a later commit, or even a maliciously altered revision, inherits trust that was earned by an earlier state.
Failure mechanism: The pull request head advances after review, but the merge system does not re-check that the approved SHA still matches the current source revision.
Impact: A reviewer may approve one commit while a different commit enters the protected branch, weakening change control and opening the door to unnoticed code drift or unauthorized modifications.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA, CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP SAMM set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply-chain Levels for Software Artifacts | Reviewed commit binding preserves source revision integrity in the software supply chain. |
| Recommendation — Pin reviewed revisions and verify provenance before promotion. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | The term supports secure change control and review of code before merge. |
| Recommendation — Enforce review gates that revalidate changed code before merge. | ||
| NIST SP 800-53 Rev 5 | CM-3 — Configuration Change Control | The SHA ties approval to a specific code state under formal change control. |
| Recommendation — Require approval to be tied to the exact revision being merged. | ||
| OWASP SAMM | Governance | The concept reinforces controlled, reviewable software delivery practices. |
| Recommendation — Track approval-to-merge traceability as part of secure delivery governance. | ||
Practitioner Guidance
Why practitioners should care: Treat the reviewed head commit SHA as a control point, not just metadata. If your workflow allows approvals to persist across source changes, you have a governance gap between what was reviewed and what was merged.
What to watch for: Repeated rebases, force-pushes, or automated branch updates after approval should trigger a fresh review requirement. The useful rule is simple: if the reviewed SHA no longer matches the current head, the approval should no longer be considered current.
Related resources from NHI Mgmt Group
- What is the difference between pinning CI/CD actions by commit SHA and trusting mutable tags in supply chains?
- How should security teams handle GitHub repository dependencies when a commit SHA may resolve through a fork network?
- What is the difference between pinning a GitHub Action to a commit SHA and using a moving version tag?
- What happens when a CI/CD pipeline uses third-party actions without pinning them to a commit SHA?
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
