GitHub 在 2026 年 10 月 28 日宣布 Actions workflow dependency lockfiles 正式可用。團隊可以在 workflow 裡保留易讀的 actions/checkout@v5 等 tag 寫法，由 .github/workflows/actions.lock 記錄實際執行的 commit；即使上游 tag 後來移動，runner 仍執行已鎖定版本。

這不只是把 YAML 裡的完整 SHA 搬到另一個檔案。Lockfile 也能涵蓋 action 內部使用的遞迴相依，並記錄來源 repository 的數字識別，降低 tag 被移動、repository 名稱遭替換或間接 action 未被盤點的風險。但它只固定「執行哪一份 action 程式碼」，不證明那份程式碼安全，也不鎖定 runner image、輸入、secret 或可重用 workflow 的內部相依。

正式版提供了哪些能力

GitHub 的 GA 公告列出 Free、Team、GitHub Enterprise Cloud 與 data residency 版本都可使用 lockfile。gh actions-lock CLI extension 會產生 actions.lock，團隊可逐一讓 workflow 納入；納入後，每個 action dependency 都必須出現在 lockfile，執行時採用檔案記錄的 commit。

Dependabot 若為已納入的 workflow 更新 action 版本，也會在同一個 pull request 重建對應 lockfile entry，不需額外設定。管理者還可使用 Require lockfile policy 強制採用，並用 verify 命令在 CI 檢查檔案是否過期。

官方同時警告：lockfile 能防止未預期的相依變動，卻不會判斷相依本身是否安全。產生檔案前仍要審查 action 的來源、權限、維護狀態與版本；自動更新後也不能只因為 CI 通過就直接合併。

與完整 SHA pinning 的差別

傳統做法是在每個 uses: 寫完整 commit SHA，再用註解標示版本。這能固定直接相依，但 action 若是 composite action、內部又呼叫另一個 action，使用方通常無法在自己的 workflow 鎖定那一層。Lockfile 可保存直接與遞迴相依，YAML 仍維持 tag 可讀性。

GitHub Docs說明，每筆相依會記錄 ref、commit、owner ID 與 repository ID。執行時，鎖定 commit 必須仍可從記錄的 branch 或 tag 到達；只存在於 fork、歷史重寫後無法到達，或來源 repository 身分不符時，workflow 會被拒絕。

不過，跨 repository 呼叫的 reusable workflow 是重要例外。呼叫端 lockfile 不會鎖住被呼叫 workflow 裡的 action；應以完整 SHA 固定 jobs.JOB_ID.uses，並由 reusable workflow 所在 repository 維護自己的 lockfile。若企業直接啟用強制政策而漏掉共用 workflow，原本正常的 pipeline 可能全部被擋下。

先盤點，再逐步納入

第一步列出所有 .github/workflows/*.yml、本地 action、外部 action 與 reusable workflow。記錄觸發器、token permissions、secret、environment、runner、部署目標及維護人。先處理 release、production deploy、套件發布與能讀取高權限 secret 的 workflow，因為上游 action 被替換時，這些流程的影響最大。

第二步檢查每個 ref 是否仍是支援版本，並確認 repository 是預期官方來源。不要把目前解析到的 commit 不經審查就鎖定；lockfile 只會忠實保存當下結果。第三方 action 若缺乏更新、使用過度權限或來源不清楚，應先替換或改成本地受控腳本。

第三步安裝官方指向的 gh actions-lock extension，先選一個低風險 workflow 產生 lockfile。檢查 workflow 變更與 actions.lock 的直接、遞迴相依，再建立 pull request 讓 CI 跑完。技術社群在公開預覽期間的實際操作紀錄也驗證了檔案生成、tag 移動後仍執行鎖定 commit，以及未更新時停止執行等行為；GA 後仍應在自己的 runner 與政策組合重測。

第四步把 gh actions-lock --verify 放進 pull request required check，防止新增 action 卻漏更新檔案。已使用 Dependabot 管理 GitHub Actions 的 repository，可讓它維持既有覆蓋；但 Dependabot 不會自動把從未納入的 workflow 加進 lockfile，所以仍需明確的 onboarding 流程。

審查 lockfile 才能形成控制

GitHub 的 enforcement 指南建議把 .github/workflows/actions.lock 加進 CODEOWNERS，由負責 build security 的人審查。Reviewer 應比對 ref 是否為預期版本、commit 是否合理、來源 owner／repository ID 是否改變、遞迴相依是否新增，以及 release notes 與風險公告。

Lockfile diff 出現大量變更時，不要讓自動格式化掩蓋來源切換。可把 action 更新拆成小型 pull request，保存上游版本說明與驗證結果。高權限 workflow 的變更應額外檢查 permissions、OIDC audience、environment approval、secret scope 與允許的網路目的地，因為這些不在 lockfile 的保護範圍內。

若使用 self-hosted runner，還要考慮工作區殘留、網路可達範圍與長期憑證；鎖定 action commit 不會隔離不受信任程式。來源 pull request 可否觸發高權限 workflow、pull_request_target 是否檢出不受信任分支，也需要獨立威脅模型。

強制政策要最後開

先在少數 repository 觀察一到兩個正常更新週期，記錄 verify 失敗、Dependabot 更新、reusable workflow 與緊急修補流程，再擴大範圍。Enterprise Cloud 可先用 Evaluate mode 查看影響；GitHub 提醒，Active 的 Require lockfile policy 會阻擋所有被政策涵蓋、但未納入 lockfile 的 workflow，即使同一 repository 其他流程已納入。

例外也要有期限。緊急事件若必須暫時調整政策，記錄核准者、理由、受影響 workflow、補做 lockfile 與恢復政策的時間；不要為了讓 pipeline 恢復就永久關閉驗證。回滾方案則應包含上一版 lockfile、workflow 以及可安全重跑的 release artifact。

導入完成的標準不是「repository 多了一個 actions.lock」，而是每個高風險 workflow 都有相依清單、更新機制、code owner 審查、verify check 與 reusable workflow 邊界。Lockfile 把 CI/CD 依賴變成可重現與可稽核的資料；搭配最小權限、固定 reusable workflow、runner 隔離與人工審查，才會真正降低供應鏈風險。