How do you require signed commits on GitHub branches?

How branch protection enforces signed commits

On GitHub, the control point is the protected branch itself. You configure branch protection so merges to that branch are blocked unless each commit in the update is signed and GitHub can verify the signature. That makes signing a merge requirement, not a courtesy, and it shifts the question from “did someone say they signed?” to “did the platform verify it?”

The practical distinction is between commit signing and enforcement. A developer can create a signed commit locally, but the branch rule is what decides whether that commit can land. If the signature is missing, untrusted, or invalid, the protected branch should reject the change even if the code is otherwise approved.

For teams using GitHub Actions or other automation, the same rule needs to cover machine-generated changes. Signed automation is often the first place this breaks down, because release jobs, dependency bots, and scripted version bumps may produce commits that do not follow the same signing path as humans. NHIMG’s GitHub and GitHub Actions Security Guide is useful here because it connects signed commits to the broader branch, runner, and workflow controls that determine whether automation can safely merge code.

What has to be true for signed commits to work in practice

Signed commits only help if the signing identity is trusted and consistently used. That means contributors need a valid signing key or a verified signing method, and the organisation needs a clear rule for which identities are acceptable. Without that, teams end up with a policy that looks strict but still lets untrusted or unverified changes enter the branch through exceptions, rebases, or automation pathways.

It also matters how the repository is structured. If a repo allows direct pushes, force pushes, or alternate merge paths around the protected branch, the signature requirement can be bypassed in practice even when it exists on paper. Good branch protection should therefore be paired with narrow write access, merge-only workflows, and review rules that make the signature check unavoidable.

For continuous delivery pipelines, commit signing is part of release integrity, not just developer hygiene. NHIMG’s CI/CD Security Guide covers the adjacent failure modes, including pipeline poisoning and workflow abuse, which is why release automation should be reviewed alongside branch rules rather than after them.

Where signed-commit policy usually fails

The most common failure is assuming that “signed” means “safe.” A signature only proves that a private key or verified signing method was used, not that the change was reviewed, benign, or produced by the right process. If an attacker steals a trusted signing key or abuses an automation identity that is allowed to sign, the branch rule will still accept malicious content unless other controls catch it.

Another failure mode is weak operational coverage. Teams often sign human commits but forget generated commits from bots, release tooling, or vendor automation. That creates a gap where the branch is protected for manual work but fragile for automated work, which is exactly where production release failures tend to surface.

Risk and Threat Considerations

Signed-commit enforcement reduces tampering risk, but it also creates a high-value trust boundary around signing keys, verified accounts, and release automation. If that trust boundary is weak, an attacker can use a valid signature path to make a malicious change look legitimate, or can block deployments by introducing unsigned changes into an otherwise controlled release flow.

Failure mechanism: The branch rule only checks signature validity, while the real attack or failure comes from stolen signing material, misconfigured automation, or an alternate merge path that escapes the policy.

Impact: A compromised signing path can allow malicious code to land in a trusted branch, while unsigned automation can stop merges, delay releases, or force risky exception handling during incident response.

Practitioner Guidance

What to verify: Confirm that the branch rule rejects unsigned commits on every protected path, not just the main merge route. Then test a real release or bot-generated commit, because the control is only effective if automation passes through the same enforcement point.

Escalation / exception: If a bot, release job, or service account cannot produce a trusted signature, treat that as a pipeline design issue rather than a one-off exception. Exceptions should be short-lived and explicit, because permanent carve-outs turn the control into documentation only.

Practitioner takeaway: The hard part is not turning on commit signing, it is making sure every identity that can write to the branch, human or automated, is forced through the same verified signing path.

Related resources from NHI Mgmt Group

• When should organisations require signed commits for production code?
• What breaks when GitHub commits are not digitally signed?
• How do you require two-factor authentication for a GitHub organisation?
• How do you configure branch protection rules on GitHub default branches?