Commit signing

What commit signing actually proves

Commit signing adds a cryptographic signature to a change record so others can later verify that the commit was created by the expected signer and has not been altered in transit or after the fact. On its own, that is only a proof of origin and integrity claim, not proof that the change is safe, reviewed, or acceptable.

The key limitation is trust. A signed commit is only as strong as the identity behind the signing key and the policy that decides whether unsigned or untrusted commits are allowed to enter protected branches.

How commit signing fits into repository trust

In a well-governed repository, commit signing is one layer in a broader trust model that includes branch protection, code review, allowed signers, and rules that prevent bypassing policy. That combination matters because the signature helps answer “who authored this change?” while repository policy helps answer “may this change be accepted here?”

Different signing approaches exist, including GPG-based signing, SSH-based signing, and keyless or externally attested patterns. The operational detail varies, but the security objective is the same: make commit provenance machine-verifiable instead of relying on a visible author name alone.

When repositories permit admin bypass, force pushes, or history rewrites without strong controls, commit signatures can be weakened or rendered misleading. The signed object may still be valid, but the surrounding repository state may no longer reflect a trustworthy change history.

Why signed commits matter for supply-chain integrity

Commit signing is most valuable when source code changes are part of a software supply chain that feeds builds, releases, and deployed artifacts. It helps reduce the chance that a malicious or fraudulent commit is mistaken for a legitimate maintainer change, especially when attackers try to hide in normal developer workflows.

That is why signed commits should be treated as provenance evidence, not as a standalone control. The signature can support downstream confidence, but it does not stop a compromised developer account, stolen signing key, or poisoned review process from introducing harmful code.

Repositories that require signed commits, protect release branches, and preserve auditability create a much stronger assurance model than signatures alone. The real control objective is to make unauthorized code changes both harder to introduce and easier to detect.

For a broader repository control view, the Git Repository Security Guide explains how signed commits fit with protected branches and history integrity, while the CI/CD Security Guide shows how commit provenance can be undermined later in the delivery pipeline.

What teams should verify when they rely on signed commits

The practical question is not whether signatures exist, but whether the organisation can trust the signer, enforce the policy, and preserve evidence across the whole workflow. That means checking whether signatures are actually required on protected branches, whether signer keys are governed, and whether repository rules prevent silent exceptions.

Teams should also verify that commit signing is paired with review discipline and branch rules, because a signed malicious commit is still malicious. The best use of commit signing is as part of a layered control set that improves accountability, change traceability, and post-incident reconstruction.

For exposure analysis after a suspected compromise, the focus should be on which signer keys, developer accounts, and repository permissions were involved, and whether signed history was preserved or rewritten. If those foundations are weak, the signature becomes evidence of activity, not assurance of trust.

The PHP Git server compromise 2021 is a useful reminder that malicious commits can be made to look legitimate when developer access is abused, and that provenance controls only work when the surrounding authentication and repository governance are sound.

Common failure modes of commit signing

Commit signing fails most often when organisations treat it as a checkbox rather than a trust system. The signature can be valid while the key is stolen, the signer is impersonated, the repository allows bypasses, or the policy accepts unverified history.

Another common failure mode is confusion between “signed” and “reviewed.” A signature proves the commit was signed by a key holder, not that the code was inspected, approved, or free of backdoors. That distinction matters most where high-trust maintainers, release branches, or production-bound code paths are involved.

As a result, commit signing works best when identity, policy, and repository enforcement are aligned. Without that alignment, it adds signal, but not enough assurance to stand alone.

Related resources from NHI Mgmt Group

• What is the difference between commit signing and SBOMs for code security?
• What breaks when code signing and commit history checks are not enforced for repository installs?
• Why does commit signing reduce the risk of codebase hijacking?
• How does GPG Commit Signing work?