GitHub has made workflow dependency lockfiles for GitHub Actions generally available, a feature that aims to close a long-standing weakness in how Actions resolves dependencies by recording exact commits for direct and transitive dependencies.
The lockfiles became generally available on October 28, 2026, two weeks after entering public preview, and are available on GitHub Enterprise Cloud, Enterprise Cloud with data residency, Team, and Free plans. A reference like actions/checkout@v4 or a branch name can change, meaning a hacked action could add bad code to a pipeline without altering the repository using it. Teams can pin to full commit SHAs, but that reduces readability and leaves transitive dependencies, such as 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. Once a workflow is onboarded, every dependency needs a lockfile entry, and the Actions runtime runs the recorded commit regardless of where the tag or branch points. The extension has a verification mode that checks if the lockfile is up to date without changing any files, allowing it to act as a CI gate.
Dependabot integration addresses the usual cost of pinning, stale pins. When Dependabot opens a version update for an action in an onboarded workflow, it also updates the matching lockfile entry, keeping the workflow reference and locked commit in sync. GitHub says this works without additional configuration.
For governance, enterprise, organization, and repository administrators can enable a "Require lockfile" policy to help enforce adoption at the relevant scope.
GitHub is explicit about the limits. 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 depends on the review that happens when an entry is created or updated. Teams that auto-merge Dependabot updates will carry any malicious change 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.
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 and pin images to digests. After the March 2026 supply chain incidents, GitLab introduced open-source pipeline execution policies that 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 and limiting Marketplace extensions. CircleCI orbs use a central semantic-versioning registry instead of commit hashes, keeping the registry immutable. Teams on these platforms often use cross-platform tools such as pinner to pin tags to SHAs and add a CI verification step, or 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, the gap GitHub's lockfile design addresses. None of them judges whether a pinned dependency is trustworthy, so the review step that precedes locking remains the control that matters.
Analysis
Why This Matters
- The feature directly addresses a vulnerability pattern that has been exploited in software supply chain attacks, where a compromised action's tag or branch reference is changed to point to malicious code.
- For teams using GitHub Actions, lockfiles provide a practical way to pin both direct and transitive dependencies, reducing the risk of supply chain compromise without sacrificing readability of workflow files.
- The Dependabot integration means the feature does not add a maintenance burden, but teams that auto-merge updates could negate the security benefit, so review processes remain critical.
Background
GitHub Actions has long had a weakness: references to actions using tags or branch names can change, meaning an action repository that is compromised can silently inject malicious code into workflows that use it. Pinning to commit SHAs prevents this for direct dependencies but not transitive ones. The lockfiles feature, now generally available, records the specific commit for every dependency in a .github/workflows/actions.lock file, and the runner enforces those commits. GitHub has introduced other security changes, such as blocking pull_request_target by default from December 2, as part of a broader tightening of Actions defaults.
Key Perspectives
GitHub: Describes the lockfile as guaranteeing that runs use the commits you locked, but notes it does not determine whether those commits are safe, advising review of dependencies before locking.
GitLab: Pipeline security guidance advises users to pin includes and components to commit SHAs and pin images to digests. GitLab introduced open-source pipeline execution policies after the March 2026 supply chain incidents, focusing on blocking known attack patterns rather than creating a dependency manifest.
Microsoft: Zero-trust guidance for Azure Pipelines suggests using SHA pinning and limiting Marketplace extensions.
CircleCI: Orbs use a central semantic-versioning registry instead of commit hashes, keeping the registry immutable.
What to Watch
- Whether competing platforms such as GitLab, Microsoft or CircleCI announce native lockfile features in response.
- Whether the Dependabot integration leads to the workflow GitHub expects, combined pull requests becoming review points, or whether teams auto-merge and negate the security value.
- The effect of the enterprise "Require lockfile" policy on adoption, especially in large organizations.
Checked
12 claims in this story checked against 1 source: 12 supported.
Show each claim
- SupportedGitHub Actions workflow dependency lockfiles have reached general availability.InfoQ: “GitHub has made workflow dependency lockfiles for GitHub Actions generally available”
- SupportedThe feature aims to address a long-standing weakness in how Actions resolves dependencies.InfoQ: “The change targets a long-standing weakness in how Actions resolves dependencies.”
- SupportedThe feature includes Dependabot integration and administrator policy controls.InfoQ: “For governance, enterprise, organization, and repository admins can enable a "Require lockfile" policy.”
- SupportedThe lockfiles became generally available on October 28, 2026.InfoQ: “GitHub has made workflow dependency lockfiles for GitHub Actions generally available on October 28, 2026”
- SupportedThe general availability release came two weeks after public preview began.InfoQ: “two weeks after the feature entered public preview”
- SupportedThe feature is available on Enterprise Cloud, Enterprise Cloud with data residency, Team, and Free plans.InfoQ: “The feature is available on GitHub Enterprise Cloud, Enterprise Cloud with data residency, Team, and Free plans.”
- SupportedA changeable action reference or branch name can allow a hacked action to add bad code to a pipeline without changing the using repository.InfoQ: “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.”
- SupportedPinning to full commit SHAs leaves transitive dependencies, such as those from composite actions, unpinned.InfoQ: “It also leaves transitive dependencies, like those from composite actions, unpinned.”
- SupportedLockfiles record commits for direct and transitive dependencies.InfoQ: “Lockfiles address both gaps by recording commits for direct and transitive dependencies.”
- SupportedOnce a workflow is onboarded, every dependency needs a lockfile entry and the runtime runs the recorded commit regardless of where the reference points.InfoQ: “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.”
- SupportedWhen Dependabot opens an action version update for an onboarded workflow, it updates the matching lockfile entry.InfoQ: “When Dependabot opens a version update for an action in an onboarded workflow, it also updates the matching lockfile entry.”
- SupportedA lockfile does not determine whether its locked commits are safe, and the announcement advises reviewing dependencies before locking them.InfoQ: “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.”
