Supply Chain · Repository Security

MCP server signed commits security

Git's author and committer fields are not cryptographically verified — anyone can set git config user.email to any value and push commits that appear to be from a trusted maintainer. For public MCP server repositories, this creates a backdoor insertion risk: a compromised contributor account, a social engineering attack, or a misconfigured CI token can add malicious code that appears to come from the project's most trusted contributor.

The impersonation risk for MCP server maintainers

When a community developer installs your MCP server, they are trusting every commit in your history. If any of those commits were made by an attacker impersonating you — by cloning the repo, modifying code, and force-pushing with your email set in their local git config — there is no way to detect this without commit signing.

The risk is concrete in three scenarios:

Contributor account compromise: An attacker who gains access to a GitHub account with write access can push commits impersonating any project maintainer.
CI token exfiltration: A misconfigured CI pipeline that exposes the GitHub token can be used to push commits that appear to come from the CI service but contain attacker-injected code.
Social engineering: A trusted-looking PR from a new contributor that introduces a subtle backdoor, made to look like a refactor.

Commit signing with GPG or SSH creates a cryptographic proof that each commit was made by someone with access to the private key associated with a verified email address. Without the private key, no one can forge that signature.

Setting up GPG commit signing

# Generate a GPG key (use RSA 4096 or Ed25519)
gpg --full-generate-key

# List your keys, find the key ID
gpg --list-secret-keys --keyid-format=long

# Export the public key and add to GitHub (Settings → SSH and GPG keys)
gpg --armor --export YOUR_KEY_ID

# Configure git to sign all commits automatically
git config --global user.signingkey YOUR_KEY_ID
git config --global commit.gpgsign true
git config --global tag.gpgsign true

# Verify your signing is working
git commit --allow-empty -m "test: verify commit signing"
git log --show-signature -1

Setting up SSH commit signing (simpler, recommended for new setups)

# Use your existing SSH key (or generate one)
ssh-keygen -t ed25519 -C "your-email@example.com"

# Add the public key to GitHub as a signing key (not just auth key)
# GitHub Settings → SSH and GPG keys → New signing key

# Configure git to use SSH for signing
git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true

# Verify
git commit --allow-empty -m "test: verify SSH commit signing"
git log --show-signature -1

Enforcing required signing in GitHub

Commit signing is only meaningful as a supply chain control if it is required — optional signing means unsigned commits still pass. Enable required signing via GitHub branch protection rules:

Repository Settings → Branches → Branch protection rules → Edit → Enable "Require signed commits"

With this rule enabled, GitHub rejects any push to the protected branch (main/master) that includes unsigned commits. CI pipelines that push directly must also sign commits, which requires a signing key to be available in the CI environment.

GitHub Vigilant Mode for consumers

Consumers of public MCP servers can enable GitHub's Vigilant Mode (GitHub Settings → SSH and GPG keys → "Flag unsigned commits as unverified") to see a visual indication on every commit in every repository they browse. Commits without a verified signature appear with an "Unverified" badge, providing a quick signal for consumers evaluating whether to trust a repository's history.

Signed commits do not prevent all supply chain attacks — they only verify that a commit was made by someone with the private key, not that the change itself is safe. Combine commit signing with code review requirements (required PR approvals, CODEOWNERS), dependency lockfile enforcement, and automated security scanning for a complete supply chain defense posture.

SkillAudit findings

HIGH No commits in recent history are GPG or SSH signed — repository provides no cryptographic commit attribution

MEDIUM Commit signing not required by branch protection — unsigned commits can be pushed to main

MEDIUM CI pipeline pushes unsigned commits — CI-generated commits appear unverified in history

Run a SkillAudit scan to check your repository's commit signing posture. SkillAudit checks recent commit signature presence, branch protection rules, and CI commit signing configuration. See also: MCP server supply chain risk and MCP server supply chain audit.