GitHub has put workflow dependency lockfiles into public preview for GitHub Actions. A repository can keep readable action tags or branches in its workflow YAML while the runner executes the exact commits recorded in .github/workflows/actions.lock.
The October 14 release covers direct actions, their transitive dependencies and reusable workflows. It addresses the risk that a reviewed tag or branch can later move, but it does not establish that the locked code is safe.
The lockfile becomes the execution record
GitHub’s documentation says the machine-generated file has two sections. workflows records the dependencies used by each onboarded workflow, while dependencies records the commit resolved for each reference. The gh actions-lock GitHub CLI extension creates and maintains the file; GitHub says it should not be edited by hand.
After a workflow is onboarded, every dependency it uses must have a corresponding lockfile entry. GitHub Actions then runs the recorded commit even if the tag or branch in the workflow file resolves somewhere else. A repository can onboard one workflow at a time, which gives teams a migration path that does not require converting the whole automation estate in one pull request.
Coverage extends beyond manual SHA pinning
GitHub has historically recommended pinning third-party actions to a full-length commit SHA. The new documentation says workflow-file SHA pinning is no longer necessary for repositories using the lockfile because the lockfile includes transitive dependencies, preserves readable workflow references and records the identity of the source repository.
That repository identity matters when a dependency is transferred or recreated under a familiar owner and name. The lockfile records a numeric repository ID as well as the resolved commit, giving the runner another stable identity check beyond a mutable string reference.
Updates still require review
Dependabot can update the matching lockfile entry in the same pull request when it proposes a version change for an action in an onboarded workflow. Maintainers can also run a check that reports whether the lockfile is stale without changing files. Administrators have a separate public-preview policy that can require lockfiles at enterprise, organization or repository scope.
Those controls improve reproducibility and make unexpected reference movement visible. They do not evaluate whether a dependency was malicious before it was locked, whether a new version is trustworthy or whether an action has more token and secret access than it needs. Independent GitHub Actions security guidance continues to emphasize narrow permissions, reviewed dependencies and controlled secret exposure.
The preview is available for GitHub Enterprise Cloud, Enterprise Cloud with data residency, Team and Free plans. The useful adoption sequence is therefore operational rather than cosmetic: generate the file, review the resolved repositories and commits, onboard selected workflows, require lockfile freshness in CI and let updates return through normal pull-request review.
