GitHub Actions Lockfiles Reach General Availability to Secure Workflow Dependencies

General Availability of Lockfiles

GitHub has announced the general availability of workflow dependency lockfiles for GitHub Actions, effective October 28, 2026. This release follows a two-week public preview period. The feature is accessible across GitHub Enterprise Cloud, Enterprise Cloud with data residency, Team, and Free plans, offering the same capabilities introduced during the preview.

Addressing Dependency Resolution Weaknesses

The lockfile mechanism targets a long-standing vulnerability in how GitHub Actions resolves dependencies. Previously, references such as actions/checkout@v4 or branch names could be changed externally, allowing a compromised action to inject malicious code into a pipeline without altering the consuming repository. While pinning to full commit SHAs was an option, it reduced readability and did not secure transitive dependencies from composite actions. Lockfiles resolve both issues by recording specific commits for all direct and transitive dependencies within a .github/workflows/actions.lock file.

Tooling and Adoption

Tooling for managing lockfiles is provided through the gh actions-lock extension for the GitHub CLI, hosted in the gh-actions-lock repository. This extension generates and maintains the lockfile. Adoption can be incremental, as each dependency requires a lockfile entry once a workflow is onboarded. The Actions runtime then executes the recorded commit, regardless of where the tag or branch points. The extension also includes a verification mode to check if the lockfile is current, which can serve as a CI gate to detect discrepancies.

Dependabot Integration and Governance

To mitigate the issue of stale pins, Dependabot has been integrated with the lockfile feature. When Dependabot proposes a version update for an action in an onboarded workflow, it simultaneously updates the corresponding lockfile entry. Both changes are included in the same pull request, ensuring the workflow reference and locked commit remain synchronized without additional configuration. For organizational governance, enterprise, organization, and repository administrators can enable a "Require lockfile" policy to enforce adoption at their respective scopes.

Security Considerations

GitHub clarifies that while lockfiles guarantee the use of locked commits, they do not inherently determine the safety of those commits. The announcement advises users to review dependencies before locking them. The security value of this feature is therefore dependent on the initial review process conducted when a dependency is locked.