GitHub Actions 自託管 Mac Runner 安全嗎？2026 驗收清單

PR 建構已通過，卻不確定外部程式碼能否讀到發布憑據，或下一個工作會不會接觸前一個工作留下的檔案。

本週先檢查觸發權限、Runner 調度範圍、簽名私鑰和任務清理；做不到可信程式碼與正式發布任務隔離，就不要讓這台 Runner 接觸生產憑據。

適合準備讓 GitHub Actions 呼叫自託管 Mac 建構 iOS App 的獨立開發者，以及需要檢查簽名與發布憑據的小型團隊。
如果你維護多個倉庫或多人協作的發布流程，可以用下列條件確認哪些工作能排到同一台主機。

GitHub Actions 自託管 Mac Runner 安全，取決於工作流邊界

Mac 並不會自動讓建構環境安全。真正要驗收的是：誰能觸發工作、Runner 會執行哪份程式碼、工作能讀到哪些憑據，以及執行完後主機留下什麼狀態。

GitHub 的Actions 安全使用指南提醒，自託管 Runner 可能受工作流程執行的程式碼影響；因此，私有倉庫或環境審批本身都不是主機隔離的證明。判斷時要分開看程式碼可信度、工作流程觸發權限、主機隔離和簽名私鑰保護，不能把「建構成功」當作權限合格。

PR 驗證只跑不可信程式碼，不讀取發布憑據

公開倉庫的外部 PR 可以需要建構驗證，但不要因此把它排到可接觸正式發布祕密的持續使用型 Runner。先在工作流程設定中查明觸發事件，再確認實際檢出的提交是否來自 PR 提交者；只看工作流程名稱或分支名稱，無法判斷執行的程式碼是否可信。

GitHub 對工作流程觸發事件的說明，應與你實際使用的事件設定一起核對。尤其要檢查 pull_request_target：它在基礎分支的安全脈絡下觸發，若工作流程再取出並執行不可信 PR 的程式碼，就可能把較高權限帶進不可信程式碼。依照安全使用 pull_request_target 的指引檢查，不要在這類工作裡直接執行 PR 提交的程式碼。

驗收時逐項記錄：

• PR 工作使用的 Runner 是否能讀取簽名憑據、發布祕密或內部資源。
• 工作流程執行的是受信任分支內容，還是外部提交的內容。
• PR 建構是否與正式發布工作共用主機、鑰匙圈或可讀取的暫存路徑。
• 若無法證明隔離，是否改由不含發布憑據的獨立環境處理 PR 驗證。

可信分支建構仍須收緊令牌與調度權限

可信分支不代表工作流程中的每個元件都值得信任。檢查 GITHUB_TOKEN 是否只取得所需權限，並確認工作流程沒有透過過寬的權限設定，取得不必要的寫入能力。GitHub 的工作流程語法權限說明可用來核對權限設定；驗收證據應是實際工作流程設定，而不是「任務正常完成」。

第三方 Action 也要列入權限盤點：確認來源、維護狀態與版本固定方式，再核對變更是否經過審查。另要檢查哪些倉庫與工作流程能調度這台 Runner。只要不相關倉庫也能將工作派到有發布憑據的主機，令牌設定再嚴格，也無法補上程式碼來源和主機授權的缺口。

GitHub Actions Runner 隔離的驗收結果，應能由工作流程權限和 Runner 存取規則直接複核。你可對照自託管 Runner 的存取管理文件，確認實際授權範圍；不要把建構通過當成隔離已完成的證據。

簽名發布工作才應取得完整簽名身分

iOS 簽名憑據管理不能只盤點憑證檔案。Apple 說明，簽名身分由數位憑證與對應私鑰構成；兩者必須一起保護，也要釐清哪些發布工作有權使用它們。可參考 Apple 的團隊簽名身分與憑證說明，再對照你的工作流程與實際存放位置。

把簽名和上傳所需的項目分開列出：憑證、私鑰、App Store Connect 憑據，以及一般建構真正需要的設定。接著檢查私鑰是否只對確有需要的發布工作可用，而不是在每次 PR 驗證時都可讀取。留意診斷輸出、錯誤日誌、暫存檔與失敗產物是否可能包含敏感資料；不要將可重用的真實密鑰放進日誌、工作流程檔案或建構產物。

驗收評等以權限邊界為準：

• 可承接正式發布：只有受信任的發布工作能取得簽名身分，工作流程與授權範圍已有紀錄，且清理結果可複核。
• 僅適合不帶憑據的建構：PR 或日常建構能與發布憑據分開，但尚未證明主機可安全承接簽名任務。
• 不可上線處理敏感任務：不可信程式碼可能接觸私鑰，或你無法確認誰能調度 Runner、工作結束後留下哪些狀態。

共用 Mac 前先確認工作結束後的殘留狀態

