Q: Your company is enforcing supply-chain integrity. The CISO wants every commit on `main` to have a verifiable author and to be tamper-evident. How do you implement this, and what attack does it actually prevent?

By default, Git's Author and Committer headers are unauthenticated free-text — anyone can run git config user.email "ceo@company.com" and produce commits that look like the CEO. Signing fixes that with cryptographic proof.

• Signing keys per developer. Either GPG (traditional) or SSH signing (Git ≥ 2.34, much simpler — reuse the SSH key engineers already have):
• Allowed-signers file mapping email → public key, distributed via your IDP / SSO so trust is centralized, not per-laptop.
• Upload the public key to GitHub/GitLab under "Signing key." Now the platform shows a "Verified" badge and exposes verification status via the API.
• Branch protection on main — require signed commits, require linear history, require status checks. Block merges where any commit is unsigned.
• CI verification — a pre-merge job that runs git verify-commit against each commit in the PR, failing if any commit isn't signed by a key in the allowed-signers list. Don't rely solely on the platform UI badge.
• CODEOWNERS to require domain-expert review on sensitive paths (e.g. /infra/, /auth/, CI workflows themselves).

Implementation: What this actually prevents: **What it does *not* prevent:** Signing answers "who wrote this commit?" with cryptography. It does not answer "is this code safe?" — that's a separate problem.

git config --global gpg.format ssh
   git config --global user.signingkey ~/.ssh/id_ed25519.pub
   git config --global commit.gpgsign true
   git config --global tag.gpgsign true

• Author spoofing — an attacker who compromises one developer's laptop can no longer forge commits as a different developer (different key).
• Tampering with merged history — if someone with repo-admin access tries to silently rewrite a past commit, the signature on the original commit chain breaks and CI rejects it.
• Compromised CI tokens pushing arbitrary code as humans — unsigned commits are blocked, so a leaked PAT can't ship merge-able changes without a key.
• A compromised developer laptop with their key on it — the attacker's commits will sign correctly. Mitigations: hardware-backed keys (YubiKey for GPG, or SSH keys in ssh-agent with confirmation), short-lived keys via SSO-issued certificates, and behavioral monitoring.
• Malicious code that's *legitimately* authored and signed (insider threat, social-engineered review). That's what CODEOWNERS, mandatory review, and SCA tooling are for.