GitHub Actions Lockfiles Reach GA to Secure Workflow Dependencies

GitHub has made workflow dependency lockfiles for GitHub Actions generally available on October 28, 2026, two weeks after the feature entered public preview. Workflows can maintain clear tag and branch references. The runner executes the specific commits listed in the .github/workflows/actions.lock file, even if those references change later. The feature is available on GitHub Enterprise Cloud, Enterprise Cloud with data residency, Team, and Free plans. The GA release includes the capabilities from the preview.

The change targets a long-standing weakness in how Actions resolves dependencies. A reference like actions/checkout@v4 or a branch name can change. This means a hacked action can add bad code to a pipeline without altering the repository using it. Teams can pin to full commit SHAs, but this reduces readability. It also leaves transitive dependencies, like those from composite actions, unpinned. Lockfiles address both gaps by recording commits for direct and transitive dependencies.

Tooling comes through the gh actions-lock extension for the GitHub CLI, hosted in the gh-actions-lock repository, which generates and maintains the lockfile. Adoption follows the workflow. Once a workflow is onboarded, every dependency needs a lockfile entry. The Actions runtime then runs the recorded commit, no matter where the tag or branch points. This lets teams migrate incrementally rather than converting an entire organization at once. The extension has a verification mode. It checks if the lockfile is up to date without changing any files. This way, it can act as a CI gate to spot differences between workflow files and the lockfile.

Dependabot integration addresses the usual cost of pinning, which is stale pins. When Dependabot opens a version update for an action in an onboarded workflow, it also updates the matching lockfile entry. Both changes appear in the same pull request, so the workflow reference and locked commit stay in sync. GitHub says this works without additional configuration. For governance, enterprise, organization, and repository admins can enable a "Require lockfile" policy. This policy helps enforce adoption at the relevant scope.

GitHub is explicit about the limits of the mechanism. A lockfile guarantees that runs use the commits you locked, but it does not determine whether those commits are safe, and the announcement advises reviewing dependencies before locking them. The security value therefore depends on the review that happens when an entry is created or updated. In practice, the Dependabot pull request becomes the review point, and teams that auto-merge those updates will carry any malicious change straight into the lockfile.

The release arrives as GitHub tightens other Actions defaults. A November 2 changelog entry announced that pull_request_target will be blocked by default starting December 2, another change aimed at limiting how untrusted code reaches privileged workflow contexts.

For teams evaluating adoption, setup instructions are in the GitHub Docs page on workflow dependency lockfiles. A reasonable starting point is to onboard a few high-privilege workflows, such as release or deployment pipelines, add the staleness check to CI, and confirm that Dependabot's combined pull requests fit existing review practices before enabling the enterprise-wide policy.

Competing platforms have not announced a native equivalent so far. GitLab's pipeline security guidance advises users to manually pin includes and components to commit SHAs. Users should also pin images to digests. After the March 2026 supply chain incidents, GitLab introduced open-source pipeline execution policies. These policies focus on blocking known attack patterns instead of creating a dependency manifest. Microsoft's Zero Trust guidance for Azure Pipelines also suggests using SHA pinning. It advises limiting Marketplace extensions too.

CircleCI orbs use a central semantic-versioning registry instead of commit hashes. This approach keeps the registry immutable. Teams on these platforms often use cross-platform tools. For example, they might use pinner to pin tags to SHAs and add a CI verification step. They may also rely on scanners like ActionSieve to flag unpinned references.

These tools pin the reference written in the pipeline file but do not resolve transitive dependencies, which is the gap GitHub's lockfile design addresses. As with GitHub's feature, none of them judges whether a pinned dependency is trustworthy, so the review step that precedes locking remains the control that matters.