GitHub Verified Commits Can Be Spoofed via Signature Malleability
GitHub's commit verification system fails to normalize cryptographic signatures before validation, allowing attackers to craft a new commit with an identical author, date, and file tree but a different hash that still receives the 'Verified' badge. This undermines any pipeline or security control that relies on commit hashes as a trustworthy, immutable identifier for provenance or deduplication. The flaw is particularly dangerous in CI/CD and software supply chain contexts where 'Verified' status is used as a gate for deploying or trusting code. Trust in cryptographic verification controls must be built on rigorous, well-specified implementations — not assumed based on a UI badge alone.
Tactical Insight
Immediate actions
- Audit all CI/CD pipelines that use GitHub's 'Verified' badge as a sole trust signal and add secondary integrity checks.
- Replace reliance on commit hashes alone with artifact signing tools such as Sigstore or GPG-signed tags pinned to a known-good key.
Long-term improvements
- Implement a Software Bill of Materials (SBOM) workflow that records and validates artifact provenance at every stage of the build pipeline.
- Enforce branch protection rules requiring signed commits from allowlisted keys, not just the presence of GitHub's 'Verified' label.
- Integrate reproducible build practices so that the same source always produces the same binary output, enabling independent verification.
Detection measures
- Enable audit logging on all repository events and alert on commits that share identical metadata (author, date, tree) but differ in hash.
- Continuously monitor supply chain security tooling (e.g., Dependabot, GitHub Advanced Security) for anomalous commit patterns or unexpected changes to protected branches.