Every signed commit is a small cryptographic promise: this code came from who it claims to. That promise only holds if the git commit signing tools behind it are configured correctly, enforced consistently, and backed by keys nobody can quietly steal or spoof. Most teams start with one engineer running git commit -S locally, then discover months later that half the repository's history is unsigned, signing keys live unprotected on laptops, and nobody actually checks verification status before merging. This guide walks through what matters when evaluating git commit signing tools and repository integrity verification, then reviews six real options — from classic GPG to keyless Sigstore signing to newer git provenance tools like gittuf — with honest strengths and limitations for each, so you can pick the combination that fits your engineering culture rather than the one that looks best in a vendor deck.
What to Look for in Git Commit Signing Tools
Not all git commit signing tools solve the same problem, so it helps to separate the decision into a few concrete questions before comparing products.
Key custody. Where does the private key live, and what happens when a laptop is lost or an engineer leaves? Tools that support hardware-backed keys (YubiKeys, secure enclaves, platform authenticators) meaningfully reduce the blast radius of a compromised workstation compared to a GPG key sitting in ~/.gnupg.
Developer friction. Signing only works if people actually do it. A workflow that requires memorizing passphrases, managing a web of trust, or fighting a flaky GPG agent will get quietly disabled the first time it blocks a release.
Identity binding. Does the signature prove a cryptographic key was used, or does it prove a specific human identity, tied to your SSO/IdP, made the commit? The latter is a much stronger guarantee and is where keyless approaches have an edge.
Auditability. Can you prove, after the fact, which key signed what and when — including if a key is later revoked or rotated? A public transparency log or an internal audit trail both count; silence does not.
Enforcement Matters as Much as Signing
Signing capability is only half the story. The other half is whether unsigned or invalidly signed commits can actually reach a protected branch. This is where a lot of otherwise reasonable signed commits software rollouts fall apart: the tooling works, but enforcement is optional, inconsistently applied across repositories, or bypassable by anyone with admin rights. Evaluate whether a tool integrates with branch protection rules, required CI checks, or a policy engine that can be centrally managed — not just whether it can produce a valid signature on a developer's machine.
Repository Integrity Verification Goes Beyond the Commit
Commit signing answers "who authored this change," but it doesn't answer "has the history itself been tampered with." Force-pushes that rewrite old commits, branch deletions that erase evidence, and privileged actors quietly altering tags are all outside the scope of per-commit signatures. Real repository integrity verification requires tracking the state of the repository over time — who is authorized to make which kinds of changes, and proof that nothing outside that policy has occurred. This is a newer and less mature space than commit signing itself, but it's increasingly where sophisticated software supply chain attacks actually happen, since attackers who can rewrite history can often erase their own tracks.
Git Commit Signing Tools and Signed Commits Software: A Comparative Roundup
GnuPG (GPG)
GPG is the original and still most widely supported way to sign git commits — it ships with git, works offline, and produces "Verified" badges on GitHub and GitLab out of the box. Its strengths are ubiquity and platform support: nearly every code review tool understands GPG signatures. The limitations are well known too: the UX is genuinely painful (passphrase prompts, agent configuration, expired subkeys), the web-of-trust model confuses more people than it helps, and unless paired with a smartcard or YubiKey, the private key typically sits unprotected on disk — meaning a compromised laptop can mean a compromised signing identity.
Git Native SSH Commit Signing
Since git 2.34, you can sign commits with the SSH key you already use to push code, verified against an allowed_signers file instead of a PGP keyring. It's a significant UX improvement over GPG for teams already standardized on SSH, and pairs well with hardware-backed SSH keys from a YubiKey or a resident key in a password manager's SSH agent. The tradeoff is that SSH signing lacks PGP's built-in revocation and expiry semantics, and distributing the allowed_signers file to every verifier is a manual process each team has to own — there's no equivalent of a public keyserver.
Sigstore (gitsign and cosign)
Sigstore takes a genuinely different approach: keyless signing, where a short-lived certificate is issued after proving identity through your existing OIDC provider (Google, GitHub, or corporate SSO), and every signature is recorded in a public transparency log (Rekor) for later audit. That eliminates long-lived private keys as a target entirely and ties signatures to a verified identity rather than a key file. It's backed by the OpenSSF and already widely used for container and SBOM signing. The catch is that it requires network access to Fulcio/Rekor at sign time, the workflow is unfamiliar to many engineers coming from GPG, and public transparency logs raise legitimate questions for teams working in private repositories who don't want signing metadata exposed externally.
GitHub and GitLab Native Verification and Enforcement
Both major platforms let you require signed commits before merge and surface "Verified" badges directly in the UI (GitHub's vigilant mode, GitLab's push rules), which means many teams don't need extra tooling at all to get baseline enforcement. The limitation is that this protection only covers what happens through the platform's own merge path — it doesn't stop someone with sufficient git access from rewriting history outside that guarded flow, and a "Verified" badge only confirms the signature matches a known key, not that the underlying code is safe. Feature parity between GitHub, GitLab, and Bitbucket also varies more than teams expect.
gittuf
gittuf is a newer, purpose-built repository integrity verification framework built on ideas from in-toto and The Update Framework (TUF). Instead of only checking individual commit signatures, it layers a policy and root-of-trust model over the whole repository to detect unauthorized force-pushes, branch deletions, or history rewrites — the exact gap that pure commit signing leaves open. It's a CNCF-adjacent, academically grounded project, which is a strength for teams that want real integrity guarantees. The honest limitation is maturity: it's a younger project with a smaller community, meaningful setup complexity (root of trust, policy metadata), and CI integrations that are still evolving compared to the decade-plus track record of GPG.
in-toto and SLSA Provenance Attestation
Slightly broader than commit signing, in-toto and the SLSA framework sit in the git provenance tools category — generating verifiable attestations for build and release steps, not just the commit itself, and pairing naturally with Sigstore to sign those attestations. They're backed by the OpenSSF and increasingly referenced by package ecosystems experimenting with provenance requirements. They don't replace git commit signing tools; they complement them by extending verification into the build pipeline. The tradeoff is real engineering investment: instrumenting CI/CD to emit attestations, and the resulting artifacts can be dense to consume without additional tooling to visualize or query them.
How Safeguard Helps
Choosing one of the tools above solves part of the problem; keeping it enforced consistently across every repository, team, and CI pipeline is the part that tends to erode over time. Safeguard sits across your software supply chain to close that gap. Instead of trusting that each repo owner configured branch protection correctly, Safeguard continuously monitors commit signature status — GPG, SSH, or Sigstore-based — across your entire repository fleet and flags drift the moment a repo starts accepting unsigned commits or a signing key changes unexpectedly. It correlates that signal with identity from your existing SSO/OIDC provider, so a "verified" commit means a specific, current employee signed it, not just that some key matched.
Beyond individual commits, Safeguard extends repository integrity verification to the events that per-commit signatures miss entirely: force-pushes, history rewrites, unexpected branch deletions, and privilege changes on protected branches, giving security teams the audit trail that frameworks like gittuf and in-toto are designed to produce, without requiring every engineering team to stand up and maintain that infrastructure themselves. For organizations already generating SLSA or in-toto attestations, Safeguard ingests that provenance data alongside commit-signing status to give one place to answer the question auditors and incident responders actually ask: for this specific change, who made it, was it verified, and has anything about the repository's history changed since. That combination — enforcement, identity binding, and tamper detection in one policy layer — is what turns commit signing from a good intention on individual laptops into a property you can actually demonstrate for the whole organization.