# GitHub Actions adds workflow lockfiles that pin transitive dependencies GitHub Enterprise Cloud can now lock Actions workflows to reviewed commits—including transitive actions—without replacing readable version tags with SHA strings. The October 14 preview adds a new enforceable CI supply-chain control, with adoption and scope limits. GitHub Actions lockfiles are in public preview for Enterprise Cloud, pinning direct and transitive actions and integrating with Dependabot. They don't prove a dependency is safe. - Status: Active - Published: 2026-10-15T17:32:18+13:00 - Updated: 2026-10-15T17:32:18+13:00 - Categories: Web Development, Cloud & Infrastructure, Deployment & DevOps, Developer Tools - Tags: CI/CD, dependency management, GitHub, GitHub Actions, supply chain security - Canonical HTML: https://beyondthe.news/dossiers/github-actions-workflow-lockfiles-enterprise-cloud-preview ## 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. ## Key details - Released October 14, 2026; public preview for GitHub Enterprise Cloud and Enterprise Cloud with data residency. - Lockfile path: .github/workflows/actions.lock; official GitHub CLI extension: github/gh-actions-lock. - Locks exact action commits and transitive dependencies, plus reusable workflow references; reusable workflows own their nested dependency lockfiles. - Repository IDs and owner IDs help detect unexpected upstream repository identity changes. - Dependabot updates lockfiles for already-onboarded workflows; it does not onboard new workflows. - Require lockfile policy supports staged evaluation and active enforcement. - The CLI extension is a pre-1.0 technical preview; GitHub Enterprise Server is unsupported. ## Builder takeaways - Identify GitHub Actions workflows with deploy keys, publishing tokens or production access and pilot lockfiles there first. - Use gh actions-lock and review the generated diff; add gh actions-lock --verify to CI. - Configure CODEOWNERS and approvals for .github/workflows/actions.lock, and let Dependabot update onboarded workflows. - Do not mistake lockfiles for a vulnerability scanner; review and harden the underlying actions, jobs and permissions. - Confirm Enterprise Cloud eligibility; don't assume the preview works on Free/Team or GitHub Enterprise Server. ## What to watch - Preview expansion to other plans or GitHub Enterprise Server and general availability. - Changes to the pre-1.0 extension and lockfile schema. - How enterprise Require lockfile enforcement interacts with composite actions, local actions and reusable workflows. - Independent operating reports on migration friction and dependency update failure modes. ## Uncertainties - Preview behaviour, supported syntax and CLI flags may change before general availability. - Lockfiles do not prove dependencies are safe or protect arbitrary runtime downloads. - No independent fleet-wide measurement of adoption, attack reduction or operational overhead is yet available. ## Sources - [GitHub Actions workflow lockfiles in public preview](https://github.blog/changelog/2026-10-14-github-actions-workflow-lockfiles-in-public-preview) — GitHub · primary · 2026-10-14T00:00:00+13:00. Dated availability, scope, enforcement and Dependabot integration. - [Workflow dependency lockfiles](https://docs.github.com/en/enterprise-cloud@latest/actions/concepts/security/workflow-dependency-lockfiles) — GitHub Docs · primary. Technical scope including transitive dependencies, repository IDs and reusable workflows. - [gh-actions-lock](https://github.com/github/gh-actions-lock) — GitHub · primary. Inspectable CLI implementation, installation instructions and preview limitations. - [Enforcing lockfiles for action dependencies](https://docs.github.com/en/actions/how-tos/administer/enforce-workflow-lockfiles) — GitHub Docs · primary. Evaluate/Active policy rollout, CI verification and review guidance.