Why Developers Need to Sign Commits: Securing Your Code with Cryptographic Trust

Fahmi Aulia Rahman 5 min read

TL;DR

While signoff commits show you agree to contribute under certain licenses (like DCO), signed commits are about cryptographic security - proving you actually wrote the code and it hasn’t been tampered with. As a developer, signing your commits is like having a digital ID card that can’t be faked, protecting your codebase from impersonation attacks and ensuring code integrity. It’s becoming essential for secure development workflows, especially in open-source and enterprise environments.


Hey fellow devs! 👋 So I recently wrote about why you need to signoff your commits, but there’s another security practice that’s equally important (and often confused with signoff) - signing your commits. As someone who’s been coding for a while and is now dealing with the paranoia that comes with being a new dad (gotta protect everything (hahaha)!), I’ve realized how crucial this is for our code security.

Let me break down why signing commits should be on your radar and how it’s different from that signoff thing we talked about before.

What’s the Deal with Signed Commits?

First off, let’s clear up the confusion - signing commits is not the same as signing off commits as I mentioneded in the previous article:

  • Signoff (git commit -s): Adds a “Signed-off-by” line to your commit message, basically saying “I have the legal right to contribute this code under the project’s license”
  • Signing (git commit -S): Uses cryptographic keys (GPG or SSH) to create a digital signature that proves the commit actually came from you

Think of signoff as signing a legal document, while signing is like having a tamper-proof seal on your code package.

Why Your Code Needs That Digital Signature

1. Anyone Can Pretend to Be You (Seriously!)

Here’s something that might blow your mind - it’s stupidly easy to impersonate someone in Git. All I need to do is run these commands and boom, I’m “you”:

git config user.name "Your Name"
git config user.email "your@email.com"
git commit -m "Definitely not malicious code 😈"

Without signed commits, there’s literally no way to prove that you actually wrote that code. Most VCS has no built-in verification - it just trusts whatever name and email you put in there.

2. Supply Chain Security is No Joke

With all the recent attacks on the software supply chain (remember the npm package incidents?), proving code authenticity has become crucial. Signed commits create an audit trail that shows exactly who contributed what, making it much harder for malicious actors to slip bad code into your project.

3. Code Integrity Protection

When you sign a commit, you’re not just proving authorship - you’re also ensuring the code hasn’t been tampered with after you wrote it. If someone tries to modify your signed commit, the signature becomes invalid, immediately alerting everyone that something’s fishy.

4. That Sweet, Sweet “Verified” Badge

Okay, this one’s a bit superficial, but let’s be real - seeing that green “Verified” badge next to your commits on GitHub/GitLab feels pretty good. It shows professionalism and attention to security details that other developers (and potential employers) notice.

Verified Badge 😜 Verified commit badge 😜 (This is what I’m talking about)

The Security Benefits Are Real

Protection Against Common Attacks

Signed commits protect against several attack vectors:

  • Impersonation attacks: Bad actors can’t pretend to be you
  • Code tampering: Any modification to your commit breaks the signature
  • Replay attacks: Prevents old commits from being reused in different contexts
  • Long-term integrity: Ensures your codebase history remains trustworthy over time

Compliance and Enterprise Requirements

Many organizations now require signed commits for compliance purposes. If you’re working in regulated industries or on projects with strict security requirements, this might not be optional anymore.

Setting It Up (It’s Easier Than You Think!)

GPG Method (Traditional)

  1. Generate a GPG key:
gpg --full-generate-key

# select "RSA and RSA"
# set key size to 4096
# set expiration date to 0 (never expires)
# set your real name, email, and comment
# set passphrase to something secure

# get your key ID
gpg --list-secret-keys --keyid-format=long
# copy your key ID (e.g., 2CD82959455C5802260F1B0FBB76207D7C304E41)

# export your key to a file
gpg --armor --export YOUR_KEY_ID > public_key.asc
  1. Add it to your VCS (GitHub/GitLab) in your SSH and GPG keys settings:

    • GitHub: Settings > SSH and GPG keys > New GPG key
    • GitLab: Settings > SSH keys > Add new key
  2. Configure Git:

git config --global user.signingkey YOUR_KEY_ID
git config --global commit.gpgsign true

SSH Method (Newer and Simpler)

Most VCS (GitHub/GitLab) now support SSH key signing, which is way simpler since most of us already have SSH keys set up:

git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub # or your public key file location
git config --global commit.gpgsign true

The Reality Check

Now, I’m not gonna lie - there are some downsides to consider:

  • Extra complexity: You need to manage keys and remember passphrases
  • Dependency on key infrastructure: If you lose your key, things get complicated
  • Not foolproof: The security is only as good as your key management practices

But honestly? The security benefits far outweigh these inconveniences, especially as the industry moves toward more secure development practices.

When Should You Sign Commits?

  • Always, if you’re working on open-source projects
  • Definitely, if you’re in a security-sensitive environment
  • Probably, if you want to show you take code security seriously
  • Consider it, even for personal projects (good habits start early!)

The Difference from Signoff (One More Time)

Just to hammer this home since I feel my self is confusing at first:

Signoff (-s)Signing (-S)
Legal agreement to contributeCryptographic proof of authorship
Adds text to commit messageAdds digital signature
Anyone can add/fake itRequires private key
No verification badgeGets “Verified” badge on VCS
Required by some projects (DCO)Security best practice

Summary

Signing your commits is becoming a standard security practice in modern development. It’s not just about getting that green badge (though that’s nice too) - it’s about building trust, ensuring code integrity, and protecting against increasingly sophisticated attacks on our software supply chain.

As developers, we need to level up our security game, and commit signing is a relatively easy win that provides significant protection. Plus, once you set it up, it’s mostly automatic.

The future of secure coding is here, and it includes cryptographically signed commits. Better to get on board now than scramble to implement it when your organization suddenly requires it (trust me, it’s coming).

Stay secure, fellow devs! 🔒✨


References

Signed commits - Equinor

What is the difference between git commit -S and -s? - Stack Overflow

Signing Git Commits with GPG and SSH: A Complete Guide

How (and why) to sign Git commits - With Blue Ink

Setting Up GPG Commit Verification for GitHub

Securing Git Commits: Why GPG Signing is Essential for Protecting Your Codebase

Code Integrity Unleashed: The Crucial Role of Git Signed Commits

Enhancing Git Security and Workflow: A Comprehensive Guide to Signed Commits

Why You Should Start Signing Your Git Commits Today - Xebia

Why we have to sign the commit

What is a GPG key and why should I sign my commits? - GitHub Community

Strengthen code security with signed commits - Atlassian

How to sign your git commits

Unsigned Commits

About the author

Portrait of Fahmi Aulia Rahman

Fahmi Aulia Rahman

Software Engineer

Software engineer with 6+ years under the hood with new dad vibes — shipping cool stuff, learning out loud and keeping it real.