On 28 October 2026 GitHub moved Actions workflow dependency lockfiles from public preview to general availability. It is available on the Free, Team and Enterprise Cloud plans.
The problem it fixes. Most apps are built and released by automated workflows that pull in third-party actions, which are small shared programs, referenced by a tag or branch name. Those names can move. If someone compromises an action and repoints its tag, your next build quietly runs their code, with access to your signing keys and secrets.
What a lockfile does. A new command line extension, gh actions-lock, writes a file at .github/workflows/actions.lock. It records the exact commit of every action a workflow uses, including the actions those actions depend on. Workflows keep readable tag names, but Actions runs the locked commit. Dependabot updates the lockfile in the same pull request as a version bump, and administrators can apply a “Require lockfile” policy across an organisation.
The caveat. GitHub is explicit that a lockfile guards against unexpected change. It does not prove a dependency is safe. Someone still has to review what gets locked.
What it means
The direction is clear: build pipelines are now treated as part of the product’s security surface, not background plumbing. That matters more as AI agents write code and trigger more automated runs.
So what
Ask your app supplier a plain question: are our build and release workflows pinned, and who reviews changes to them? It is a cheap control with a clear yes or no answer. Our custom software development projects include release pipelines you own and can inspect. To discuss, start a project.