GitHub Actions workflow execution protections GA 怎麼設？用 ruleset 限制誰能觸發 CI

GA 版本多了什麼#

GitHub 官方公告的 GA 能力包含 workflow file path targeting、Insights，以及 REST API。它們分別解決「哪一份 workflow 要套政策」、「目前政策會影響哪些執行」，以及「如何把規則放進管理自動化」三個問題。

GA 不代表所有 workflow 都會自動變安全。它只是讓前置准入政策有較完整的 targeting、觀察和管理介面；workflow 內的 token、secret、checkout 與第三方 action 仍要各自 review。

這個 protection 解決哪一個邊界#

workflow execution protections 會在 workflow 執行前評估 allow list；未通過的 actor、event 或 target 不會進入一般執行階段。這和 workflow 內的安全設定是不同層次：

例如 on: workflow_dispatch 只說明 workflow 支援手動執行；它不會單獨限制哪些 repository role 可以按下執行。execution protection 的 actor rule 才是在集中政策中處理「誰能觸發」的控制面。

先從高權限 workflow 做 ruleset#

預設情況下，具有 repository write access 的使用者可能觸發 workflow。這不代表他一定能讀取 production secret 或推送程式碼，但它可能讓一份剛被修改的 workflow YAML 進入 runner；若該 workflow 有過寬權限，風險就會在執行時放大。

建議把導入範圍拆成三層：

1. 先選 workflow path：列出會使用部署 token、cloud credential、OIDC 或 production environment 的 workflow，不要一開始對整個 repository 的所有檔案套同一種規則。
2. 再限制 actor 與 event：針對 pull_request_target、手動 workflow_dispatch 和 release 流程做 allow list，並把必要的 Dependabot、Copilot 或 release automation 明確列入。
3. 最後補最小權限：即使 actor 和 event 通過，仍在 workflow 明確設定 permissions，並讓 production environment 保留獨立 reviewer。

這種分層方式可以讓 policy 只保護真正有影響力的執行面，也比較容易從 Insights 判斷哪條規則造成誤擋。

設定位置與安全導入順序#

官方文件的設定入口在 repository、organization 或 enterprise 的 Actions policy。以 repository 為例：

1. 開啟 Settings > Actions > Policies。
2. 建立 workflow execution protection ruleset，選擇要 targeting 的 workflow path。
3. 加入 actor 和 event rules，先選 Evaluate。
4. 透過 Insights 檢查將被拒絕或需要調整的 workflow run。
5. 確認例外與維運流程後，再切換成 active；需要大量管理時，再評估 REST API。

Evaluate mode 是觀察工具，不是安全封鎖。正式啟用前，應把允許與拒絕案例都放進 rollout 紀錄，避免「看起來有規則」卻沒有真正阻擋。

pull_request_target 要提前做一次盤點#

GitHub 已公告 public repository 的預設 workflow execution policy 將限制 pull_request_target，受影響的 repository 會在 2026 年 11 月 2 日開始套用這項變更。若現有流程依賴 pull_request_target，不要等到日期當天才看失敗訊息，現在就應檢查：

• 哪些 workflow 使用 pull_request_target，以及是否真的需要高權限上下文。
• workflow 是否 checkout 或執行來自不受信任 fork 的程式碼。
• 需要的權限是否可改成 pull_request 加上明確的審查、artifact 或外部服務流程。
• repository 的 Actions policy 是否使用 GitHub 的 default policy，還是已經有自訂 ruleset。

這項預設政策不會取代 pull_request_target 的安全邊界。即使 actor 與 event 被允許，也不能在高權限上下文中直接執行不可信的 fork 程式碼。需要更完整的風險分層時，也可搭配 疑似惡意 workflow 的保留與核准檢查。

啟用前後怎麼驗證#

至少留下以下五類測試案例：

把被允許與被拒絕的案例都放進 rollout 紀錄。規則只改變「能不能進入 workflow」，不會替你驗證程式碼、secret 或第三方 action，因此仍應保留 build、test 和部署前檢查。

結論：先控准入，再控權限#

GA 後的 workflow execution protections 已經不只是試用中的 actor／event 開關：workflow path targeting、Insights 與 REST API 讓它更適合放進組織級治理。不過安全導入順序仍相同：先盤點高權限 workflow，再用 Evaluate 收集誤擋案例，最後同時檢查 actor、event、permissions、environment reviewer，以及 pull_request_target 的安全邊界。

常見問題#