GitHub Actions Lockfiles Pin Every Dependency to a Commit. They Don't Vet Any of Them.

GitHub put workflow lockfiles for GitHub Actions into public preview on October 14 and declared them generally available on October 28. A lockfile records the exact commit behind every action a workflow uses, including the actions those actions pull in, and runs then execute those recorded commits even if a tag or branch is later moved. It does not pin calls to reusable workflows; an earlier version of this article said it did, and the October 28 update below explains the correction. The problem it targets: a workflow you reviewed last month can run different code today, because the v4 it points at is a label someone can repoint. GitHub changelog, preview · GitHub changelog, GA

For teams whose CI now runs coding agents, third-party review bots and a growing pile of marketplace actions, the feature reopens a practical choice: keep hand-pinning SHAs in YAML, or adopt a lockfile and enforce it by policy. GitHub does not frame the feature around AI agents. That angle is ours.

What shipped

Item	Detail
Status	Generally available since October 28, after a public preview from October 14 (lockfiles and the enforcement policy)
Plans	Free, Team, Enterprise Cloud, Enterprise Cloud with data residency
Tooling	gh actions-lock, a GitHub CLI extension from the public gh-actions-lock repository
File	.github/workflows/actions.lock, committed and reviewed like any other change
Scope	Actions and their transitive dependencies. Calls to reusable workflows are not pinned; a reusable workflow’s own dependencies belong to the lockfile of the repository that defines it
Enforcement	“Require lockfile” policy for enterprise, organization and repository admins
Dependabot	Regenerates the matching lockfile entry in the same version-update pull request, for onboarded workflows

All rows: GitHub changelog, preview · GitHub changelog, GA · GitHub Docs: workflow dependency lockfiles. An editor’s note on the preview page updated the plan list on launch day; the GA post lists the same four plans.

Adoption is per workflow. Once a workflow is onboarded, every dependency it uses needs an entry in the lockfile. The CLI can also confirm the lockfile is current without changing any files, which is meant to run as a CI check. Neither changelog names the subcommand for that check; the extension’s README does, as gh actions-lock --verify. GitHub changelog · gh-actions-lock README

Why SHA pinning wasn’t enough

GitHub’s docs tell users to pin third-party actions to a commit SHA, warning that a tag can be moved or deleted if a bad actor gains access to the repository storing the action. Its secure-use reference now describes a dependency lockfile as the stronger option, superseding SHA pinning for repositories that adopt one. GitHub Docs: secure use reference

The gap is in what a uses: line can reach. Pinning some-org/deploy@<sha> freezes that action’s code. If it is a composite action that itself calls other actions by tag, those inner references can still move, and nothing in your YAML shows them. The lockfile extends the pin through that dependency tree, the part hand-pinning never covered. Calls to reusable workflows are the exception: the lockfile does not pin jobs.<job_id>.uses, so a reusable workflow still needs a full commit SHA on the calling side, and its own uses: dependencies are covered by the lockfile of the repository where it is defined. GitHub changelog · GitHub Docs: workflow dependency lockfiles

Where it helps agent-driven CI

A CI job that runs a coding agent usually needs a model API key and often a token that can push or comment on the repository. The actions that wrap those agents are newer than the checkout and setup actions most teams have used for years, and fewer people have read their source. A moved tag in one of them would run with whatever permissions the job grants.

A lockfile turns that silent change into a diff. Any new commit for a dependency has to land as an edit to actions.lock, which goes through the same pull-request review as code. With the “Require lockfile” policy turned on at the organization level, a team can make that the rule rather than a convention that one repository forgets. The changelog did not say whether the policy blocks an unlocked run outright or only warns; GitHub’s docs now say it blocks, with details in the October 28 update below. GitHub changelog · GitHub Docs: enforcing lockfiles

What it doesn’t do

GitHub is explicit that locking a dependency says nothing about whether it is safe, and tells users to review dependencies before locking them. GitHub changelog If a compromised commit is already in place when you generate the lockfile, you have pinned the compromise. The same goes for a Dependabot update: the lockfile entry regenerates in the same pull request, which makes the change reviewable, and a reviewer who approves version bumps on sight gets no protection from it.

There is also friction. Per-workflow onboarding means a repository with many workflows is partly locked until someone finishes the job, and the stale-lockfile check will fail builds whenever a workflow edit adds a dependency without updating the file. That is the point, but it lands on whoever edits workflows, including agents that open pull requests against them.

Several things were not stated on the launch page: a general-availability date, availability on GitHub Enterprise Server, the lockfile’s internal format, and how the policy treats a dependency that is already SHA-pinned in YAML. The October 28 update below answers all four. GitHub changelog

What to test this week

1. Onboard one workflow that uses a composite action, and read the generated actions.lock to see how many transitive entries appear that your YAML never mentioned. A reusable-workflow call will not appear; it still needs a full commit SHA on its uses: line.
2. Add gh actions-lock --verify to CI, or copy the extension repository’s verify-lockfile.yml, then open a pull request that adds an action without updating the lockfile and confirm it fails. Check which extension version the job pins: on October 28 the sample pinned v0.2.0 while v0.4.0 was the latest release.
3. Turn on “Require lockfile” in a sandbox repository. On Enterprise Cloud, start in Evaluate mode and read Policy insights before switching to Active. Free and Team have no Evaluate mode, so scope the policy to one onboarded workflow first. Record the message a blocked run shows; the docs do not print it.
4. Let Dependabot open an action update on the onboarded workflow and check that the lockfile diff is legible enough for a reviewer to judge.
5. If agents edit workflow files in your repositories, check whether they can regenerate the lockfile, and decide whether they should be allowed to. The extension also installs as an agent skill with gh skill install github/gh-actions-lock. gh-actions-lock README

