Merge checks control the workflow by forcing review before code reaches the production branch, while signed commits and tags verify who created or approved a change. One protects the release process, the other strengthens provenance and tamper evidence. Used together, they reduce the chance that unreviewed or altered code reaches production.
How Merge Checks and Signed Commits Protect Different Parts of Integrity
Merge checks and signed commits protect code integrity at different points in the delivery chain. Merge checks are workflow controls: they decide whether a change is allowed to enter the protected branch at all. Signed commits and tags are provenance controls: they help you verify that a specific change really came from the expected author or maintainer and has not been altered in transit. The distinction matters because one blocks unsafe admission, while the other strengthens trust in origin.
That difference also changes what each control can prove. Merge checks can tell you that review, tests, or policy gates were satisfied before merge, but they do not by themselves prove who wrote the code. Signed commits can prove cryptographic authorship or approval, but a signature does not mean the code was reviewed, approved for release, or safe to merge. In practice, these controls answer separate questions about process and provenance.
For a broader supply-chain view, signed artifacts become more valuable when they are paired with integrity and provenance expectations such as SLSA and secure development guidance in NIST SSDF (SP 800-218). Those sources help frame why cryptographic provenance is only one layer of code integrity, not a replacement for controlled promotion into production.
What Each Control Can and Cannot Prevent
Merge checks are strongest at stopping unreviewed, untested, or policy-violating code from reaching the branch that drives production deployment. They are a release governance measure, so they help enforce branch protection, reviewer quorum, CI status checks, and other gates that reduce accidental or rushed changes. Their limitation is that once a trusted actor is allowed to merge, the control does not verify the internal truth of the code itself.
Signed commits and signed tags are strongest at detecting tampering, impersonation, or ambiguous authorship. If a commit is signed with a trusted key, you can bind that change to a specific signer and improve non-repudiation. Their limitation is that they do not assess business logic, test coverage, or whether the change was accepted through the correct workflow. A perfectly signed commit can still be a poor or malicious change if the signer is compromised or the review process is weak.
For readers who want a concrete integrity model, OpenSSF and SLSA are useful complements because they connect commit provenance, build integrity, and downstream artifact trust. In other words, provenance helps you trust where code came from, while merge checks help you trust how it entered the release path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 8.2 — Audit Log Management | Signed commits and merge gates create traceable change evidence for integrity reviews. |
| 16.3 — Software Integrity and Validation | Merge checks and signed commits both support software integrity validation before release. | |
| Recommendation — Record and review repository change events to detect unauthorized or suspicious code changes. Validate code integrity and release gates before promoting changes to production. | ||
| NIST CSF 2.0 | PR.AA-01 — Identity Proofing, Authentication, and Authorization | Signed commits depend on trusted signer identity and authorization to attribute code changes. |
| PR.DS-01 — Data-at-Rest Integrity Protection | Signed commits and tags provide tamper evidence for source and release artifacts. | |
| PR.PS-01 — Production/Service Change Control | Merge checks are change-control gates that regulate what reaches the production branch. | |
| Recommendation — Verify signer identity and enforce authorization for code changes and release actions. Protect source and release artifacts with integrity controls that detect unauthorized modification. Enforce controlled promotion and approval before production code changes are accepted. | ||
| NIST SP 800-63 | IAL2 — Identity Assurance Level 2 | Commit signing relies on sufficiently trusted binding between a signer and their key or account. |
| AAL2 — Authenticator Assurance Level 2 | Signed commits depend on robust authenticator protection for the private signing key. | |
| FAL2 — Federation Assurance Level 2 | Repository and signing workflows often rely on federated identity trust for reviewer or maintainer actions. | |
| Recommendation — Bind code-signing keys to trusted identities with assurance appropriate to the release process. Protect signing keys with strong authenticators and resist key theft or misuse. Use federated trust only when the signing and approval workflow preserves strong identity assurance. | ||
| OWASP Agentic AI Top 10 | A3 — Identity and Access | Repository approvals and signing keys are access-bearing actions that need strong authorization boundaries. |
| A4 — Data and Model Integrity | Commit signatures and merge controls both aim to preserve integrity of source inputs. | |
| Recommendation — Restrict signing and merge authority to tightly governed identities and approval paths. Preserve integrity controls for source inputs before they affect downstream builds or releases. | ||
Practitioner Guidance
What to verify: Treat merge checks as release protection and signed commits as provenance evidence, then verify both separately. A repository can have excellent signatures and still allow risky merges if branch protections are weak; it can also have strict merge checks while accepting unsigned or poorly attributable commits.
Common mistake: Teams often assume that one control compensates for the other. It does not. If your concern is “who introduced this change?”, signatures matter more; if your concern is “how did this change reach main?”, merge checks matter more. The strongest posture uses both, with protected branches requiring review plus verified commit and tag signatures where your workflow supports it.
Practitioner takeaway: Use merge checks to control admission into the protected branch, and use signatures to make authorship and tamper evidence verifiable; neither control alone fully answers code integrity.
Related resources from NHI Mgmt Group
- What is the difference between shift-left code checks and post-merge review gates?
- What is the difference between code integrity risk and identity exposure risk in CI/CD?
- What is the difference between protecting developer credentials and protecting package integrity in a supply chain attack?
- What is the difference between protecting source code secrets and protecting secrets stored in cloud managers?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
