SSH commit signing lets a developer sign Git commits with an SSH private key, and Git records the matching public key material so others can verify authorship and integrity. Defenders should require verified signatures on protected branches, manage trusted signing keys, and revoke or rotate keys when accounts or laptops are lost.
How SSH commit signing works
ssh commit signing works by binding a commit to a developer’s SSH private key, then letting Git verify that the commit was signed by the matching public key. The important security property is integrity with attribution: the signature says who controlled the key at signing time, not that the person is necessarily trustworthy forever.
Git stores the signature alongside the commit object, and verification checks that the signed content has not changed and that the public key is trusted for that signer. In practice, the control only holds if the organisation knows which keys are approved, can remove old keys quickly, and can trust the branch protection policy that enforces verification.
Because SSH signing is part of a wider software supply chain trust chain, the same governance issues that affect source provenance and release integrity also apply here. NHIMG’s Software Supply Chain Security Guide is the broader reference for provenance and signing controls around code, builds, and dependencies.
What is actually being signed and verified?
A signed commit covers the commit content itself, including the tree reference, parent reference, author and committer metadata, and the message. If any of that content changes after signing, verification fails. That makes commit signing useful for detecting tampering, accidental rewriting, or pushes that were not authorised by the expected key holder.
SSH commit signing does not protect everything around the repository. It does not prove the code is correct, and it does not prevent a malicious but authorised signer from committing harmful changes. It is best understood as a cryptographic integrity control, not a review substitute.
Git records the public key material needed for verification, so the verifier can confirm the signature against a known key rather than guessing trust from the commit text. That is why key registration, trust decisions, and key revocation are as important as the signing step itself.
Where the control succeeds, and where it can fail
SSH commit signing is strongest when repositories require verified signatures on protected branches and when trusted signing keys are tightly governed. It becomes weaker when keys are shared, copied across laptops, left active after role changes, or accepted without a clear owner. NHIMG’s SSH Key and SSH Certificate Management Guide covers the operational reality of ssh key sprawl, orphaned keys, and rotation.
The usual failure mode is not cryptography breaking, it is trust drift. A stolen laptop, an exposed private key, or an over-broad signing key can allow an attacker to create commits that appear legitimate to downstream reviewers unless branch rules, key inventory, and revocation are enforced. The control is only as strong as the organisation’s ability to remove trust from compromised keys.
Commit signing also sits alongside other repository and delivery pipeline controls. If an attacker can inject code before the signing step, abuse CI/CD permissions, or alter what gets merged, a valid signature on the final commit may still be consistent with a compromised process. NHIMG’s CI/CD Security Guide is relevant because pipeline integrity and commit integrity have to be defended together.
How verification should be used in practice
Verification is most useful when it is enforced automatically, not left to voluntary inspection. Protected branches should reject unsigned or unverified commits, and maintainers should have a clear policy for which keys are trusted for which repos, teams, or release paths. The point is to make signature status an admission control, not just a label in history.
Key lifecycle matters just as much as signing format. If a developer leaves, loses a device, or suspects compromise, the trusted key should be revoked or replaced quickly, and any affected signing paths should be reviewed for misuse. In mature setups, the verification record should be treated as evidence for provenance, not as proof that review or testing happened.
For teams that already manage code signing, SSH commit signing is usually the right fit when developers need a lower-friction way to sign changes without managing a separate PGP workflow. The trade-off is that the organisation must still manage trust in the SSH key lifecycle with the same seriousness it applies to other identity-bearing credentials.
Risk and Threat Considerations
Commit signing reduces the risk of unauthorised source tampering, but it can also create a false sense of security if the signing key itself is stolen or reused across contexts. The highest-value attack path is usually key compromise plus repository trust acceptance, because that turns an access token into apparently legitimate source changes.
Failure mechanism: An attacker obtains a trusted SSH private key, signs malicious commits, and relies on weak branch enforcement or slow key revocation to keep those commits accepted as authentic.
Impact: Malicious code can be introduced with a credible integrity signal, making review and incident reconstruction harder and increasing the chance of downstream supply chain compromise.
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 ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply Chain Levels for Software Artifacts | Commit signing supports provenance and integrity in software supply chains. |
| Recommendation — Adopt provenance checks for source and build artifacts before release. | ||
| CIS Controls v8 | CIS-5 — Account Management | Trusted signing keys depend on controlled ownership, rotation, and removal of dormant access paths. |
| Recommendation — Maintain and regularly review accounts and keys that can sign or approve changes. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | SSH signing keys are authenticator material whose lifecycle must be managed and revoked. |
| AC-6 — Least Privilege | Only approved identities should be able to sign protected source changes. | |
| Recommendation — Manage signing keys through issuance, rotation, protection, and revocation. Restrict commit-signing authority to narrowly scoped, approved signers. | ||
| OWASP ASVS | V11 — Cryptography | Commit signing relies on cryptographic assurance for integrity and authenticity. |
| Recommendation — Use verified cryptographic signatures to protect commit integrity and authenticity. | ||
Practitioner Guidance
What to verify: Confirm that signature verification is enforced at the branch or merge policy layer, not just displayed in the UI. Also verify that trusted keys are owned, named, and removable, with an auditable path for revocation when a developer device or account is lost.
Common mistake: Treating “signed” as equivalent to “safe”. A signed malicious commit is still malicious, so signature checks should complement review, protected branches, and CI/CD hardening rather than replace them.
Practitioner takeaway: SSH commit signing is a provenance control, but it only stays trustworthy when key lifecycle, branch enforcement, and delivery pipeline integrity are governed together.