GitHub Actions cache-mode 怎麼配？2026 企業 Mac CI 防投毒指南
📋 本文目錄
GitHub 在 2026 年 9 月 10 日公布 Actions 快取存取控制的 cache-mode 能力；你可在官方公告核對發布資訊。症狀：不可信工作流程可能讀取或寫入快取；最快解法：依觸發器信任程度指定 read 或 none，讓可信工作流程單獨維護快取。 只有輸入可信且確實需要保存時，才考慮 write 或 write-only。快取權限不會清理 Mac，也不會隔離主機上的程式碼與憑證。
負責企業 GitHub Actions 政策的 IT 或平台工程負責人，可用本文設定快取讀寫權限和審批邊界。
負責 iOS/macOS CI 的工程負責人，可檢查快取內容如何進入 Mac 建置任務。
負責程式碼與簽名憑證安全的安全負責人，可據此複核非可信程式碼是否能影響可信流程。
最後更新於 2026 年 9 月 24 日；發布前核對 GitHub 的 cache-mode 公告、工作流程語法、依賴快取安全說明及 self-hosted Runner 安全文件。若官方更新支援範圍或觸發器規則，應以最新文件重新驗證本文的設定結論。
權限模式：能讀寫快取，不等於隔離程式碼
GitHub Actions cache-mode 企業配置應先依任務信任等級決定權限，再談快取命中率。下表概括四種模式的操作意義；採用前，請核對該功能發布時的官方語法與支援範圍，並在工作流程中明確指定模式，不要依賴未檢查的省略值。
| 模式 | 恢復快取 | 儲存快取 | 適用判斷 |
|---|---|---|---|
read |
可 | 不可 | 只需要使用既有快取的低信任任務 |
write |
可 | 可 | 信任輸入，且需要讀取及更新快取的工作流程 |
write-only |
不可 | 可 | 只允許產生新快取，不應讀取既有內容的工作流程 |
none |
不可 | 不可 | 不需要快取，或不應接觸快取的任務 |
上述模式控制的是快取操作，不是程式碼執行權限。即使任務只有 read，它仍可能執行非可信程式碼，也可能在持久化 Runner 留下檔案、背景程序或憑證。反過來說，停用快取亦不會自動清理工作區或隔離主機。
若原有流程省略模式或依賴動作的預設行為，先查明具體工作流程和快取動作的有效行為。快取恢復與工作結束後的儲存可能是不同階段；只看工作流程檔案中有沒有快取步驟，不能證明兩者都被禁止。GitHub 的依賴快取說明可協助你核對快取範圍與一般行為。
觸發器信任：誰可以恢復或寫入
快取投毒的風險不只在於誰能寫入，也包括不可信工作流程能否讀取可信工作流程先前保存的內容。設計政策時，應逐種檢查觸發事件、程式碼來源，以及後續工作流程是否會執行生成物；不要將「有權執行 CI」視為「有權更新共用快取」。
| 觸發情境 | 建議起始權限 | 核查重點 |
|---|---|---|
來自 fork 的 pull_request |
read 或 none |
依任務是否必須恢復快取決定；不要讓不可信變更更新可信工作流程使用的快取 |
同一儲存庫的 pull_request |
read 起步，按政策調整 |
確認貢獻者及分支保護規則，不能只因來源在同一儲存庫就判定為可信 |
pull_request_target |
預設不執行 PR 程式碼；需要快取時另行審查 | 事件可在基礎分支的權限脈絡執行，若同時檢出並執行不可信程式碼，風險會擴大 |
workflow_run |
由可信工作流程控制，預設不採用不可信產物 | 下游流程可能取得較高權限；檢查產物來源、驗證及執行方式 |
受信任分支的 push |
確認輸入及審批後才允許寫入 | 確認分支保護、審核政策及簽名任務是否與一般建置分開 |
這些是政策起點，不是 GitHub 對所有儲存庫都適用的固定預設值。各事件的權限和快取可見範圍須依事件觸發器文件核實。對 pull_request_target，請遵守官方的安全使用指引：取得較高權限的工作流程不應直接執行未審查的 PR 程式碼。
pull_request 工作流程要選哪種快取權限？
如果工作流程只需讀取相依套件快取，先用 read；若它不應接觸任何快取，就用 none。只有當輸入已納入可信審核、且寫入流程經平台與安全團隊批准，才允許寫入。對外部 PR，不要因為快取可改善建置流程，就把寫入權限一併開放。
如何避免不可信 PR 改動可信分支使用的快取？
讓不可信 PR 不具備寫入權限，並由受信任分支上的工作流程負責更新快取。若採用後續工作流程處理 PR 產物，先驗證產物來源與內容，再決定是否使用；不能只憑觸發器名稱判斷可信。
快取影響面：鍵值、分支範圍與內容
權限模式只能限制快取存取方向；快取鍵、恢復鍵和快取內容會決定錯誤配置的影響範圍。GitHub 的依賴快取安全文件說明了快取存取邊界。落地時，應把任何恢復的快取視為不可信輸入，而不是已驗證的建置成果。
| 檢查項目 | 風險信號 | 建議處理 |
|---|---|---|
| 快取鍵 | 多種任務共用相同鍵，或鍵未反映相依性變更 | 依工作流程、相依性檔案及建置用途設計鍵值 |
| 恢復鍵 | 寬泛的恢復前綴可能取得不符合預期的快取 | 限縮恢復範圍；確認恢復內容不會直接取得簽名或發布權限 |
| 分支作用域 | 誤以為所有分支都能任意互讀或互寫 | 依官方快取作用域規則驗證實際可見範圍 |
| 快取內容 | 含密鑰、憑證、簽名素材或其他敏感資料 | 不把秘密資料放進快取；改用受控的秘密管理流程 |
實際風險不只在「誰最後寫了快取」。若 Xcode CI 恢復的內容會被編譯、執行或用來產生發布產物，即使來源只是相依套件或中間建置檔，也應納入程式碼審查與產物驗證。避免讓可信發布流程直接把低信任任務生成的快取當成已驗證輸入。
Mac Runner 邊界：遠端快取控制無法清理主機
使用 self-hosted Mac Runner 時，遠端快取權限只覆蓋快取操作，不能替代主機隔離。GitHub 的安全使用 self-hosted Runner 指引提醒你評估不可信工作流程在自架環境中的安全風險。對 Mac CI 而言，至少要分開盤點本機工作區、工具鏈狀態、登入工作階段、背景程序與憑證殘留。
GitHub Actions 快取權限能保護持久化 Mac Runner 嗎？
不能。none 可以阻止工作流程使用快取，但不能清除上一個任務留下的本機檔案，也不能撤銷仍有效的憑證。若同一台 Mac 會接收不同信任等級的程式碼，你仍須以獨立 Runner 群組、乾淨環境或任務後重建等方式處理主機生命週期；具體措施須依你實際採用的執行環境驗證。
可用以下三種方式比較 Runner 隔離要求，並標示內部風險評級：
- 一次性或任務後重建：低殘留風險。 適合隔離要求較高的非可信建置；仍須確認憑證不會隨映像或啟動腳本殘留。
- 依信任等級分組、工作區重設：中度風險。 適用於能嚴格限制任務路由，且已驗證清理涵蓋工作目錄以外狀態的情況。
- 多信任等級共用持久化主機：高風險。 除非你能證明工作區、工具鏈、程序及憑證均受到隔離，否則不應讓非可信 PR 與簽名或發布工作共用節點。
這是供內部評審使用的風險分級，不是 GitHub 官方評分，也不代表任何特定 Mac 服務已具備相應隔離能力。若你正評估自購硬體，可先參考企業 Mac mini 採購與價格考量；硬體所有權本身同樣不會自動解決清理及憑證分區問題。
上線驗收：用證據確認模式有效
對照文件完成設定後，應用可信與不可信工作流程分別驗證實際結果。測試紀錄須包含觸發器、程式碼來源、有效 cache-mode、快取恢復及儲存日誌、工作流程權限，以及失敗時是否降級到不寫入。若只檢查設定檔而未查看執行紀錄，就無法確認任務是否按預期存取快取。
- [ ] 列出各觸發器及其信任等級，特別標明 fork PR、
pull_request_target與workflow_run。 - [ ] 為每個工作流程明確指定快取模式，記錄省略設定時的官方文件依據，不以推測代替。
- [ ] 確認不可信任務無法寫入可信工作流程使用的快取；保留相應執行紀錄。
- [ ] 分別核對恢復、儲存與工作流程失敗時的紀錄，確認失敗不會令權限意外放寬。
- [ ] 驗證秘密資料不在快取內，並確認簽名憑證不會暴露給低信任任務。
- [ ] 在 Mac Runner 上檢查工作區、工具鏈狀態、背景程序及憑證清理紀錄。
- [ ] 由平台、安全與研發共同簽署測試結果，再決定試點、整改或放量。
怎樣判斷可以擴大使用？
先確認不可信任務的快取權限受到限制，再確認 Mac Runner 的清理及憑證隔離有可供稽核的證據。任何一項尚未驗證，就維持小範圍試點或先整改，不要用「CI 已成功完成」取代安全驗收。
若團隊目前把所有任務放在同一台持久化 Mac 上，這種方式可能面臨殘留狀態難追查、非可信 PR 與簽名流程邊界不清，以及擴充節點時環境難以一致等問題。自購 Mac 適合長期固定負載與需要實體介面的工作；雲端執行環境則要逐項核對硬體、持久化和管理責任。若你需要的是階段性測試或臨時補充 Mac 節點，可進一步了解 MacDate 的 Mac 運算節點選項，並先確認所需的隔離、清理與憑證管理條件，再決定是否納入企業 CI。