A GitHub Action tag can move: review the executable revision
Understand tags versus immutable commit references, verify the resolved action and keep pinned dependencies maintainable.
In brief
A tag is a reference that can be moved to different code. Google’s pipeline hardening report highlights mutable action tags as a supply-chain concern; a familiar version label is not an immutable code identity.
Pinning to a reviewed full commit reference can make the selected revision explicit, while updates still need a controlled review process.
Verify what will execute
Read the action’s actual repository and resolved revision. Confirm that the intended tag/release corresponds to the reviewed code rather than copying a commit from an unrelated comment. Do not publish an invented commit hash as a usable configuration example.
Inspect authority and dependencies
Review workflow token permissions, secrets and the action’s network or download behaviour. A pinned action can still fetch changing code if implemented that way. Keep release jobs separate from untrusted inputs and use the minimum authority needed.
Keep changes manageable
Use update proposals and inspect meaningful release differences. Run relevant checks before accepting a new revision and keep its reason recorded. If a tag was redirected maliciously, review affected workflow runs and exposed credentials; replacing the tag does not undo prior execution.
Before you act
An immutable reference does not prove the code is safe or that every downloaded dependency is pinned. Freezing a vulnerable revision indefinitely is not secure maintenance.
What to do next
- Inventory third-party actions and how their revisions are selected.
- Review the intended release and use a verified immutable reference where appropriate.
- Maintain updates through a reviewable process, inspecting the action and its downstream execution.
