58% of top repos' Actions float on a tag. I counted

GitHub made workflow lockfiles generally available on October 28. Two weeks later, 0 of the 22 most-starred repos that actually run GitHub Actions use one — and 58% of their action references float on a mutable major tag like @v4. I audited all 30 of the most-starred repos on GitHub to check.

The problem lockfiles solve

GitHub Actions are fetched from Git. When a workflow says uses: actions/checkout@v4, that v4 is a tag, and tags move. Whoever controls the tag controls what code your CI runs — a previously safe tag can be re-pointed at malicious code, and your workflow will pull it without any change on your side. The old advice was to pin the full 40-character commit SHA instead, with the tag in a comment for humans. The new answer, as of October 14 in public preview and October 28 as GA, is a lockfile: .github/workflows/actions.lock, generated by the gh actions-lock CLI extension, records the exact commit behind every action a workflow uses, including transitive dependencies, while the workflow itself keeps readable vX.Y.Z tags. Dependabot and Renovate already update lockfiles, zizmor 1.32.0 understands them, and there is a Require lockfile policy for orgs that want to mandate them.

GitHub is careful about the limit, and so should you be: a lockfile guarantees your workflow runs the commit you locked, not that the commit is safe. It locks what you reviewed. It does not review it.

The audit

Method: GitHub's search API, repos with over 100,000 stars created before 2024, top 30 by stars. For each, I listed .github/workflows and fetched every workflow file through the Contents API, then classified each uses: reference as a full SHA, a semver tag (vX.Y.Z), a major tag (vX), or a branch/unpinned ref. Local actions and Docker actions excluded. Eight of the 30 have no workflows directory at all (mostly awesome-lists and books); the other 22 have 379 action references between them.

reference type          count    share
SHA-pinned (40-hex)       154    40.6%
semver tag (vX.Y.Z)         1     0.3%
major tag (vX)            220    58.0%
branch / unpinned           4     1.1%
total                     379   100%

The headline is the middle row. Nearly three in five action references in the most-starred repositories on GitHub resolve through a tag that can move. Only one reference in the whole sample uses a full semver tag — the ecosystem's real convention is @v4, not @v4.2.1, which means the readable version in the workflow file is doing almost no pinning work at all.

Per-repo, the spread is wide:

repo                              sha   semver   major   branch
n8n-io/n8n                         83        0       0        0
yt-dlp/yt-dlp                      23        0       0        0
Significant-Gravitas/AutoGPT       22        0       4        0
freeCodeCamp/freeCodeCamp          13        0       0        0
react/react                         2        1      97        3
ollama/ollama                       0        0      82        0
TheAlgorithms/Python                0        0      24        0

n8n is the model citizen here: 83 SHA pins across 110 workflow files, zero tags. yt-dlp and AutoGPT are mostly pinned too. At the other end, React pins 2 of 103 references — the rest float on major tags — and Ollama pins none of its 82. Seven of the 22 repos with workflows have zero SHA pins at all. Ten have at least one.

And the lockfile count, the reason I ran this: 0 of 22. Two weeks after general availability, not one of the most-starred repos on GitHub has an actions.lock file. (Caveat in fairness: fourteen days is early for a new file format, and the repos in this sample are old and large — the early adopters are more likely to be smaller repos that never make a most-starred list. But "the biggest repos haven't moved" is still the correct read of this sample.)

What the numbers don't say

A major tag from actions/checkout is not the same risk as a major tag from a random third-party action. The tag-mover threat needs control of the upstream repo, and the actions/* org is a harder target than a one-maintainer action. So 58% floating is not 58% compromised — it is 58% of references where a compromise upstream would flow straight into CI with no local change to catch it.

The lockfile has edges too. GitHub's own docs exclude reusable-workflow calls from what a lockfile pins — jobs.<job_id>.uses needs a full SHA on the call itself — and container images are out of scope. A hand-edited lockfile entry pointing at a commit that exists only in a fork was reported to pass verification in October (still open as of October 19, per the extension's issue tracker). None of that makes the lockfile useless; it makes it a lock, not a review.

The one-command version

If you maintain a repo with Actions, the fix the audit says nobody at the top has done yet is:

$ gh extension install github/gh-actions-lock
$ gh actions-lock

It rewrites your workflows to readable tags and writes the lockfile. Add the verify job to CI so a stale lockfile fails the build. That is the whole migration, and the audit above is the measure of how far the ecosystem still has to go: 379 references, 220 floating, 0 lockfiles.

Sources: Hugo van Kemenade, "Lock your GitHub Actions," hugovk.dev, November 11, 2026; GitHub Changelog, workflow lockfiles public preview October 14, 2026 and generally available October 28, 2026; GitHub Docs, "Workflow dependency lockfiles"; the audit is my own run against the GitHub API on November 11, 2026 — top 30 repos by stars (stars > 100,000, created before 2024), 22 with workflow directories, 379 uses: references classified. Raw per-repo counts are in the article.