5.1.2. Immutable Actions and Version Pinning
💡 First Principle: Git tags are movable pointers, so @v3 has always been a promise rather than a guarantee — and every durable fix for that works the same way, by naming the bytes instead of the label, which is why a full commit SHA remains the answer no matter what the platform ships around it.
The model resolves uses: owner/repo@ref by fetching that Git ref at run time. Because a maintainer (or anyone who compromises their account) can force-push a tag to point somewhere new, @v3 can silently become different code — the mechanism behind the widely-reported March 2025 tj-actions/changed-files compromise, where a moved tag pushed credential-dumping code into thousands of workflows.
Immutable actions was GitHub's announced answer: publish each action release as an OCI package in GitHub Packages (ghcr.io) so a published version's contents could never change, while consumers kept writing uses: owner/action@v1.2.3 unaltered. It never shipped. GitHub removed both the public-preview and GA roadmap items in December 2025 as not planned, the publishing action was never released for public use, and the stated reason was a shift of effort toward immutable releases instead. Know the term and the intent — the objectives still name it — but do not expect to configure it.
What did ship is immutable releases, generally available since October 2025 and enabled per repository or organization. It protects releases rather than action resolution: once published, a release's assets cannot be added, modified, or deleted, its tag cannot be moved or deleted, and it receives a signed attestation you can verify. That hardens the artifacts an action's consumers download, and it makes a version tag meaningfully harder to repoint — but it is a publisher-side setting on the source repository, not a change to how uses: resolves.
So the exam angle — "implications for version pinning and registry sources" — resolves to three things. First, full-SHA pinning is the operative control, not a fallback: a 40-character commit SHA is unforgeable regardless of what any tag does, and it is the guidance the security objective states outright (6.1.4). Second, immutability is a publisher's choice and a consumer cannot assume it — which is exactly why the consumer-side defense has to be the SHA. Third, the classic moving major tag (v1 re-pointed at each patch) is convenient and explicitly mutable; it is defensible for first-party actions and not for untrusted third-party ones.
⚠️ Exam Trap: Immutability is a property of what was published, never of the syntax you type. Writing @v1.2.3 gives you no guarantee at all — the tag can still move. Don't confuse "looks precise" with "is pinned"; only a full SHA is pinned from the consumer's side.
Reflection Question: Immutable releases protect a release's assets and tag, yet SHA pinning is still the advice for consuming third-party actions. What does the SHA cover that the publisher's setting cannot?