Feedback goes to GitHub’s community discussion or the gh-actions-lock issue tracker; the GA post links both. GitHub changelog, GA · Community discussion · Extension issues

October 28 update: lockfiles are GA, and reusable workflows are not pinned

GitHub declared workflow lockfiles generally available on October 28, two weeks after the preview, on the same four plans. The GA post lists the preview’s capabilities and nothing beyond them: the gh actions-lock extension, per-workflow onboarding, a stale check that modifies no files, the Require lockfile policy for enterprise, organization and repository administrators, and Dependabot regenerating the matching entry in the same pull request. It repeats the warning that locking a dependency does not establish that it is safe. The GA entry was one of GitHub’s Universe announcements; our Universe coverage deals with Copilot Fusion and metered Copilot billing. GitHub changelog, GA

Correction. When published, this article said the lockfile pins reusable workflows. GitHub’s docs say it does not pin calls at jobs.<job_id>.uses; those need a full commit SHA. A reusable workflow’s own dependencies are covered by the lockfile of the repository that defines it, not by the caller’s lockfile; the docs exclude dependencies of reusable workflow calls from a lockfile’s coverage and do not separately address same-repository calls. The lede, scope row and test 1 are corrected. GitHub Docs: workflow dependency lockfiles · GitHub Docs: control workflow execution

The docs now describe the policy. In Active mode, Require lockfile blocks runs of targeted workflows that are not onboarded to the repository’s lockfile, including workflows with no uses: dependencies, and blocks a caller whose reusable workflow is not onboarded in its own repository. Evaluate mode, which only reports would-be blocks under Policy insights, is Enterprise Cloud only. The policy lives under Settings, Actions, Policies for a repository or organization, and the enterprise Policies tab. The separate SHA-pinning policy is a different setting; for lockfile-covered dependencies, GitHub evaluates it against the locked commit SHA. Neither page prints a blocked run’s error. GitHub Docs: enforcing lockfiles · GitHub Docs: control workflow execution

The other open points are answered. The README says github.com and Enterprise Cloud with data residency are supported and GitHub Enterprise Server is not. The format is documented: each dependency records ref, commit, owner_id and repo_id, the commit must stay reachable from that ref upstream, and the file is never hand-edited. gh-actions-lock README · GitHub Docs: workflow dependency lockfiles

gh actions-lock --verify writes nothing and needs network access; the runner checks provenance again at job start. The sample verify-lockfile.yml pins the extension to v0.2.0; v0.3.0 and v0.4.0 shipped on October 22 and 23, and the v0.3.0 notes say some lockfiles that passed on v0.2.0 now fail, and that local ./ actions that use remote actions block runs by default. Pin a version on purpose. Which plans get Active mode is still unconfirmed: both docs how-to pages carry a “GitHub Enterprise Cloud” label while the changelog lists Free and Team. gh-actions-lock README · verify-lockfile.yml · Extension releases

Related: Anthropic keys now blocked on push

A day earlier, on October 13, GitHub added secret scanning detectors for Anthropic API keys, anthropic_service_api_key and anthropic_user_api_key, and put both in push protection by default. Commits containing either are blocked in repositories with secret scanning enabled, free public repositories included. The same update added a cloudsmith_api_key detector and brought Salesforce in as a secret scanning partner for salesforce_marketing_cloud_api_oauth2_token, so tokens found in public repositories go to Salesforce to revoke or rotate. The changelog does not say whether the Cloudsmith or Salesforce types are push-protected by default. GitHub changelog

Teams building with Claude should expect blocked pushes wherever a key sits in a config file, test fixture or example script. The fix is to move the key into Actions secrets or an environment variable and rotate any key that has already been committed. Neither change replaces review. The source map that shipped inside an npm package in the Claude Code source leak would not have been caught by a lockfile or a secret detector; someone had to notice what was in the release. Both features make specific mistakes louder: a moved dependency now shows up as a diff, and a committed Anthropic key now stops the push.

Sources

• GitHub Actions workflow lockfiles in public preview — GitHub changelog, October 14
• GitHub Actions workflow lockfiles are generally available — GitHub changelog, October 28
• Secret scanning blocks Anthropic keys by default, adds Salesforce — GitHub changelog, October 13
• Workflow dependency lockfiles — GitHub Docs
• Locking action dependencies in a repository’s workflows — GitHub Docs
• Enforcing lockfiles for action dependencies — GitHub Docs
• Governing execution of GitHub Actions workflows — GitHub Docs
• Secure use reference — GitHub Docs
• gh-actions-lock repository and README — github/gh-actions-lock
• verify-lockfile.yml — github/gh-actions-lock
• Releases — github/gh-actions-lock
• Issues — github/gh-actions-lock
• Workflow lockfiles community discussion — GitHub Community