How do you require signed commits in GitHub and GitLab?

What signed commits actually enforce in GitHub and GitLab

signed commits are a repository trust rule, not a cosmetic signal. They let you reject changes unless the commit can be verified against a trusted signing identity, which is useful only when the enforcement point is the branch or merge path that matters. In practice, the control is strongest when it applies to protected branches, release branches, and any path that can merge into them.

That distinction matters because commit signing on its own does not stop an unsigned change from entering through a different workflow. The policy has to be enforced where code is accepted, not just where it is created. That is why teams usually pair commit signing with branch protection, merge checks, and a clear policy for which keys or certificates are allowed to sign.

For guidance on the broader signing lifecycle, use Code Signing Security Guide as the parent concept for key protection, timestamping, revocation, and recovery after key theft.

How to make the policy effective across direct pushes and merge paths

In GitHub, the practical pattern is to protect the target branch and require signed commits as part of the branch protection rules. In GitLab, the equivalent is to use protected branches together with push rules or server-side checks that reject unsigned commits. The exact menu names differ, but the operational goal is the same: the repository should refuse unsigned history on the branches that govern delivery.

The merge path deserves special attention because many teams assume that a protected branch alone is enough. If pull requests or merge requests can be merged by a path that does not re-check commit signatures, an unsigned commit can still slip in. Treat merge validation as part of the same enforcement problem, not as a separate convenience feature.

That is also why release automation should sign its own commits rather than rely on a human developer to remember the right local configuration. If a bot or release job creates commits, those commits need a signing identity, controlled access to the signing material, and a predictable verification outcome on the receiving side.

For pipeline-specific controls, CI/CD Security Guide covers how signed commits fit alongside branch rules, runner isolation, and review gates.

What to verify before you trust the setting

A policy is only real if you can prove that all entry paths enforce it. Verify direct pushes, fast-forward merges, merge commits, squash merges, and any API-driven automation that can write to the repository. Also confirm that administrators, bypass roles, and service automation are not silently exempt unless you have deliberately accepted that risk.

Key policy is the next control layer. A signing rule is only as trustworthy as the policy that decides which keys, certificates, or signing services are acceptable. If that policy is weak, reused, or difficult to revoke, the repository may accept a technically valid but operationally unsafe signature.

If you want a concrete incident lens for this failure mode, Sisense breach 2024 shows why a compromised GitLab credential and weak reset discipline can quickly expand blast radius.

Risk and Threat Considerations

Signed-commit enforcement reduces the chance of unauthorized history entering a protected branch, but it does not eliminate compromise if the signing key, certificate, or automation identity is already exposed. The main risk is trust substitution: an attacker who can sign as a trusted actor can produce changes that look legitimate to the repository controls.

Failure mechanism: The policy is enforced on one path but not all accepted paths, or a trusted signing identity is stolen, reused, or left active after its owner should no longer be able to sign.

Impact: Unsigned or attacker-controlled changes can be merged into protected code, weakening release integrity, auditability, and incident attribution, especially when release automation and human developers share the same trust model.

Practitioner Guidance

What to verify: Test the exact paths your teams actually use, including pull or merge requests, squash merges, release automation, and admin bypasses. If one route can land code without signature verification, the policy is incomplete even if branch protection looks correct in the UI.

Decision rule: If a non-human workflow creates commits, give it a dedicated signing identity and a revocation plan. Do not let ad hoc human keys become the release mechanism for automation.

What practitioners underestimate: The difficult part is usually not enabling signature checks, but ensuring that key issuance, merge enforcement, and revocation stay aligned over time. If those drift apart, the control becomes a checkbox rather than a trust boundary.

Practitioner takeaway: Treat signed commits as an enforcement chain, not a single setting: signing, branch protection, merge validation, and key governance all have to agree, or unsigned code can still enter through the side door.

Related resources from NHI Mgmt Group

• How do you require signed commits on GitHub branches?
• 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?