Signed commits and Git supply chain hygiene for platform teams

Unsigned commits trust host identity and stolen session tokens more than cryptographic proof of authorship. When build pipelines read directly from main, every merged change becomes a potential vector for supply chain compromise. Tamper evidence at the commit level provides a verifiable chain of custody from developer workstation to production deployment. Without it, policy enforcement relies on platform trust alone, and that trust is only as strong as the weakest session cookie.

Software supply chain attacks have moved from theoretical risk to documented reality across every major package ecosystem. Compromised maintainer accounts, poisoned dependencies, and unauthorised commits in trusted repositories have caused widespread downstream damage. Signing commits is one foundational control that raises the cost of impersonation and provides forensic evidence when something goes wrong. It does not eliminate risk, but it sharply reduces the attack surface available to credential theft.

Attackers who gain access to a developer account through credential stuffing, token leakage, or social engineering can push commits that appear legitimate on every surface. Without cryptographic signing, there is no way to distinguish a genuine contribution from an impersonation after the fact. The commit author field in Git is self-reported, which means anyone with write access can claim any identity they choose.

SSH-backed signing integrates cleanly with many developers' existing key practices and requires no additional software beyond the Git client itself. Developers who already authenticate to code hosting platforms over SSH can reuse those keys or generate dedicated signing keys with minimal friction. The configuration is straightforward, and major hosting providers now display verification badges for SSH-signed commits, making adoption visible across the team.

GPG remains the standard in regulated environments that already operate formal key ceremonies and maintain internal key servers. Its trust model supports hierarchical certification, which aligns well with organisations that need to express approval chains or tiered authority. The trade-off is higher onboarding complexity and more frequent developer support requests around key expiration, passphrase management, and subkey configuration compared to SSH-based workflows.

Regardless of which signing method you choose, the most important decision is to pick one organisational standard and document it clearly. Mixed environments where some teams use GPG and others use SSH create confusion in verification tooling and complicate policy enforcement. A single onboarding guide that covers key generation, Git configuration, and platform registration reduces friction enough that most developers complete setup within their first day.

Branch protection should require signed commits, passing status checks, and at least one approved review before any merge reaches a release branch. These rules form the first automated gate against unauthorised changes. Bypass lists that allow specific users or service accounts to skip these requirements tend to grow unchecked over time, so audit them quarterly and revoke exceptions that no longer have a documented business justification.

Platform teams should enforce signature verification at the server level, not just as a local developer convention. GitHub, GitLab, and Bitbucket all offer settings that reject unsigned pushes outright or flag them visibly. Treating verification as a server-side gate means a developer who forgets to configure signing will receive an immediate rejection rather than silently merging unsigned work that only surfaces during a later audit.

Merge queues and automation bots need signing identities that are clearly labelled as automation rather than personal accounts that imply human review where none occurred. When a merge bot carries a personal identity, audit logs become misleading and incident investigators lose the ability to distinguish human decisions from automated ones. Dedicated bot accounts with their own signing keys and descriptive names make the provenance of every merge unambiguous.

Managing signing keys for CI systems and automation requires its own lifecycle process. Store bot signing keys in a secrets manager or hardware security module rather than embedding them in pipeline configuration files. Rotate these keys on a defined schedule and ensure that revocation of a bot key does not block the entire release pipeline. A backup key enrolled in advance prevents a rotation from becoming an outage.

Key rotation for developer signing keys requires overlapping trust periods so that commits signed with the previous key remain verifiable while the new key propagates through the organisation. Communicate rotation timelines well in advance and provide clear instructions for updating local Git configuration. Yanking a root key at the end of the working week is a morale event that breeds resentment and shortcuts. Plan rotations during business hours with adequate support coverage.

Revocation planning deserves its own runbook separate from routine rotation. When a developer leaves the organisation or reports a compromised key, you need a documented process to revoke the key on the hosting platform, update the allowed signers file if you maintain one, and audit recent commits signed with that key for anomalies. Speed matters because every hour of delay extends the window for potential misuse of the compromised credential.

Tie signatures to hardware security keys where feasible, as this moves the signing secret off the developer workstation entirely. FIDO2 resident keys and smart cards provide strong protection against malware that might extract private keys from disk. Phishing-resistant multi-factor authentication for code hosting complements signing but does not replace it, because MFA protects the account while signing protects the individual commit. Both layers are necessary for defence in depth.

The distinction between authentication and attestation is worth reinforcing across engineering teams. A strong login protects who can access the repository, but signing answers who authored this specific change. Organisations that invest heavily in single sign-on and conditional access policies sometimes assume those controls are sufficient. They are not, because a compromised session token bypasses login controls entirely while a signing requirement still demands possession of the private key.

Include signature verification as an explicit step in CI for tagged releases, configuration repositories, and any pipeline that modifies production infrastructure. Silent unsigned hotfixes become precedent and erode the policy you worked to establish. When an emergency bypass is genuinely necessary, log it as a formal exception with a post-incident review commitment so the team understands it was a deliberate trade-off rather than a forgotten requirement.

Configuration repositories and infrastructure as code deserve the same signing rigour as application source code, if not more. A single unauthorised change to a Terraform module or Kubernetes manifest can alter network policies, expose secrets, or grant elevated permissions across an entire environment. Treating these repositories as lower priority because they contain no application logic is a common blind spot that attackers are well positioned to exploit.

For organisations subject to compliance frameworks like SOC 2, ISO 27001 or national cloud security schemes (for example the NCA Cloud Cybersecurity Controls in Saudi Arabia and the Dubai Electronic Security Center's Cloud Service Provider Security Standard in the UAE), signed commits provide concrete audit evidence that every change to regulated systems traces back to a verified identity. Automated reports that correlate commit signatures with access reviews and change management tickets reduce the manual effort of preparing compliance artefacts. This evidence is far stronger than screenshots of pull request approvals alone.

Train incident responders to preserve commit metadata during forensics rather than cleaning up history for readability. Rebasing for cleanliness destroys the original commit timestamps, signatures, and parent references that investigators rely on to reconstruct a timeline. Establish a policy that production branches are never force pushed and that forensic copies of suspect repositories are created before any remediation rewriting begins. The audit trail is evidence, not clutter.

Building a signing culture requires more than a policy document and a wiki page. Run hands-on workshops where developers generate keys, configure their Git clients, and make their first verified commit in a sandbox repository. Pair new hires with teammates who can troubleshoot configuration issues in real time. When signing is treated as a team practice rather than a security mandate, adoption tends to be faster and more durable.

Git supply chain hygiene is not a single tool or setting but a layered discipline that connects developer identity, platform policy, automation governance, and incident readiness. Signed commits are the foundation layer because they make authorship verifiable and tamper evidence automatic. Start with a single signing standard, enforce it at the platform level, and expand coverage incrementally until every path to production carries a cryptographic attestation of who approved the change.