What GitHub Actions lockfiles mean for your CI

GitHub made workflow dependency lockfiles for GitHub Actions generally available on October 28, 2026, according to InfoQ. Once you onboard a workflow, the runner executes the exact commits recorded in a .github/workflows/actions.lock file. That covers the actions you reference directly and the actions those actions pull in. It holds even if the tag or branch your workflow names is later moved. That one rule is what makes the feature matter. A compromised third-party action can no longer change what your pipeline runs without a change to your own repository.

The background you need

A GitHub Actions workflow is a YAML file in .github/workflows/. Most steps don’t contain their own logic. They call a reusable action with a line like uses: actions/checkout@v4. The part after the @ is a ref. It can be one of three things: a tag (v4), a branch (main), or a full commit SHA.

Tags and branches are pointers. A branch moves forward with every new commit, by design. A tag is meant to stay put. But anyone who controls the repository can delete a tag and recreate it pointing at different code. Maintainers also commonly move major-version tags like v4 on purpose, so you get fixes without editing your workflow. So @v4 really means whatever v4 points to when this job starts.

A commit SHA is different. It is a hash computed from the commit’s contents and history. Change one byte and you get a different SHA. Pinning to a SHA means you get the same code on every run.

An analogy helps here. A tag is like a street address. The building at that address can be torn down and replaced, and the address still works. A SHA is like a fingerprint of the exact building you inspected. The analogy breaks in one important way. A fingerprint proves identity, not good character. A SHA only proves you are running the same code you saw before. It does not prove that code was ever safe.

Why does this matter? A supply-chain attack on Actions usually works like this. An attacker gains control of a popular action’s repository, for example through stolen maintainer credentials. They point an existing tag at malicious code. Every workflow that references that tag runs the attacker’s code on its next run. Many workflows hold secrets: cloud credentials, deploy keys, package-publishing tokens. That makes them valuable targets.

There is one more layer. A composite action is an action built out of other actions. It has its own uses: lines, and you never see them in your workflow file. Those are transitive dependencies. You might pin the outer action to a SHA while the actions inside it still reference movable tags.

If you have used npm, Poetry or Cargo, you already know what a lockfile is. The manifest says what you asked for. The lockfile records exactly what got resolved, including dependencies of dependencies. GitHub has now applied that idea to Actions.

What actually changed

Some of this was already possible. You could always pin actions to full commit SHAs by hand. According to InfoQ, that approach had two problems. It makes workflows harder to read. It also leaves transitive dependencies, such as those inside composite actions, unpinned.

Here is what is new, per InfoQ’s report:

• A lockfile the runner enforces. The lockfile records commits for both direct and transitive dependencies. The runtime runs the recorded commit, no matter where the tag or branch now points. Your workflow files can keep readable tag references.
• CLI tooling. A GitHub CLI extension, gh actions-lock, hosted in the gh-actions-lock repository, generates and maintains the lockfile. It has a verification mode that checks whether the lockfile is up to date without changing any files. You can run it as a CI gate to catch drift between workflow files and the lockfile.
• Per-workflow adoption. Onboarding happens one workflow at a time. Once a workflow is onboarded, every dependency it uses needs a lockfile entry. You don’t have to convert a whole organization at once.
• Dependabot support. When Dependabot opens a version update for an action in an onboarded workflow, it also updates the matching lockfile entry in the same pull request. GitHub says this needs no additional configuration.
• A policy switch. Enterprise, organization and repository admins can turn on a “Require lockfile” policy to enforce adoption at that scope.

InfoQ lists the feature as available on GitHub Enterprise Cloud, Enterprise Cloud with data residency, Team and Free plans. GA came two weeks after the public preview and includes the preview’s capabilities.

This is part of a wider tightening. InfoQ also points to a November 2 changelog entry: the pull_request_target trigger will be blocked by default starting December 2. That trigger runs in the context of the base repository, so it can expose secrets to workflows triggered by pull requests from forks. Both changes aim to limit how untrusted code reaches privileged workflows.

What it means for developers who ship apps

The main benefit is simple. In an onboarded workflow, a moved tag no longer changes what runs. That also applies to actions buried inside composite actions you never read. You get that without turning every uses: line into a 40-character hash.

The main limit matters just as much. GitHub is explicit that a lockfile guarantees runs use the commits you locked. It does not decide whether those commits are safe, and GitHub advises reviewing dependencies before you lock them. InfoQ draws the practical conclusion. The Dependabot pull request becomes the review point. Teams that auto-merge those updates will carry any malicious change straight into the lockfile.

So the lockfile moves the risk to a moment you control: when an entry is created or updated. If nobody looks at that moment, you have frozen a problem instead of preventing one.

InfoQ suggests a starting order:

1. Onboard a few high-privilege workflows first, such as release or deployment pipelines.
2. Add the staleness check (the verification mode) to CI.
3. Confirm that Dependabot’s combined pull requests fit your existing review practice.
4. Only then turn on the enterprise-wide policy.

Separately, check whether any of your workflows use pull_request_target before December 2.

If you also run pipelines elsewhere, InfoQ reports that no competing platform has announced a native equivalent so far. GitLab’s pipeline security guidance tells users to pin includes and components to commit SHAs by hand and to pin images to digests. After the March 2026 supply chain incidents, GitLab introduced open-source pipeline execution policies. Those focus on blocking known attack patterns rather than creating a dependency manifest. Microsoft’s Zero Trust guidance for Azure Pipelines also recommends SHA pinning and limiting Marketplace extensions. CircleCI orbs use a central semantic-versioning registry that is kept immutable, rather than commit hashes. Cross-platform tools such as pinner and ActionSieve can pin or flag unpinned references. According to InfoQ, they don’t resolve transitive dependencies.

What we don’t know yet

The report leaves several practical questions open:

• GitHub Enterprise Server. InfoQ lists Enterprise Cloud, Team and Free plans. It does not mention self-hosted Enterprise Server.
• Container images. Some actions run Docker images. The report talks about locking commits. It does not say whether images those actions pull are pinned too.
• Reusable workflows. The report covers actions and composite actions. It does not say how workflows that call other workflows are handled.
• Defaults. The “Require lockfile” policy is opt-in. The report gives no sign of whether GitHub plans to make lockfiles a default, the way it is changing pull_request_target.
• Other platforms. Whether GitLab, Azure Pipelines or CircleCI will build something similar is unknown. InfoQ only says none has announced one so far.