工作結束，不等於主機已恢復乾淨。逐項查驗工作區、鑰匙圈、暫存憑據、建構產物與日誌：哪些會刪除、由什麼流程刪除，清理失敗時是否會阻止後續敏感任務。

GitHub 的自託管 Runner 文件說明 Runner 的安全與隔離邊界；使用臨時 Runner 或在工作後註銷註冊記錄，也不能單獨證明底層主機已清潔。你需要核對實際資源是否重設或重建，並以代表性建構和發布任務檢查清理結果。若工作會重複使用同一台 Mac，還要確認前一工作留下的鑰匙圈狀態、檔案權限與產物不會被下一個工作繼承。

多倉庫共用時，把排程權限當成主機入口

多個倉庫共用 Runner，首先是授權問題，其次才是維護便利性。逐一確認 Runner 的註冊層級、Runner 群組、允許使用的倉庫，以及哪些管理者能更改設定。GitHub 的自託管 Runner 存取管理文件可協助你核對群組與倉庫存取規則；仍須以實際設定確認不相關的專案不能排程到這台主機。

當各專案的程式碼信任程度不同，或只有部分工作需要發布憑據時，共用環境會增加審核與清理責任。若你無法證明程式碼、主機狀態和憑據之間的界線，就縮小可調度的倉庫範圍，或分開一般建構與正式發布環境。

上線前用條件分支決定 Runner 用途

依照可複核的工作流程設定和清理紀錄，逐項套用以下判斷；不要以口頭承諾或單次建構成功取代證據。

• 若外部 PR 只能使用不含簽名憑據的環境，而且不會執行在可存取發布祕密的 Runner 上，就讓它只負責不帶憑據的驗證；否則，將 PR 工作移出這台主機。
• 若 GITHUB_TOKEN 權限、第三方 Action 版本和可調度該 Runner 的倉庫範圍都能由設定核實，就繼續評估可信分支建構；否則，先收窄權限與存取範圍，不要接入正式發布。
• 若簽名憑證與私鑰只供受信任的發布工作使用，且日誌、暫存檔和失敗產物不會暴露憑據，才讓該 Runner 承接簽名任務；否則，將簽名工作移至隔離的發布環境。
• 若工作結束後的工作區、鑰匙圈、暫存憑據、產物與日誌都有清理證據，且代表性任務已驗證清理結果，才考慮讓同一主機承接後續工作；否則，先改用可重設的獨立環境或停止重複派送敏感任務。
• 若多個倉庫共用 Runner 時的群組、倉庫授權和管理權限均已核對，且不相關專案無法排程，才保留共享；否則，縮小授權範圍或拆分主機。

常見問題

公開倉庫的 PR 可否使用自託管 Runner？

不應把可能來自外部貢獻者的 PR，直接排到可讀取祕密或連接發布資源的持續使用型 Runner。若確實要在自託管環境驗證，先確認程式碼執行與發布憑據、主機狀態完全隔離；無法證明時，改用不含憑據的環境。

iOS 憑證和私鑰可以放在 Runner 上嗎？

可以納入受控的簽名工作，但只讓確有需要的受信任發布流程使用。憑證與對應私鑰共同構成簽名身分，因此還要核對鑰匙圈、工作流程權限、日誌和失敗產物；一般 PR 驗證不應因此取得私鑰。

多個工作流程共用一台 Mac 是否安全？

要看哪些倉庫和工作流程有排程權限，以及不同工作的憑據和主機狀態是否分開。使用 Runner 群組或倉庫存取策略限制授權，再檢查任務完成後的清理方式；若無法證明不相關專案不能接觸該主機，就應縮小共享範圍或拆分環境。

如何驗證工作之間沒有憑據殘留？

不要只以工作成功、工作區已刪除或 Runner 已註銷作結論。檢查鑰匙圈、暫存檔、建構產物與日誌的清理紀錄，並執行代表性工作確認結果；若主機會重複使用，也要查明底層資源如何重設。缺少可複核證據，就不要把它視為乾淨隔離。

上線紀錄要能讓團隊重做一次驗收

把 PR 觸發條件、令牌權限、Runner 可存取的倉庫、簽名私鑰可用範圍、任務清理證據，以及失敗後的處理方式整理成上線紀錄。再以代表性的 PR 驗證、可信分支建構與發布任務逐一核對；尚未解決的風險也要明確列出，不能以「成功產生 IPA」取代安全驗收。

如果你正評估遠端 Mac，先核對基礎設施資訊與技術支援資訊，確認交付與連線細節是否符合自己的工作流程。自建 Runner 的優點是環境由你控制，但你也要負責主機維護、工作殘留檢查和憑據隔離；若只是暫時需要 Mac 進行測試或建構，租用 VPSMAC 的遠端 Mac 可免去專為短期需求採購實機的負擔，但不會自動替你完成工作流程權限或簽名密鑰治理。若要比較可用方案，可先查看VPSMAC 的遠端 Mac 服務資訊，再按上述驗收條件判斷是否適合你的發布流程。