GitHub Actions Has a Package Manager, and It Might Be the Worst

via Andrew Nesbitt
December 23, 2025  •  Updated December 25, 2025

Related HN discussion

An interesting blog post by Andrew discussing the issues around GitHub Actions’ package management. I’ve had some doubts about the versioning model in GitHub Actions for a while, and this post affirms many of those concerns. The high numbers in the linked research are not surprising at all.

Mutable versions. When you pin to actions/checkout@v4, that tag can move. The maintainer can push a new commit and retag. Your workflow changes silently.

This in my opinion is the main issue, which gives a false sense of security. The v4 you ran last month might not be the same v4 you run today, and there’s no indication that anything has changed.

Invisible transitive dependencies. SHA pinning doesn’t solve this. Composite actions resolve their own dependencies, but you can’t see or control what they pull in. When you pin an action to a SHA, you only lock the outer file. If it internally pulls some-helper@v1 with a mutable tag, your workflow is still vulnerable

So there’s little point to SHA pinning if the action itself pulls in mutable dependencies. You might as well just pin to the tag.

Interestingly, immutable releases were made generally available only this October. As for immutable actions, the issues on the roadmap for public preview and GA have been closed as not planned only few days ago.

Why should CI/CD workflows be treated any less seriously than application dependencies?

Edit: There is a community built tool gh-actions-lockfile (CLI + GitHub Action) that allows you to generate and verify a lockfile for your GitHub Actions. It seems to be inspired by the Andrew’s post. Useful solution, but I still feel it is a workaround for a problem that should be solved by GitHub natively.

Reply via email