GitHub Actions lockfile預覽：固定提交仍需程式碼審查
Dev
瀏覽 6
審查過的workflow後來執行不同程式碼，團隊究竟批准了什麼？GitHub於10月14日發布workflow lockfile公開預覽。關鍵是指定誰審查固定提交，以及誰批准下一次更新。
先確認開放範圍
修訂後的公告包括GitHub Enterprise Cloud、具資料落地選項的Enterprise Cloud、Team與Free。它仍是預覽。官方儲存庫說明不支援GHES，1.0之前格式與行為可能改變。請記錄核實日期與擴充功能版本。
區分標籤與批准的提交
擴充功能產生.github/workflows/actions.lock，記錄已接入workflow的action、遞移相依性及可重複使用workflow相依性的提交。它減少參照移動後程式碼無聲改變的風險，但不保證固定程式碼安全。
從容易審查的小改動開始
以下是維運建議：選擇沒有正式環境密鑰與部署權限的測試workflow，列出uses參照、維護者及用途。在同一PR審查workflow與lockfile差異，連結實際執行紀錄，再擴大強制範圍。
為更新指定負責人
官方README中的gh actions-lock --verify不寫入檔案。--verify-local只是離線結構檢查，不能取代可信度驗證。分別記錄CI結果與程式碼審查，確定負責人、停止條件與復原辦法。本文沒有安裝擴充功能。
公告說明，Dependabot更新已接入workflow的action版本時，會在同一PR重新產生對應lockfile項目。自動差異也需要批准。本文建議同時檢查參照、提交、權限與新程式碼的外部通訊變化。
可重現不等於安全結論。官方提及社群回饋，但不能據此推斷事故減少率或所有環境相容性。接入前閱讀最新README，為審查、固定、更新分別確定負責人。
官方來源
2026年10月15日核實；產品行為與維運建議分開說明。