GitHub Actions workflow 被保留等待核准怎麼辦？先做來源與權限檢查
如果 public repository 的 GitHub Actions run 顯示等待核准，先不要把它當成 CI 壞掉。GitHub 已開始自動保留部分疑似惡意的 workflow；必須由具 write 權限的 collaborator 在已登入的網頁 session 核准後，run 才會繼續。
直接原則是：核准的是某一次準備執行的 workflow，不是對提交者或 repository 建立永久信任。先看變更、觸發來源和 secrets 路徑，再決定是否放行。
這項保護涵蓋什麼
GitHub 說明，保留機制針對 GitHub.com 的 public repository，自動套用且目前不需額外設定；GitHub Enterprise Server 尚未提供同一項保護。它是針對被辨識為潛在惡意的 workflow run，而非一般的 fork PR approval 規則。
因此不要用「它以前能跑」推論這次可以直接核准。被入侵的帳號也可能推送看似熟悉、但內容已被替換的 workflow。
核准前的最小檢查
| 檢查 | 要找什麼 | 有疑慮時 |
|---|---|---|
| 觸發來源 | 哪個 commit、branch、actor 與 event 觸發 | 不核准，先請 maintainer 確認 |
| workflow diff | 新增的 run、action、下載與 token 權限 | 用 PR review 或 revert 收斂 |
| secrets 路徑 | 是否會接觸 deploy key、registry token 或 cloud credential | 停止並撤銷暴露風險 |
| 外部 action | 是否釘選到可追溯的 SHA、是否近期被替換 | 改成已審核版本後再跑 |
可以先找 workflow 最近的變更與敏感步驟：
git log -p -- .github/workflowsrg -n 'secrets\.|permissions:|id-token:|curl |wget |npm (install|ci)' .github/workflows搜尋只是一個起點；任何把 token、artifact 或 repository 內容交給 shell、第三方 action 或部署工具的步驟，都需要沿著資料流確認。
不要把「核准」當成修復
核准只讓這次 run 繼續，不能消除惡意 YAML、過寬的 GITHUB_TOKEN 或外洩的 secret。若確認 workflow 有問題，正確處理是停止 run、還原或移除變更、輪替可能暴露的憑證，並檢查同一段時間的其他 workflow 與 commit。
也別為了避免等待而把 secrets 全部提供給低信任事件。既有的 pull_request_target 安全邊界 仍適用：高權限 workflow 不應 checkout 後執行 fork PR 的不可信程式碼。
團隊可先寫好的決策規則
- 只有熟悉該 repository 與部署範圍的人可以核准。
- 核准前一定看 workflow diff，而不是只看 run 名稱。
- production secret 的 workflow 需要另一位 maintainer 複核。
- 不確定時先取消，要求以小型、可審查的 PR 重送。
這樣的流程會比「所有 blocked run 一律按 approve」慢一點，卻能讓自動保護真正成為供應鏈檢查點。
參考資料：
回報錯字、失效連結，或告訴我你想看的延伸主題。