Table of Contents
By Khimananda Oli | Last reviewed: August 2026
Software supply chain attacks have shifted from compromising build servers to impersonating maintainers via unsigned or forged commits. To prevent this, you must sign commits with GPG and SSH for supply-chain trust, creating a cryptographic link between code changes and verified identities. This practice ensures that every merge request and release tag can be mathematically attributed to an authorized developer, forming the bedrock of audit-ready infrastructure and compliance frameworks like SOC 2.
gpg.format and user.signingkey, and enforce signature verification in your CI pipeline. SSH signing offers simpler key reuse, while GPG provides stronger identity attestation for compliance audits.Why should you sign commits with GPG and SSH for supply-chain trust?
Identity spoofing remains one of the most persistent vectors in software supply chain compromises. An attacker who gains write access to a repository can craft commits with arbitrary author metadata, making malicious code appear to originate from a trusted maintainer. Cryptographic signing eliminates this ambiguity by binding each commit to a private key that only the legitimate owner possesses.
Beyond security, regulatory and customer-driven compliance increasingly demands provenance. During SOC 2 Type II audits, I frequently encounter findings related to "unverified code changes." Auditors want evidence that production deployments trace back to approved, authenticated sources. When you implement CI/CD best practices alongside mandatory signing, you create an immutable chain of custody. This satisfies control objectives around change management and logical access without adding manual approval bottlenecks.
For teams operating in regulated environments or handling sensitive data, unsigned commits represent an unacceptable risk surface. The cost of implementing signing is negligible compared to the forensic effort required to investigate a compromised repository or explain unverified changes during a compliance review.
How do you configure Git to sign commits with GPG and SSH keys?
Modern Git supports both GPG and SSH as signing formats. While GPG has been the historical standard, SSH signing (available since Git 2.34) allows you to reuse existing authentication keys, reducing key management overhead. However, GPG retains advantages for cross-platform identity certification and integration with hardware tokens.
Generating an ED25519 signing key
For new deployments in 2026, ED25519 is the recommended algorithm due to its speed and compact signatures. Avoid RSA keys shorter than 4096 bits and deprecated SHA-1 hashes.
# Generate an ED25519 SSH key specifically for signing
ssh-keygen -t ed25519 -C "[email protected]" -f ~/.ssh/git_signing_key
# Or generate a GPG key with modern defaults
gpg --full-generate-key --pinentry-mode loopback
# Select: (1) RSA and ECC → (9) ECC (sign only) → Curve 25519
# Set expiration to 2y maximum for rotation hygieneConfiguring Git globally or per-repository
Once generated, register the key with Git. For SSH signing, use the public key path; for GPG, use the key fingerprint.
# SSH signing configuration
git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/git_signing_key.pub
git config --global commit.gpgsign true
# GPG signing configuration (alternative)
git config --global gpg.format openpgp
git config --global user.signingkey FINGERPRINT_HERE
git config --global commit.gpgsign trueA common mistake is forgetting to add the public key to your hosting platform. GitHub, GitLab, and Bitbucket all require you to upload the signing public key separately from your authentication key. Without this step, commits will be signed locally but show as "Unverified" on the web interface, defeating the purpose of establishing trust.
GPG vs SSH signing: Which method fits your security model?
Choosing between GPG and SSH depends on your team's operational maturity, compliance requirements, and existing infrastructure. Both achieve the core goal when you manage keys securely, but they differ significantly in administration overhead and ecosystem support.
| Criteria | GPG Signing | SSH Signing |
|---|---|---|
| Key Management | Separate keyring; requires gpg-agent | Reuses existing SSH keys; simpler |
| Hardware Token Support | Mature (YubiKey, Nitrokey) | Limited; emerging in 2026 |
| Identity Attestation | Web of Trust / CA signatures | Tied to hosting platform account |
| Cross-Platform Tooling | Requires GnuPG installation | Native OpenSSH everywhere |
| Audit & Compliance | Stronger non-repudiation evidence | Sufficient for most SOC 2 controls |
| Rotation Complexity | Higher; subkeys help mitigate | Lower; standard SSH rotation |
In my practice, I recommend SSH signing for internal engineering teams prioritizing velocity and low friction. Reserve GPG for release managers, open-source maintainers, or environments requiring hardware-backed non-repudiation. If your organization already uses HashiCorp Vault for secrets management, consider integrating it with GPG agent forwarding to centralize key operations without exposing private material to developer workstations.
How do you automate signature verification in CI pipelines?
Signing alone does not guarantee trust; you must verify signatures at enforcement points. A signed commit pushed to a repository that accepts unsigned merges provides false assurance. In 2026, effective supply-chain security requires automated verification gates in your CI system and branch protection rules.
- Enable branch protection: Configure your VCS to require signed commits on protected branches (main, release/*). Reject pushes that lack valid signatures.
- Add CI verification jobs: Even with branch protection, run explicit verification in pipelines to generate audit artifacts. Use
git log --show-signatureor dedicated tools likesigstore/gitsignfor structured output. - Fail fast on invalid signatures: Treat missing or expired signatures as pipeline failures, not warnings. This prevents drift where developers bypass signing during emergencies.
- Log verification results: Store signature metadata (key ID, timestamp, signer email) in your centralized logging system. This creates the evidence trail auditors expect.
# Example GitLab CI job for signature verification
verify-signatures:
stage: validate
script:
- apk add --no-cache gnupg openssh-client
- git fetch --unshallow
- |
INVALID=$(git log origin/main..HEAD --format="%H %G?" | grep -v "G$" || true)
if [ -n "$INVALID" ]; then
echo "::error::Unsigned or invalid commits detected:"
echo "$INVALID"
exit 1
fi
allow_failure: falseThis approach aligns with infrastructure-as-code principles where policy is codified rather than enforced through tribal knowledge. When verification is part of the pipeline definition, it survives team turnover and scales across repositories.
What are the operational pitfalls when managing signing keys?
The most frequent failure mode I observe is not technical misconfiguration but operational neglect. Keys expire, developers leave, laptops fail, and suddenly teams cannot sign releases or verify historical commits. Proactive lifecycle management prevents these outages.
Key expiration and rotation: Set reasonable expiration dates (1–2 years) and establish rotation procedures well before expiry. For GPG, use subkeys for signing while keeping the master key offline. This limits blast radius if a signing key is compromised. Document the rotation runbook and test it quarterly.
Revocation planning: Generate revocation certificates immediately after key creation and store them securely offline. If a developer departs unexpectedly or a device is lost, you must be able to revoke the key within hours, not days. Integrate revocation checks into your offboarding checklist.
Local agent configuration: Developers often struggle with GPG agent timeouts or pinentry programs failing in headless environments. Standardize agent configuration across the team using dotfiles or configuration management. For SSH signing, ensure ssh-add includes the signing key in CI runners and developer machines alike.
Backup without exposure: Never back up private signing keys to cloud storage unencrypted. Use encrypted USB drives or hardware security modules for backups. The goal is recovery capability without expanding the attack surface. If you cannot recover a key securely, accept that you will need to rotate and re-sign critical tags.
Establishing Verified Trust Across Your Engineering Organization
Implementing cryptographic signing is a foundational step toward a verifiable software supply chain, but technology alone does not sustain trust. Success requires embedding these practices into onboarding, code review culture, and compliance documentation. Start with a pilot team, refine your key distribution and verification automation, then expand with documented standards. Monitor adoption metrics and treat unsigned commits as incidents until the behavior is universal.
If your team needs guidance on integrating commit signing into existing CI/CD workflows, preparing for SOC 2 audits, or designing a key management strategy that balances security with developer experience, reach out to discuss your specific infrastructure challenges. Building supply-chain trust is an investment that compounds over time — start signing today so your future self isn't explaining unverified commits to an auditor tomorrow.
