GitHub Actions 自託管 Mac Runner 金鑰外洩怎麼辦？2026 排查指南

工作流程出現可疑日誌、拉取請求警告，或 Runner 行為異常：先暫停可疑工作流程並隔離受影響的 Mac Runner，再撤銷或輪替可能暴露的憑據、檢查日誌與權限；完成環境清理及可信程式碼復測前，不要恢復派送任務。

適合正在處理疑似金鑰暴露的獨立開發者，以及替客戶管理 Runner 的自由工作者。
小型遠端團隊也可用本文統一止損、調查與恢復的交接步驟。

GitHub Actions 自託管 Mac Runner 金鑰外洩：先分辨事件類型

不要只憑一則告警就判定密鑰已遭竊；先確認它是「已確認外洩」、「疑似暴露」，還是尚未證實的異常。已確認外洩代表有證據顯示憑據可被未授權者取得或使用；疑似暴露則表示它可能進入不可信程式碼或輸出，但目前證據不足；一般告警則可能只有異常觸發或行為，尚未證實憑據曾暴露。

GitHub Actions 自託管 Runner 可能洩露金鑰時，第一步要做什麼？先阻止可疑工作流程繼續執行，將疑似受影響的 Runner 從任務派送中隔離，再評估憑據是否需要撤銷或輪替。不要為了快速恢復而在同一台未檢查的主機上重跑工作。

注意：日誌中的自動遮蔽不代表憑據一定沒有外洩。GitHub 說明遮蔽機制並非絕對保障，憑據經過轉換或以不同形式輸出時，可能無法如預期遮蔽；請參照 GitHub Secrets 的遮蔽與使用說明，並以實際日誌和憑據狀態判斷。

先查工作流程如何取得程式碼與權限

確認事件觸發器、程式碼來源及工作流程權限。特別留意工作流程是否因拉取請求觸發、是否檢出外部提交，以及該工作流程是否能讀取部署金鑰、環境密鑰或其他敏感值。GitHub 提醒，自託管 Runner 不保證每次任務都在乾淨、隔離的暫存環境執行；不可信工作流程程式碼也可能危及 Runner 環境及其可存取的憑據。可對照官方自託管 Runner 安全使用說明逐項檢視。

怎樣判斷工作流程有沒有把密鑰暴露給拉取請求程式碼？先確認觸發事件，再追查工作流程是否檢出並執行拉取請求提供的程式碼，以及該任務可使用哪些權限。一般來說，來自 fork 的 pull_request 工作流程不會取得 Secrets，GITHUB_TOKEN 也受到限制；但若工作流程使用 pull_request_target，又在高權限內容下檢出並執行不可信程式碼，風險便不同。請核對 GitHub 對 pull_request_target 的安全指引，不要以放寬核准要求的方式處理。

接著檢查工作流程設定中的 permissions。例如，工作只需要讀取程式碼時，應評估 contents: read 是否足夠，而不是沿用不必要的寫入權限；可參考工作流程權限語法。同時辨認 GITHUB_TOKEN 是否被工作流程或動作使用，並按其用途和權限範圍調查；GitHub 對 GITHUB_TOKEN 的說明可協助你區分它與自行建立的金鑰。

檢查日誌時要看什麼？從 GitHub Actions 工作流程日誌確認執行時間、工作與步驟、觸發來源，以及是否有憑據樣式內容、異常輸出或不熟悉的執行行為。參照官方工作流程日誌操作說明保存調查所需資訊；不要在分享截圖或複製日誌時再次散播疑似憑據。

按憑據種類撤銷或輪替，不要只改一個值

把疑似暴露的內容分成不同類別，逐項確認它由誰管理、有哪些工作流程可以讀取，以及該如何使舊值失效。GitHub Secrets 可能設在儲存庫、環境或組織層級；定位時可參考Secrets 的管理與使用說明。

GitHub Actions secrets 輪替後，如何確認舊憑據不再可用？先在核發憑據的系統撤銷舊值或停用舊金鑰，再確認相關工作流程已改用新值；接著查核該系統可提供的使用紀錄，並確認舊憑據不能再完成原先授權的操作。只更新 GitHub Secrets 的內容，不能證明外部系統上的舊金鑰已失效，也不能清除 Runner 可能留下的持久化變更。

隔離 Runner 後再決定清理、重建或重新註冊

若不可信程式碼曾在自託管 Mac Runner 上執行，先停止派送，保存必要的工作流程資訊與事件時間，並依組織的事件應變程序交由主機責任方調查。不要在調查前刪除可能有助於釐清事件的資料，也不要把該主機當成可信的建置環境。

自託管 Mac Runner 執行過不可信程式碼後，是否要重新註冊？重新註冊本身不等於清除風險。先由有權限的主機責任方判斷如何調查、清理或重建環境；若無法確認主機狀態，就不要讓它重新接收工作。依照移除自託管 Runner 的官方說明完成必要的移除作業，再依組織流程決定是否以可信狀態重新加入。

如果 Runner 由你自行管理，先列出哪些倉庫、工作流程和憑據可以接觸該主機；若由客戶或團隊管理，則要明確交接主機調查、Secrets 撤銷與重新授權的責任。涉及客戶專案時，可把遠端 Mac 工作環境的資料保護與責任範圍列入事前檢查，但不要把一般服務說明當成特定事件已完成處置的證據。

按恢復里程碑驗收，而不是改完密鑰就恢復

以下順序可作為事件處理的檢查軸；若組織已有事件應變程序，應以責任人和正式流程為準。

• 止損完成：可疑工作流程已暫停，受影響 Runner 已停止接收任務，調查所需資訊已按程序保存。
• 範圍釐清：已追查觸發器、程式碼來源、工作流程權限、日誌與可用憑據；仍無法確認的部分應明確標示為未確認。
• 憑據處理完成：可能暴露的 Secrets、Token、金鑰或授權已按其核發來源撤銷或輪替，並確認工作流程不再依賴舊值。
• 環境恢復完成：主機責任方已依事件流程確認 Runner 可重新使用；單純重新註冊不足以作為環境可信的證明。
• 受控復測完成：只以可信程式碼執行受控工作流程，確認 Runner 狀態、憑據可用範圍及建置結果符合預期，再由責任人批准恢復派送。
• 權限複核完成：檢查工作流程觸發條件、受保護環境、GITHUB_TOKEN 權限與第三方 Action 來源，移除不必要的存取。

如需補足事前驗收項目，可參考本站的遠端 macOS 工作環境指南；指南不能取代事件調查，也不代表特定 Runner 已經清理或復測。

如果你目前依賴自己維護的 Mac Runner，事件發生時可能同時面對主機狀態待查、建置中斷，以及憑據和客戶責任需要分頭確認等問題。租用遠端 Mac 可以讓你評估另一種主機管理方式，但不會自動消除工作流程風險；你仍應先核對實際的存取權限、隔離責任與憑據管理方式。若只是暫時需要 macOS 建置或測試環境，可先查看 macminirent 的服務方案並確認責任邊界；若你需要長期固定主機、實體介面，或完整掌控硬體環境，自行管理設備可能更合適。