許多開發者在撰寫 GitHub Actions 工作流時，為了方便管理，習慣使用版本標籤（例如 v1.0.0）來引用第三方 Action。然而，近期發生的一起供應鏈攻擊事件揭露了這種做法的潛在風險。攻擊者透過一種稱為 Imposter Commit（偽裝提交）的手法，成功將惡意代碼植入知名 Action 中，藉此竊取企業 CI/CD 流程中的敏感憑證。
理解 Imposter Commit 的運作原理
在正常的 Git 操作中，標籤（Tag）應該指向一個特定的提交紀錄（Commit）。但這次攻擊的核心在於，攻擊者將儲存庫中的所有現有標籤，重新導向到一個偽裝提交（Imposter Commit）。
所謂的偽裝提交，是指攻擊者在一個由其控制的 Fork（分支副本）中建立惡意提交，然後讓原儲存庫的標籤指向這個外部提交。由於這個提交並不存在於原儲存庫的正常歷史紀錄中，它能有效地繞過標準的 Pull Request（PR）審核機制，讓惡意代碼在沒有經過任何團隊審查的情況下，直接進入執行環境。
惡意代碼的執行路徑與影響
當開發者的 CI/CD 流水線執行到被污染的 Action 時，惡意代碼會在 GitHub Actions Runner（執行工作流的虛擬機環境）中啟動。其攻擊流程分為三個階段：
首先，它會在 Runner 中下載 Bun（一個高效能的 JavaScript 執行環境），用來執行後續的攻擊腳本。
接著，它會嘗試讀取 Runner.Worker 進程的記憶體。這是一個極其危險的動作，因為 CI/CD 環境中通常存放著許多敏感資訊，例如 GitHub Tokens、雲端平台金鑰（AWS/Azure/GCP Keys）或資料庫密碼，這些憑證往往存在於記憶體中。
最後，它會透過 HTTPS 請求，將竊取到的憑證傳送到攻擊者控制的外部伺服器。
這種攻擊模式顯示出強烈的組織化特徵。安全研究發現，此次攻擊使用的外傳域名與先前針對 npm 生態系（如 @antv）的 Mini Shai-Hulud 攻擊活動高度重疊，顯示這可能是一場跨平台的大規模供應鏈攻擊。
為什麼版本標籤（Tag）不安全
這起事件給所有工程師的一個重要教訓是：標籤（Tag）在 Git 中是可以被移動或更改指向的，它並不具備不可篡改性。
如果你在 YAML 設定檔中使用 actions/issues-helper@v1，GitHub 會在每次執行時解析 v1 指向哪個 Commit。如果攻擊者成功將 v1 標籤移向惡意 Commit，你的流水線會在下一次執行時自動拉取並執行惡意代碼，而你完全不需要更改任何設定。
實務上的防禦建議
要徹底解決這個問題，唯一安全的方法是使用完整的 Commit SHA（提交雜湊值）來固定版本。
Commit SHA 是根據內容產生的唯一 ID（例如 40 個字元的隨機字串），它是不可更改的。如果你將 Action 固定在特定的 SHA 值，即便攻擊者更改了標籤或刪除了標籤，你的工作流依然會執行那個被驗證過的安全版本，而不會被導向偽裝提交。
總結來說，在處理 CI/CD 安全時，應將第三方 Action 視為不可信的外部代碼。放棄使用便捷的版本標籤，改用 Commit SHA 固定版本，是保護企業憑證不被竊取的關鍵工程實務。
來源：thehackernews.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。