In August 2022, a researcher demonstrated that they could create commits on GitHub that appeared to come from any user — including Linus Torvalds, GitHub's CEO, or any maintainer of a target project. The technique exploited a fundamental property of Git: anyone can set the author and committer fields of a commit to any value. GitHub displays these values without independent verification for unsigned commits.
This wasn't a new discovery, but it highlighted an attack vector that the software supply chain community has consistently underestimated: malicious commits that exploit trust in the code review and merge process.
The Committer Spoofing Problem
Git commits contain two identity fields: author and committer. These are configured locally by each developer and are not verified by Git or, for unsigned commits, by GitHub. A developer can configure their Git client to set these fields to any name and email address:
git config user.name "Trusted Maintainer"
git config user.email "maintainer@project.org"
Commits made with these settings will display as coming from "Trusted Maintainer" on GitHub. For unsigned commits, there is no cryptographic proof of identity — the displayed name is purely self-asserted.
This creates several attack scenarios:
Scenario 1: Impersonation in Pull Requests
An attacker forks a repository, makes malicious changes with commits attributed to a trusted maintainer, and submits a pull request. Reviewers seeing familiar names in the commit history may apply less scrutiny.
Scenario 2: Direct Push Impersonation
If an attacker gains write access to a repository (through account compromise, leaked tokens, or insider threat), they can push commits attributed to any team member, making forensic analysis more difficult.
Scenario 3: Poisoned Dependency Commits
An attacker targets a less-maintained dependency in a project's supply chain. By submitting a PR with commits that appear to come from known contributors, they increase the likelihood that the malicious change is accepted.
Beyond Spoofing: PR-Based Attack Patterns
Committer spoofing is one piece of a broader set of attack patterns targeting the code review process:
The "Helpful Fix" Attack
An attacker submits a pull request that fixes a real bug — and also introduces a subtle backdoor. The fix is legitimate and passes review, while the malicious change is hidden in a larger diff or in an area that reviewers are less familiar with.
This is exactly how the event-stream attack worked in 2018: the attacker first established credibility as a helpful contributor before introducing malicious code.
The Review Fatigue Attack
Large, complex pull requests are harder to review thoroughly. An attacker submits a PR with hundreds of lines of legitimate changes and a few lines of malicious code buried in the middle. Reviewers experiencing fatigue or time pressure may approve the PR without catching the malicious change.
The Dependency Update Attack
A PR that "updates dependencies to fix vulnerabilities" is typically approved quickly because it appears to be a security improvement. An attacker can include a dependency change that introduces a malicious package alongside legitimate updates.
The CI/CD Configuration Attack
Modifying CI/CD configuration files (.github/workflows/*.yml, .travis.yml, Jenkinsfile) can introduce build-time attacks that don't appear in the application code itself. These files are often reviewed with less scrutiny than application code.
Real-World Incidents
The Linux Kernel Hypocrite Commits (2021)
Researchers from the University of Minnesota submitted intentionally buggy patches to the Linux kernel to study the review process. While not malicious in intent, the incident demonstrated that even the Linux kernel's famously rigorous review process could miss subtle, intentionally-introduced vulnerabilities.
The PHP Self-Hosted Git Server Compromise (2021)
In March 2021, attackers pushed malicious commits to the PHP project's self-hosted Git server, with the commits attributed to known PHP maintainers Rasmus Lerdorf and Nikita Popov. The commits attempted to add a backdoor to the PHP source code. The attack was caught quickly, but it prompted PHP to move its canonical repository to GitHub.
The node-ipc Maintainer Sabotage (2022)
While not a commit impersonation attack, the node-ipc incident demonstrated that even legitimate maintainers can introduce malicious code through normal commit and publish processes.
Defenses
Require Signed Commits
The most direct defense against committer spoofing is requiring signed commits. GPG-signed or SSH-signed commits include a cryptographic signature that GitHub can verify against the signer's registered key.
GitHub displays a "Verified" badge on signed commits. Organizations can configure branch protection rules to require signed commits, rejecting any unsigned commit.
However, signed commits don't prevent maintainers themselves from introducing malicious code — they only prove that the commit actually came from the claimed author.
Branch Protection Rules
GitHub's branch protection rules provide several relevant controls:
- Require pull request reviews: Prevent direct pushes to protected branches
- Require review from Code Owners: Ensure that changes to specific areas are reviewed by domain experts
- Require status checks: Ensure that CI/CD checks pass before merging
- Require signed commits: Only allow verified, signed commits
- Dismiss stale reviews: Require re-review when a PR is updated after approval
Automated Code Analysis
Static analysis tools can catch certain classes of malicious code:
- Secret detection: Tools like truffleHog and git-secrets catch hardcoded credentials
- Vulnerability patterns: SAST tools can identify dangerous patterns like command injection or deserialization
- Behavioral analysis: Tools that analyze code behavior (network connections, file system access, process execution) can flag suspicious patterns
Review Process Discipline
Technical controls are necessary but not sufficient. Review culture matters:
- Review every line. Don't approve PRs based on the commit message or the PR description alone.
- Review CI/CD changes with extra scrutiny. Build system modifications are high-risk.
- Limit PR size. Large PRs should be split into reviewable chunks.
- Don't rush security fixes. "Urgent" PRs that pressure reviewers to merge quickly are a social engineering vector.
- Require multiple reviewers for sensitive areas. Critical components should require sign-off from multiple team members.
Commit Monitoring
Monitor repositories for unusual commit patterns:
- Commits from new or unexpected contributors
- Commits that modify CI/CD configuration alongside application code
- Large commits that touch many files across multiple subsystems
- Commits that add new dependencies or modify dependency configurations
The Git Signing Landscape in 2022
As of mid-2022, several options existed for signing Git commits:
GPG signing: The traditional approach, supported by Git for years. Requires managing GPG keys, which has a reputation for poor developer experience.
SSH signing: Added in Git 2.34 (November 2021), SSH signing uses existing SSH keys, which developers already have. This significantly lowers the barrier to adoption.
Gitsign (Sigstore): Keyless commit signing using Sigstore. Developers authenticate via OIDC, and the signing certificate is recorded in the Rekor transparency log. No key management required.
Each option has tradeoffs, but the availability of SSH signing and Gitsign significantly reduced the friction that previously prevented widespread commit signing adoption.
How Safeguard.sh Helps
Safeguard.sh monitors your source code repositories for supply chain risks including suspicious commit patterns, unauthorized changes to build configurations, and unsigned commits in protected branches. Our platform integrates with GitHub to enforce commit signing policies, flag unusual contribution patterns, and ensure that code review processes are consistently applied. By treating the commit and review process as part of the supply chain, Safeguard.sh helps catch malicious contributions before they reach production.