What changed
On October 14, 2026 GitHub released workflow dependency lockfiles in public preview for GitHub Enterprise Cloud, including data-residency tenants. A repository can generate .github/workflows/actions.lock with the gh-actions-lock CLI extension. An onboarded workflow continues to display a tag or branch in YAML, but GitHub Actions executes the recorded commit, including dependencies inside composite actions. Administrators can pilot and require lockfiles; Dependabot updates the lockfile when it bumps an onboarded action. This is a running platform feature, not merely the security roadmap announced earlier in 2026.
Why it matters
Mutable tags let a compromised action maintainer silently change what runs in downstream CI pipelines. Lockfiles make a code change visible and reviewable while reducing the operational cost of manually pinning full SHAs. For teams whose CI jobs have release credentials or deploy access, dependency review becomes a concrete gate. The preview is currently an Enterprise Cloud capability, not a free-tier or GitHub Enterprise Server feature, and pinning cannot certify that a reviewed commit is benign.
A repository lockfile controls what executes
The GitHub CLI extension gh-actions-lock generates .github/workflows/actions.lock. For each onboarded workflow it records action references and commit SHAs, plus source repository owner and repository IDs to detect unexpected repository identity changes. GitHub Actions runs the locked commit even when a tag or branch moves. Composite-action transitive dependencies are included; reusable workflows are locked as references, but their own transitive actions are covered by the lockfile in the repository defining that reusable workflow.
Adoption is gradual but strict after onboarding
Teams can onboard one workflow at a time. Once a workflow is onboarded, all of its action dependencies must have valid entries. The extension can verify lockfiles without rewriting them, while the Require lockfile policy can be piloted in Evaluate mode before enforcement. An Active policy can block un-onboarded targeted workflows. GitHub recommends reviewing lockfile changes as code and requiring code-owner approval for the file.
Dependabot maintains—but does not start—coverage
Dependabot version-update pull requests regenerate matching lockfile entries for workflows already onboarded. It does not automatically onboard new workflows. Teams adding a new workflow or uses dependency should regenerate and review the lockfile, then verify it in CI. A moved tag or changed repository identity warrants investigation rather than automatically accepting a replacement.
Scope and security limits
The October 14 release covers GitHub Enterprise Cloud and Enterprise Cloud with data residency. GitHub Enterprise Server is not supported by the current CLI extension. The extension remains pre-1.0 and its lockfile format or flags may change. Locking records the code to execute; it does not scan that code for malware, stop malicious reviewed dependencies, or eliminate risks from scripts downloaded at runtime. Teams still need dependency review, minimal job permissions and secret isolation.
What to do now
For an eligible repository, install the official extension with gh extension install github/gh-actions-lock; run gh actions-lock; review the full workflow and actions.lock diff; commit both; and add gh actions-lock --verify to a pull-request check. Start with workflows that publish artifacts or deploy production services, and test policy Evaluate mode before switching to Active. Treat the lockfile as a security-sensitive review artifact rather than a generated file to auto-approve.