這篇文章協助企業 IT、平台工程與安全團隊評估 workflow lockfiles 是否適合導入 Mac CI。內容比較依賴覆蓋、完整 SHA 固定、風險邊界與維護成本，並提供漸進試點及策略評估步驟。
這篇文章協助企業 IT、平台工程與安全團隊評估 workflow lockfiles 是否適合導入 Mac CI。內容比較依賴覆蓋、完整 SHA 固定、風險邊界與維護成本，並提供漸進試點及策略評估步驟。
資料點：GitHub 於 2026 年 10 月 14 日宣布 workflow dependency lockfiles 與 Require lockfile 策略進入公開預覽；這是預覽消息，並非正式 GA。公告原文
依賴引用會移動 → 先在符合資格的企業儲存庫試點 lockfile，再評估是否強制。
要降低 Mac CI 的供應鏈風險 → 同步保留依賴審查、最低權限及 Runner 隔離；lockfile 不會替它們把關。
適合需要評估 lockfile 策略範圍與啟用門檻的企業 IT 或 GitHub Enterprise 管理者。
適合維護 Mac CI 工作流程、共用 Action 及 Dependabot 更新流程的平台工程負責人。
也適合要降低依賴引用漂移、並明確界定剩餘風險的安全負責人。
最後更新於 2026 年 10 月 15 日；預覽狀態、依賴範圍與策略邊界核對自公告及官方文件。公開預覽資格及操作限制可能調整，導入前應再核對最新文件。
GitHub Actions workflow lockfiles 的價值，在於協助記錄工作流程依賴的解析結果，讓團隊檢查引用與提交之間的對應關係。它不代表「整個 CI 已鎖定」：工作流程可能引用 Action、可重用工作流程或本地 Action，而依賴定義、解析方式及負責維護的儲存庫並不必然相同。
官方文件說明 workflow dependency lockfiles 的用途及範圍；落地時應逐一核對引用類型，不要把某種依賴的鎖定效果外推到其他類型。GitHub 的依賴鎖定概念文件與鎖定 Action 依賴的操作指南是建立清單的依據。
我們建議把下列問題寫進儲存庫的試點紀錄：
其中的非顯然風險是責任歸屬：工作流程儲存庫可以記錄自己的引用，但可重用工作流程或 Action 的維護者仍可能在另一個儲存庫更新內容。若企業只檢查呼叫端的 YAML，卻未追蹤依賴定義所在位置，審查鏈就可能在跨儲存庫邊界中斷。對本地 Action 也應按官方解析規則核實，不要只因引用位於同一個工作流程檔案，就假定它會以相同方式納入 lockfile。
標籤或分支名稱便於閱讀，但若上游移動了引用目標，工作流程執行內容也可能隨之改變。lockfile 的決策價值，是讓團隊可以檢查依賴解析結果是否仍對應已核驗的提交，以及來源儲存庫身分是否符合預期；它本身不是安全審查結論。
完整 commit SHA 固定，是直接在工作流程引用中指定提交，通常容易在 YAML 中檢視；workflow dependency lockfiles 則提供依賴解析紀錄，適合用來審閱受支援範圍內的依賴。兩者的差異不應簡化成「lockfile 一定涵蓋更多」或「SHA 一定足夠」：實際覆蓋要依官方規則和工作流程中的依賴類型確認。GitHub 亦提供選擇與自訂 Actions 的說明，可協助團隊檢查引用方式。
| 選項 | 引用可讀性 | 依賴解析檢視 | 維護負擔 | 我們的治理評分 |
|---|---|---|---|---|
| 使用可移動的標籤或分支 | 高，名稱直觀 | 低；目標移動時須額外察覺 | 表面較低，變更追蹤成本可能較高 | 低 |
| 在引用中固定完整 commit SHA | 中；需核對 SHA 與來源 | 直接固定指定引用，其他依賴仍須另查 | 更新需審核並修改引用 | 中 |
| 使用 lockfile 並保留審查流程 | 中；要同時檢視 YAML 與鎖定紀錄 | 依官方支援的依賴類型檢查解析結果 | 需維護生成、驗證與審核閉環 | 高 |
表內評分是我們依照引用可見度、可審查性及持續維護需求作出的治理判斷，不是 GitHub 官方評等，也不是本站實測。對高敏感度的 Mac 發布工作流程，團隊可評估是否同時保留明確 SHA 引用與 lockfile，而不是把其中一項當成另一項的替代品。
注意：固定到完整 SHA，只能確定引用目標；它不代表該提交已經過安全審查，也不代表提交沒有已知漏洞。審查應同時追蹤來源、程式碼變更、維護者和更新理由。
GitHub Actions workflow lockfiles 能降低未經審查的依賴引用變動混入執行的風險，但不能替企業證明 Action 程式碼可信。它也不會限制 Runner 上可以存取哪些檔案、密鑰或網路資源；被攻陷或權限過大的 Mac Runner，仍可能暴露其可讀取的資料。
| 控制項 | 主要處理的風險 | 不能據此推論 |
|---|---|---|
| workflow lockfile | 依賴解析及引用變動的可見度 | 依賴已安全或每項程式碼都已審查 |
| 完整 SHA 固定 | 特定引用目標漂移 | SHA 對應提交無漏洞、無惡意變更 |
| 依賴審查 | 來源、變更與更新理由未經核對 | Runner 已隔離或憑證已妥善保護 |
| Runner 存取與隔離 | 不同信任工作流程間的主機權限邊界 | 依賴本身可信，或發布流程一定安全 |
| 發布簽名權限治理 | 簽名憑證遭不必要工作流程接觸 | 建置依賴沒有漂移或遭入侵 |
GitHub 的安全使用參考列出工作流程安全考量；自託管 Runner 則應另外檢查Runner 群組的存取管理。在 Mac CI 上，尤其要確認不可信程式碼能否排入持有發布憑證的 Runner、是否能讀取其他工作流程留下的檔案，以及 Runner 群組權限是否與建置任務相符。這些是主機和權限層的問題，不會因新增 lockfile 自動消失。
如果團隊正在規劃 Mac 節點的採購或配置，可以先參照企業 Mac 採購選項整理自建主機、遠端存取與維護責任，再把 Runner 的信任邊界獨立納入審查；硬體取得方式不會代替 CI 權限設計。
lockfile 若長期未更新，可能無法反映工作流程依賴的實際變更；如果每次升級都無人負責生成、驗證與審查，團隊就會在文件看似完整、執行內容卻未經確認的狀態下運作。啟用強制策略前，先證明更新流程能持續完成，比先擴大策略範圍更重要。
建議按以下步驟建立可重複的驗證流程：
Dependabot 可以協助提出依賴更新，但不會代替企業確認更新是否符合 Mac 建置、測試和簽名要求。將更新合併前，仍須核對 lockfile 是否同步、引用來源是否符合政策，以及 Mac 工作流程實際執行的程式碼是否經審查。這樣才能避免「自動更新已開啟」被誤當成「供應鏈控制已完成」。
截至本文更新時，GitHub 已宣布 workflow dependency lockfiles 與 Require lockfile 策略進入公開預覽；不要把公開預覽寫成正式 GA，也不要未經核對便推定企業方案、儲存庫或工作流程必然符合資格。政策的實際範圍與執行影響，應以官方策略文件在啟用當下的說明為準。
我們建議以「依賴清單覆蓋、lockfile 更新閉環、變更審查紀錄、策略評估結果、真實 Mac CI 執行結果」作為擴大試點前的證據包。以下判斷採用的是治理條件，而非本站試點成績：
這個順序避免把「策略可以開啟」誤當成「團隊已準備好」。若強制規則可能阻止尚未接入的工作流程執行，直接全面套用就會把治理缺口轉化成建置中斷；先檢視策略評估結果，再限定範圍調整，才有條件衡量影響。預覽狀態、資格及限制均可能變動，應在每次擴圍前重新核對官方說明。
不能。它針對官方支援範圍內的工作流程依賴解析提供紀錄，不會因此固定 Mac 主機上的所有工具、環境變數、系統設定或其他建置輸入。企業應將工作流程依賴清單與 Runner 環境清單分開管理，並對每項控制標明負責人和驗收證據。
是否並用取決於依賴範圍、審查方式及官方支援規則。SHA 便於直接檢查某個引用的固定目標；lockfile 則提供其支援範圍內的依賴解析紀錄。兩者都不是安全認證，採用前應比較實際覆蓋並確認更新時能同步審查。
不會。鎖定依賴引用與隔離執行環境是不同控制面。團隊還要設定 Runner 群組存取、工作流程信任層級和簽名憑證權限，避免不可信工作流程接觸高權限主機或發布祕密。策略評估通過也不能替代這些檢查。
除非已核實資格、依賴覆蓋和更新流程，否則不宜直接全面強制。先以少量工作流程進行影子驗證，收集策略評估結果、失敗案例及 Mac 執行紀錄，再修正可能被阻擋的工作流程。預覽功能的適用範圍和操作限制，應在每次擴大前重新查看官方文件。
如果試點顯示依賴引用已可審查，但 Mac Runner 的隔離、維護責任或發布憑證承載方式仍不清楚，應先補齊環境治理，再決定要不要增加構建資源。自建 Mac 適合需要固定實體控制及長期穩定工作負載的團隊；若仍在評估容量或需要短期測試節點，可比較VNCMac 的 Mac 使用方案，再依實際工作流程決定是否租用。租用 Mac 能提供額外的遠端構建資源，但不會自動替企業設定 lockfile 審查、Runner 隔離或簽名權限。
它的用途是記錄工作流程依賴的解析結果，協助團隊核對引用對應的來源與提交；但不能因此假設整條 CI 鏈都已鎖定。請依官方文件確認 Action、可重用工作流程及本地 Action 各自的解析和鎖定邊界，並確認依賴定義由哪個儲存庫負責。
完整 SHA 是在工作流程引用中直接指定提交，容易從 YAML 看出固定目標；lockfile 則提供依賴解析紀錄，便於審查及維護其涵蓋的依賴。兩者都不會自動證明程式碼安全，也不能取代更新審查；企業應依團隊的可讀性、依賴範圍和更新流程選擇或並用。
需要。lockfile 著重於工作流程依賴引用的確定性，不會隔離已遭入侵的 Runner，也不會保護暴露在工作流程中的憑證。Mac CI 仍須按信任層級配置 Runner 存取、工作目錄與發布權限，並限制不可信程式碼接觸簽名憑證及其他敏感資料。
先在小範圍工作流程產生並檢查 lockfile，驗證新增依賴與更新能完成審查，再檢視官方策略評估結果及適用資格。記錄可能遭阻擋的工作流程並修正後，才考慮擴大範圍或強制執行。這項功能截至本文更新時仍為公開預覽，實際資格及操作限制應以官方文件為準。