```
A new security disclosure challenges a core assumption in modern software development: that a signed Git commit's hash is a unique, immutable identifier. Researchers have demonstrated that any signed commit can be duplicated into a new commit with a different hash while preserving all authorship, file content, and a valid cryptographic signature. This clone will still receive GitHub's "Verified" badge, undermining the trust model many automated systems rely on.
The technique exploits a design characteristic of Git, not a flaw in its cryptographic signing. A signature is generated based on the commit's content blob and metadata, but crucially, the reference to the parent commit can be altered. Changing this parent link creates a new commit hash (SHA) while leaving the original signature cryptographically valid for the content it covers.
As a result, all the checks a human reviewer might perform—valid signature, correct author, matching date, and identical files—are satisfied. The only difference is the commit hash itself. This has serious implications for software supply chain security.
The primary risk targets automated processes that use pinned commit hashes as trusted, immutable references. This common practice is seen in dependency files like go.mod and package-lock.json, as well as in GitHub Actions workflows where a uses: directive points directly to a specific commit hash. An attacker could create a malicious "shadow commit" containing harmful code but mimicking the original metadata and signature. By substituting the pinned hash in a repository, the attack would bypass standard signature verification, potentially introducing malware while all automated checks appear successful.
"This isn't a vulnerability in signing keys, but a fundamental misunderstanding of Git's trust model among many developers," the research analysis explains. "The 'Verified' badge attests to a signature's validity, not to the hash's uniqueness or the commit's place in history."
In response, security experts are urging an immediate change in verification protocols. Developers and organizations should no longer treat the "Verified" badge or a signed commit hash as standalone proof of provenance. Instead, verification must explicitly check the commit's lineage within the repository's Directed Acyclic Graph (DAG).
"For immediate protection, teams must update internal security protocols, code review processes, and CI/CD validation scripts," the guidance states. "In dependency pinning and Actions workflows, validation should verify the parent commit reference to ensure the hash points to the expected history, not just the signature."
Long-term solutions involve platform and tooling evolution. Researchers recommend that providers like GitHub enhance their verification interfaces to better distinguish between cryptographic signature validity and hash uniqueness. This could involve augmenting the "Verified" badge with DAG context or adding a separate lineage indicator. The broader developer tooling ecosystem, including linters and security scanners, is also called to integrate automated lineage checks as a standard part of verification.
The disclosure leaves several critical questions for the industry to resolve. How will platforms redesign their UIs to clearly communicate this nuanced trust model? What specific changes are required in common developer tools to automate lineage verification? Will standards bodies, such as the Git community or the Open Source Security Foundation (OpenSSF), publish formal guidance to address hash malleability?
This finding serves as a pivotal reminder that cryptographic signatures are a necessary but insufficient component of supply chain trust. True assurance of code provenance requires verifying the entire context and history of a change, not just the cryptographic seal on a single snapshot.
一項新的安全披露挑戰了現代軟件開發的一個核心假設：簽署過的Git提交雜湊值是獨一無二且不可變更的識別碼。研究人員已證實，任何已簽署的提交都可以被複製成一個具有不同雜湊值的新提交，同時保留所有作者資訊、檔案內容及有效的加密簽名。這個複製品仍然會獲得GitHub的「已驗證」徽章，從而削弱了許多自動化系統所依賴的信任模型。
此技術利用的是Git的設計特性，而非其加密簽名存在漏洞。簽名是基於提交的內容物件和中繼資料生成的，但關鍵在於，指向父提交的參照可以被更改。更改這個父提交連結會產生一個新的提交雜湊值（SHA），同時使原始簽名對其所涵蓋的內容在加密意義上仍然有效。
因此，一個人工審核員可能進行的所有檢查——有效的簽名、正確的作者、匹配的日期和相同的檔案——都將滿足。唯一的區別在於提交雜湊值本身。這對軟件供應鏈安全具有嚴重影響。
主要風險針對的是那些使用固定提交雜湊值作為可信、不可變參照的自動化流程。這種常見做法見於依賴檔案如 go.mod 和 package-lock.json，以及GitHub Actions工作流程中，其中 uses: 指令直接指向特定的提交雜湊值。攻擊者可以創建一個包含惡意代碼但模仿原始中繼資料和簽名的惡意「影子提交」。通過替換倉庫中固定的雜湊值，攻擊將繞過標準簽名驗證，可能在所有自動化檢查看似成功的情況下引入惡意軟件。
「這不是簽名密鑰的漏洞，而是許多開發者對Git信任模型的根本誤解，」研究分析解釋道。「『已驗證』徽章證明的是簽名的有效性，而非雜湊值的唯一性或提交在歷史中的位置。」
為此，安全專家敦促立即更改驗證協議。開發者和組織不應再將「已驗證」徽章或已簽署的提交雜湊值視為來源真實性的獨立證明。相反，驗證必須明確檢查提交在倉庫有向無環圖（DAG）中的譜系。
「為了立即提供保護，團隊必須更新內部安全協議、代碼審查流程和CI/CD驗證腳本，」指引指出。「在依賴固定和Actions工作流程中，驗證應檢查父提交參照，以確保該雜湊值指向預期的歷史，而不僅僅是簽名。」
長期解決方案涉及平台和工具的演進。研究人員建議GitHub等提供者增強其驗證介面，以更好地區分加密簽名的有效性和雜湊值的唯一性。這可以通過在「已驗證」徽章中增加DAG上下文或添加單獨的譜系指標來實現。更廣泛的開發者工具生態系統，包括代碼檢查工具和安全掃描器，也被呼籲將自動化譜系檢查作為驗證的標準部分。
此次披露給業界留下了幾個亟待解決的關鍵問題。平台將如何重新設計其用戶界面，以清晰傳達這一複雜的信任模型？常見開發者工具需要哪些具體更改來實現自動化譜系驗證？標準組織，例如Git社區或開源軟件安全基金會（OpenSSF），會否發布正式指引來解決雜湊值可變性問題？
這項發現作為一個關鍵提醒：加密簽名是供應鏈信任的必要但非充分組成部分。真正確保代碼來源的真實性，需要驗證變更的完整上下文和歷史，而不僅僅是對單一快照的加密封印。