GitHub Actions pull_request_target 預設規則，Mac CI 怎麼驗？2026

2026 年 9 月 17 日，GitHub 公布 workflow execution protections 正式可用；公告指出，對尚無適用事件策略的公開倉庫，pull_request_target 預設處理先進入評估模式，並計劃於 2026 年 12 月 2 日對受影響倉庫自動執行。公告中的正式可用狀態、評估階段與執行日期 是時間安排依據，不代表你旗下每個公開倉庫必然受影響。

私有與內部倉庫不適用這項公開倉庫預設規則；但這不代表它們不受組織或倉庫既有 Actions 策略約束。事件策略也不是 Mac 主機隔離或憑證隔離機制。你必須分開確認倉庫可見性、適用策略、工作流程檔案與實際執行邊界。GitHub 的 Actions 策略管理文件 說明了管理工作流程執行政策的範圍。

建立一份倉庫清單，列出仍由 pull_request_target 觸發的工作流程、用途、程式碼來源及負責人。不要只記錄倉庫名稱；同一倉庫中的工作流程可能有不同觸發條件和憑證需求。

評估模式的用途是觀察哪些工作流程與事件會被策略判定為不允許，讓你有資料可供後續決策。它不是正式阻止執行的證明，也不能代替實際工作流程驗證。使用 GitHub Actions Insights 指標文件對照可用的執行資料，再把觀察結果與倉庫清單連起來。

操作時按以下次序留存證據：

• [ ] 列出公開倉庫，記下倉庫可見性及目前適用的事件策略。
• [ ] 找出包含 pull_request_target 的工作流程檔案，記錄工作流程用途與維護人。
• [ ] 查看 Insights 的評估結果，記下被判定不允許的工作流程和事件。
• [ ] 將每筆結果對應到倉庫、工作流程檔案、程式碼來源及負責人。
• [ ] 以後續評估和受控測試更新記錄，不以單次檢查推定長期沒有影響。

注意：評估結果是審查輸入，不是「安全」或「不會中斷」的認證。若工作流程檔案、事件或倉庫策略有變更，重新核對記錄。

pull_request_target 需要特別檢查，是因為工作流程可能在基礎倉庫的權限脈絡下處理 PR，而 PR 內容可能來自 fork。風險取決於工作流程如何取得、檢出或執行不可信程式碼，以及執行時能接觸哪些權限和敏感憑證；不是 Mac Runner 的處理器、型號或作業系統本身造成的事件風險。GitHub 的 pull_request_target 安全指引 說明了這個事件的安全邊界。

逐一審查工作流程中的觸發事件、程式碼來源、執行步驟與 permissions。如需最小化權限，依照 GitHub Actions 工作流程語法的權限設定說明核對實際設定，而不是只看工作流程名稱或預期用途。

記錄以下內容，作為保留或移除事件的依據：

• PR 工作流程是否會檢出或執行來自 fork 的程式碼。
• 工作流程取得的倉庫權限，以及是否使用簽名、發布或部署憑證。
• Mac Runner 可存取的金鑰、工作目錄與產物位置。
• 移除或限制事件後，哪些檢查會停止，是否有較合適的觸發方式可替代。

尤其要留意「先執行外部程式碼，再使用高權限憑證」的組合。即使單次建置成功，亦不能證明程式碼來源與憑證邊界已安全分離。

哪類倉庫需要優先盤點？

先盤點公開倉庫，再確認是否已有適用事件策略。這項預設規則不適用私有和內部倉庫，但組織自行設定的策略仍須另行核對。每項判斷都要連到倉庫可見性、策略配置和工作流程檔案，不要把組織層級的概括認知當成單一倉庫的證據。

Insights 顯示受影響，是否代表 Mac CI 已被阻止？

不是。評估模式用來觀察工作流程和事件是否會被判定為不允許；它本身不等於正式執行阻止。你還要確認結果對應的工作流程檔案、事件和程式碼來源，並在受控驗證中核對策略評估記錄與工作流程執行結果。

