As reported by The Hacker News, newly published research exposes a structural weakness in how Git commit signing is implemented — one that calls into question a foundational assumption underpinning modern software supply chain security: that a verified commit is a unique, tamper-evident artifact.
The Core Problem: Signatures Prove Authorship, Not Uniqueness
This finding deserves careful framing, because it is easy to either overstate or dangerously understate the risk. What the research demonstrates is not a flaw in GPG, SSH, or cryptographic signing itself. It is a flaw in how developers, reviewers, and security tooling interpret that verification badge.
Git commit hashes are SHA-1 or SHA-256 digests of a specific blob of metadata — parent hashes, tree state, timestamps, author fields, and the commit message. The cryptographic signature covers the content a signer chose to sign. But the hash itself is not what was signed. This creates a gap: an attacker with knowledge of the original commit's contents can construct a second commit object that satisfies the signature verification check while producing a completely different hash.
The implication: Two commits can exist — one legitimate, one adversarially crafted — both displaying GitHub's green "Verified" badge, with identical visible metadata, but divergent commit hashes. Any security control or audit log keyed to the hash will see two different objects. Any human reviewer checking the badge will see the same green checkmark.
Why This Matters for Supply Chain Security
The software industry has invested heavily in commit signing as a supply chain integrity control, particularly post-SolarWinds. Organizations implementing SLSA, SSDF, or executive order-aligned DevSecOps frameworks frequently cite signed commits as a provenance guarantee. This research suggests those guarantees have a meaningful blind spot.
Specific threat scenarios worth considering:
Who Is Most Exposed?
Organizations at greatest risk are those who have deployed commit signing as a terminal trust control rather than one layer in a defense-in-depth strategy. This includes:
- Open source projects with large contributor bases where commit provenance is a primary trust signal
- Enterprises using GitHub Advanced Security or similar tooling where "Verified" status drives merge permissions
- Any team using signed commits as the primary input to SLSA Level 2+ provenance claims
- CI/CD pipelines that log commit hashes for compliance purposes but verify signatures at runtime
Shield53 Recommendations
Immediate Actions
- Never treat the Verified badge as a uniqueness guarantee. Retrain developers and security reviewers: a green checkmark means the content was signed by the expected key, not that this is the only commit that could carry that signature.
- Pin to hashes AND verify signatures independently. Your pipeline should record both the commit hash and the signature verification result as separate, independently validated fields. Discrepancies between expected and observed hashes should trigger alerts even when signatures pass.
- Audit your SBOM and provenance tooling. Determine whether your tools anchor provenance claims to commit hashes, signature metadata, or both. Treat hash-only anchoring as a gap.
- Implement binary artifact signing at build time. Sigstore/Cosign and similar tools that sign the built artifact — not just the source commit — provide a stronger chain of custody than commit signatures alone.
Longer-Term Strategic Guidance
- Engage your GitHub Enterprise or platform team to understand whether repository rulesets or push protections can enforce hash consistency checks in addition to signature verification.
- Re-evaluate SLSA provenance claims in your documentation and vendor attestations. If commit signing is cited as a SLSA control, it may need to be supplemented.
- For high-assurance repositories, consider requiring that merge commits be reproducibly built and that build hashes are attested alongside commit hashes.
The Bigger Picture
This research is a timely reminder that security badges and UI affordances are powerful — sometimes dangerously so. GitHub's "Verified" label was designed to communicate cryptographic authenticity. It was never designed to communicate uniqueness or non-duplicability. The gap between what the control technically provides and what practitioners assume it provides is where real-world attacks live.
The software supply chain security community needs to move past treating any single indicator as a sufficient trust signal. Layered, independently verifiable provenance — spanning source, build, and artifact — is the only architecture that holds up under adversarial scrutiny.
