「已驗證」提交的缺陷：為何 GitHub/GitLab 在供應鏈安全方面力有未逮

軟體供應鏈攻擊已成為一個重大隱憂，凸顯了在開發各個階段採取強大安全措施的迫切需求。確保程式碼完整性的基本面向之一是提交簽署（commit signing），其目的是驗證變更的作者身份與真實性。然而，在 GitHub 和 GitLab 等主要 Git 平台實施與強制執行提交簽署的方式上，存在著一個關鍵缺口，使得組織容易受到能繞過現有「已驗證」（Verified）標籤的複雜攻擊。

此問題源於平台無法強制執行特定的簽署金鑰，導致攻擊者可以偽裝成合法的、已驗證的提交，將惡意程式碼注入到儲存庫中。本文將探討目前提交簽署保護措施的局限性、流行平台所缺失的功能，以及開發團隊為了彌補這些安全缺陷而承擔的沉重負擔。

「已驗證」提交的幻象

GitHub 和 GitLab 提供「要求簽署提交」（Require signed commits）功能，表面上看，透過確保所有推送到儲存庫的提交都由與提交者帳號關聯的金鑰簽署，似乎增強了安全性。然而，這種保護措施從根本上來說是有缺陷的。如果攻擊者入侵了開發者的筆記型電腦或其 GitHub/GitLab 帳號，他們只需簡單地將一個新的簽署金鑰新增到該帳號中即可。有了這個新的、未經授權的金鑰，攻擊者就可以推送惡意提交，而這些提交仍會獲得夢寐以求的「已驗證」標籤。

這種情境創造了一個巨大的盲點：「已驗證」標籤原本旨在作為信任的標記，卻變成了供應鏈攻擊的潛在媒介。僅依賴此功能的組織會產生一種虛假的安全感，因為惡意程式碼可以無縫地整合進他們的程式碼庫，且看起來完全合法。

平台功能的關鍵缺口

核心問題在於 GitHub 和 GitLab 缺乏細粒度的控制與強制執行機制。具體而言，這些平台目前並未提供：

組織層級的核准簽署金鑰白名單： 組織目前沒有內建方式可以指定並強制執行一份「僅限」核准的簽署金鑰清單（例如，由組織核發的硬體支援 YubiKeys），並允許這些金鑰進行提交簽署。
基於簽署金鑰本身的推送拒絕機制： 平台無法被配置為在提交由不在核准白名單上的金鑰簽署時，自動拒絕該次推送，即使該金鑰與合法用戶帳號關聯。
內建且細粒度的金鑰存取審計： 組織必須自行串流並解析審計日誌，以了解誰存取了什麼，這使得有效偵測未經授權的金鑰新增或使用變得非常困難。

這些缺失的功能意味著，即使啟用了「要求簽署提交」，Git 歷史紀錄的完整性仍可能因單一開發者帳號遭入侵而受到威脅。

目前權宜措施的局限性

面對這些平台限制，許多組織採取了權宜措施，例如：

在持續整合（CI）流水線中重新驗證簽署： 這涉及在 CI 中增加一個步驟，根據內部白名單重新檢查提交簽署。
封鎖部署基於未核准的金鑰： 如果 CI 偵測到由未經授權的金鑰簽署的提交，則停止部署。
自託管 Git 並使用 pre-receive hooks： 在自託管的 Git 實例上實施自定義 hooks，以便在提交進入儲存庫之前強制執行簽署金鑰政策。

雖然這些權宜措施提供了一種程度的偵測或預防，但它們都有一個共同的關鍵缺陷：惡意提交 仍然會進入儲存庫。CI 僅是在事後偵測到它，這意味著受損的程式碼已經被整合進了程式碼庫，即使它被阻止了部署。這種「事後」偵測對於真正的供應鏈安全而言是不夠的，因為真正的目標是防止惡意程式碼進入受信任的儲存庫歷史紀錄中。

組織的負擔

這些基本安全功能的缺失，迫使組織（特別是規模較小的開發團隊）必須投入大量且耗費資源的努力來確保其軟體供應鏈的安全。這包括：

向每位開發者核發硬體安全金鑰（例如，YubiKeys）： 這是一項龐大的物流與財務支出。
建立自定義的驗證與審計流水線： 開發專屬系統來強制執行金鑰政策並監控活動。
將審計日誌串流至安全資訊與事件管理（SIEM）系統： 這需要額外的基礎設施與專業知識來進行日誌分析與告警。
升級至企業級方案以獲得基本的可視性： 這通常會導致更高的成本，以獲取那些本應是標準安全功能的特性。

對於被視為「基本門檻」的安全要求而言，投入如此高昂的成本，是造成極大挫折感的來源，並將資源從核心開發與創新中轉移出去。

對於更好平台支援的呼籲

目前的現狀凸顯了現代開發需求與領先 Git 平台提供的功能之間的嚴重脫節。雖然像 GitHub 這樣的平台在 AI 驅動的編碼助手等功能上投入了重金，而防止「已驗證」供應鏈攻擊的基本安全機制卻仍未解決。組織需要平台提供強大且內建的機制來：

強制執行特定的、由組織核准的簽署金鑰。
在入口處拒絕不符合這些金鑰要求的推送。
提供透明且具備可操作性的金鑰管理與使用審計軌跡。

如果沒有這些功能，單一開發者帳號遭入侵所導致的「已驗證」供應鏈攻擊威脅，對於全球開發團隊而言，仍是一個切實且迫切的關注點。確保 Git 日誌與歷史紀錄的完整性，應是平台供應商的首要任務。