GitHub Actions gets lockfiles to pin workflow dependencies

GitHub announced on October 14, 2026, via its official changelog, the public preview of lockfiles for workflow dependencies in GitHub Actions. The feature is available for GitHub Enterprise Cloud and for GitHub Enterprise Cloud with data residency, and it solves a problem that any team that has already suffered or feared a supply chain attack in CI/CD recognizes instantly.

The problem the lockfile addresses

A GitHub Actions workflow normally references an action by tag or branch, something like actions/checkout@v4. The annoying detail is that tags and branches can move after someone has reviewed and approved that workflow. If the referenced action is compromised and the maintainer (or an attacker) reassigns the v4 tag to a malicious commit, the workflow starts running code different from what was audited, without a single line of the team's repository having changed.

This vector is not hypothetical: episodes of popular compromised actions in the GitHub marketplace have already shown how an apparently unchanged workflow can start leaking secrets or executing malicious payload overnight. The lockfile does not replace reviewing the dependency, GitHub's own changelog is explicit about this: pinning a commit does not guarantee that commit is safe, it only guarantees it won't change under the team's feet without warning.

How it works in practice

The mechanics are the same any dev already knows from other ecosystems: package-lock.json in npm, poetry.lock in Python, go.sum in Go. The difference is that now the lock's target isn't an application dependency, it's the CI/CD orchestration itself.

The flow proposed by GitHub works like this:

1. Install the gh actions-lock extension for GitHub CLI, maintained in the public gh-actions-lock repository.
2. Generate the .github/workflows/actions.lock file, which records the exact commits of each action used, including transitive dependencies (an action that calls another action) and reusable workflows.
3. Review the generated lockfile and commit it together with the workflow changes.
4. From there, the workflow becomes "onboarded": GitHub Actions starts requiring a lockfile entry for each dependency and always executes the recorded commit, no matter where the tag points to afterward.

Adoption is gradual, workflow by workflow, it's not a button that locks the entire repository at once. This matters because you can start with the pipelines that touch production or publish artifacts, and leave low-risk workflows for later.

Checking for outdated lockfiles and mandatory policy

The extension also offers a check mode that verifies whether the lockfile is in sync with the workflow, without modifying anything, designed to run as a CI check. This avoids the classic scenario of a lockfile nobody updates, which silently stops reflecting the pipeline's reality.

In addition, GitHub released in preview the Require lockfile policy, which enterprise, organization, or repository admins can enable to require a lockfile across all workflows under that scope. This turns the lockfile from an optional practice of disciplined teams into a compliance requirement, something that makes a difference in large organizations where not every squad will adopt good security practices on its own.

Dependabot joins the game

A lockfile that pins commits has an obvious cost: it also pins updates. GitHub solved this by integrating the feature with Dependabot. When Dependabot opens a version update pull request for an already onboarded action, it regenerates the corresponding entry in the lockfile in the same PR, keeping the workflow reference and the pinned commit in sync without extra configuration.

In practice, this removes the main friction of any lock system: the team doesn't need to choose between security (staying pinned to an old commit) and updating (giving up the lock every time an action bumps its version). Dependabot was already used to keep actions updated, now it also takes care of the lockfile.

When this doesn't apply to you yet

The detail that matters most for the Brazilian dev is availability: the preview is restricted to GitHub Enterprise Cloud and GitHub Enterprise Cloud with data residency. Those on GitHub.com free, Pro, or Team don't have access yet, only organizations with an Enterprise Cloud license.

This means that a good part of teams at startups and smaller squads will keep being exposed to the same moving-tag risk for a while, until (if) the feature leaves preview and moves down to other plans. It's also worth remembering that a lockfile is not a silver bullet: it freezes the commit, it doesn't audit the code in that commit. Teams that skip reviewing the action before locking it are just pinning a potentially bad dependency with more confidence than they should have.

For those already running critical pipelines on Enterprise Cloud, the natural path is to start by onboarding the workflows that publish releases or touch production secrets, enable the outdated-lockfile check as a CI gate, and only then consider the Require lockfile policy at organization scope. Forcing the policy before any team has run the flow manually tends to generate friction and hastily generated lockfiles, without real review, which cancels out much of the security gain the feature promises.