GitHub Actions locks workflow dependencies by commit with lockfiles now generally available

GitHub made the lockfiles feature for workflow dependencies in GitHub Actions generally available on October 28, 2026, two weeks after it entered public preview, according to an InfoQ report. The feature is available in GitHub Enterprise Cloud, Enterprise Cloud with data residency, Team, and Free, and the final version keeps the same capabilities that were already in preview.

The idea tackles a well-known problem for anyone who maintains pipelines on GitHub: a reference like actions/checkout@v4, or a branch name, can point to different code after the workflow was written. This means a compromised action can inject malicious code into a pipeline without anyone needing to touch the repository that uses it. Pinning to the full commit SHA already solved part of the problem, but it hurt YAML readability and didn't cover transitive dependencies, such as those pulled in by composite actions.

How the lockfile changes execution

The .github/workflows/actions.lock file records the exact commit of every dependency, direct or transitive, referenced in the workflow. Once the lockfile exists, the Actions runner executes the commit recorded there, no matter where the tag or branch cited in the YAML has moved to since then. The workflow stays readable, with @v4 or a branch name in the file, but it's the lockfile that decides what runs.

Generating and maintaining the file is handled by the gh actions-lock extension, hosted in the gh-actions-lock repository and installed via GitHub CLI. Once a workflow is brought into the process, every one of its dependencies needs a corresponding entry in the lockfile. The extension also has a verification mode that checks whether the lockfile is up to date without changing any file, which lets you use it as a CI gate to detect drift between the workflow and what's locked.

A practical point for anyone managing multiple repositories: adoption is incremental. You can bring workflows in one at a time, starting with the highest-privilege ones, without needing to convert the entire organization at once.

Dependabot joins the update cycle

The historical cost of pinning dependencies is that the pin goes stale: the tag moves forward, gets security fixes, and the commit locked in the YAML doesn't keep up. GitHub addressed this by integrating the lockfile with Dependabot. When Dependabot opens a version-update pull request for an action in a workflow that's already been brought into the process, it also updates the corresponding entry in the lockfile, and both changes show up in the same PR, with no extra configuration.

For governance, enterprise, organization, or repository admins can turn on a "Require lockfile" policy, which helps force adoption within the chosen scope. That gives security teams a way to make sure sensitive pipelines, such as release pipelines, don't go without the control even if individual teams don't prioritize the migration.

What the lockfile doesn't solve

GitHub's own announcement is direct about the mechanism's limit: a lockfile guarantees that execution uses the commit that was locked, but it doesn't guarantee that commit is safe. The recommendation is to review the dependency before locking it. In practice, this shifts the control point: the Dependabot pull request becomes the moment when someone needs to look at what's being accepted.

In short: teams that set up auto-merge for Dependabot PRs in workflows with a lockfile take any malicious change straight into the locked file, because the automation removes exactly the review the feature assumes. The lockfile reduces the attack surface from floating tags, but it doesn't replace human or automated review of the dependency's content.

Part of a broader Actions hardening effort

The lockfiles GA isn't an isolated feature. A changelog published on November 2, 2026 announced that pull_request_target will be blocked by default starting December 2, 2026, another change aimed at limiting how untrusted code reaches privileged workflow contexts. For anyone already dealing with pipeline security, the two changes are part of the same push: closing off ways for unverified-source code to execute inside Actions.

How other CI platforms solve the same problem

No direct competitor has announced a native feature equivalent to GitHub's lockfile so far. Each platform handles the problem differently:

On GitLab, after the March 2026 supply chain incidents, official guidance shifted to recommend manual SHA pinning for includes and components, and digest pinning for images; the pipeline execution policies introduced afterward focus on blocking known attack patterns, not on creating a dependency manifest. On Azure Pipelines, Microsoft's Zero Trust guidance follows the same line of manual SHA pinning, plus the recommendation to restrict Marketplace extensions. CircleCI departs from the commit model: orbs use a central registry with semantic versioning kept immutable.

Teams on these platforms often turn to cross-platform tools, such as pinner to lock tags to SHA with CI verification, or scanners like ActionSieve to flag unpinned references. These tools lock the reference written in the pipeline file, but they don't resolve the transitive dependency, which is exactly the gap GitHub's lockfile design targets. As with GitHub's feature, none of them judge whether the pinned dependency is trustworthy: review remains the control that matters.

What changes for CI/CD maintainers in Brazil

For teams already running GitHub Actions in production, the feature arrives with no extra license cost on the plans mentioned, including Free, which removes the budget excuse for not adopting dependency pinning in deployment pipelines. The entry point suggested by the InfoQ report is to start with the highest-privilege workflows, such as release or deployment ones, add the lockfile staleness check as a CI gate, and confirm that Dependabot's combined PRs fit the existing review process before turning on the policy at the enterprise level.

It's worth rereading the InfoQ report before running the extension in production, because setting up verification as a mandatory gate changes the behavior of PRs that currently pass without friction. For anyone reviewing pipeline security on small squads, the immediate practical gain is reducing reliance on manual discipline around SHA pinning, a habit that rarely survives deadline pressure.

Source

GitHub Actions Lockfiles Reach GA to Secure Workflow Dependencies - InfoQ