私有倉庫是否可以略過所有檢查？

不可以。私有與內部倉庫不適用這項公開倉庫預設規則，但仍可能受企業既有 Actions 策略、權限設定或工作流程安全風險影響。確認可見性後，仍要檢查倉庫與組織策略，並審查 PR 程式碼是否會接觸高權限工作流程或憑證。

必須保留事件時，例外要如何收窄？

先評估是否能改用更適合的觸發方式，或調整工作流程權限。確有業務需求時，核對適用事件策略與工作流程檔案範圍，並記錄例外理由、審批人、倉庫、所需憑證和複核條件。顯式允許只表示策略准許，不代表工作流程已自動具備安全隔離。

若業務仍依賴 pull_request_target，先回答兩個問題：能否用其他觸發方式達成相同目的？能否在不暴露高權限資源的情況下完成工作？只有替代方案不足以滿足需求時，才提出例外。

接著核對例外適用的事件策略與工作流程檔案範圍。GitHub 公告提及可針對工作流程檔案設定；你應依照 Actions 策略管理文件確認實際配置方式，避免把授權套用到無關工作流程。

例外變更記錄至少要寫明：業務理由、審批人、受影響倉庫、工作流程檔案、權限與憑證需求，以及何時重新審查。若理由或範圍不能明確對應到單一工作流程，先不要擴大授權。

正式變更前，在受控環境測試允許與拒絕的觸發，再分別對照工作流程結果和策略評估記錄。檢查 Mac Runner 能存取的簽名憑證、倉庫權限與建置產物；Runner 是執行節點，不會自動替你隔離不可信程式碼或憑證。GitHub 的自我管理 Runner 安全使用文件提供了自我管理 Runner 的風險與防護指引。

按以下順序完成驗收：

• [ ] 確認測試使用的倉庫、分支、事件和工作流程檔案與預定變更一致。
• [ ] 驗證預期允許的事件確實觸發，並確認工作流程取得的權限符合設計。
• [ ] 驗證預期拒絕的事件沒有依原先方式執行，並保存策略評估結果。
• [ ] 審查 Runner 可讀取的簽名憑證、工作目錄與輸出產物。
• [ ] 記錄策略生效後可能出現的失敗表現、負責人與復原路徑。

不要只以任務成功作為放行條件。若工作流程結果與策略記錄不一致，或測試沒有涵蓋實際 PR 程式碼來源，先查明差異再放行。

根據評估結果和業務依賴，選擇阻止 pull_request_target、為必要工作流程設明確例外，或先整改再變更。對需要保留的工作流程，確認例外沒有超出倉庫與檔案範圍；對不再需要的工作流程，移除事件或相關權限，並用受控驗證確認沒有意外中斷。

在變更記錄中保存倉庫範圍、規則設定、Insights 結果、驗證記錄與例外審批。GitHub 公布的自動執行日期是 2026 年 12 月 2 日；在此日期前完成複核，若官方更新了日期、適用範圍或規則行為，就重新評估結論。官方公告是日期依據；你自己的倉庫影響仍須由策略配置和執行證據確認。需要自動化盤點時，可參照 Actions 策略 REST API 文件，並以實際取得的倉庫資料為準。

這次驗收要處理的是工作流程觸發與權限邊界，不是單靠換一台 Mac 便能解決的安全問題。若你目前以自購 Mac 承接 CI，硬體採購、維護與容量安排都要自行處理；若改用非 macOS 執行環境，則不能直接承接需要 macOS 的建置工作。當團隊需要臨時或階段性的 Mac 執行環境時，可先比較 CALMVPS 的方案與計價資訊，並了解 CALMVPS 的 Mac 遠端服務，再按工作負載、憑證政策與實際運維責任判斷是否租用；需要長期穩定重載或實體介面的任務，則應先確認租用方式是否符合要求。