理解 Composer GitHub Action 中的 GitHub_TOKEN 洩露問題

持續整合 (CI) 流水線的安全性通常是組織的一個關鍵漏洞點。最近的一份安全公告 (GHSA-f9f8-rm49-7jv2) 引起了人們對一個特定案例的關注，即 GITHUB_TOKEN 在 GitHub Action 的日誌中被無意中洩露。此事件提醒了敏感憑證如何輕易地透過日誌記錄機制洩露，以及驗證第三方 Action 安全性的重要性。

洩露的性質

與最初報告和標題暗示 GitHub Actions 本身存在系統性故障不同，此漏洞並非 GitHub 平台核心基礎設施的缺陷。相反，問題存在於 Composer 專案 (PHP 的依賴管理器) 所提供的特定 GitHub Action 中。

當工作流使用 GITHUB_TOKEN 進行身份驗證時，GitHub Actions 通常會透過將這些秘密 (secrets) 替換為星號來在日誌中遮蔽它們。然而，如果一個 Action 執行了修改或驗證相同 token 的操作，且其方式導致平台的遮蔽機制無法識別，則該 token 可能會以明文形式列印到 stdout/stderr 日誌中。

技術影響與風險

對於在 GitHub Actions 工作流中使用 Composer 的組織而言，風險在於任何有權存取這些工作流日誌檔案的人或實體都可以取得目前有效的 GITHUB_TOKEN。

雖然 GITHUB_TOKEN 通常是短暫的且僅限於特定儲存庫的範圍，但其洩露可能允許攻擊者以該 token 被分配的相同權限執行操作。根據工作流權限的配置，這可能從唯讀存取範圍擴展到推送代碼或建立發行版 (releases) 的能力。

社群討論與反對觀點

圍繞此事件的技術討論強調了關於 CI/CD 工具安全性態勢的幾個關鍵點：

秘密遮蔽失敗

使用者提出的主要擔憂之一是 token 洩露的原因。一位貢獻者指出，驗證不透明身份驗證金鑰的結構——而不是簡單地訪問像 /rate_limit 這樣無害的端點來驗證 token 的有效性——是一種危險的做法，這往往會導致意外的洩露。

DevOps 複雜性

一些從業者表達了對 GitHub Actions 生態系統的挫折感，認為該平台旨在於初始設置的簡易性，但缺乏「嚴謹 DevOps」實踐所需的深度。這種情緒暗示了平台對簡單整合而非嚴格安全預設值的依賴，可能會為開發者帶來陷阱。

緩解措施與建議

為了保護您組織的流水線，建議採取以下步驟：

  1. 稽核 Composer Actions：如果您在 GitHub Actions 中使用 Composer，請確保您使用的是已修復此洩露問題的最新版本 Composer Action。
  2. 驗證秘密遮蔽：不要僅依賴平台的內建遮蔽功能。確保您的自定義腳本或第三方 Action 並不會明確地將包含秘密的環境變數列印到日誌中。
  3. 最小權限原則：將您的 GITHUB_TOKEN 權限配置為盡可能嚴格。GitHub 現在預設鼓勵使用 GITHUB_TOKEN 的唯讀權限，以限制潛在洩露的影響範圍。
  4. 立即行動：正如漏洞報告者所建議的，如果您不確定您的 Action 正在運行哪個版本的 Composer，請考慮在更新之前停用受影響的工作流。

Sources