Skip to content

ci: pin actions versions with hashes - #10460

Open
mdevolde wants to merge 1 commit into
Rapptz:masterfrom
mdevolde:ci/pin-actions-versions
Open

mdevolde wants to merge 1 commit into
Rapptz:masterfrom
mdevolde:ci/pin-actions-versions

Conversation

@mdevolde

@mdevolde mdevolde commented Jun 7, 2026

Copy link
Copy Markdown

Summary

I have pinned the versions of the actions used in the workflows with hashes.

Pinning GitHub Actions to a commit hash is an effective safeguard against supply chain attacks. By referencing a specific and immutable version of an action, you prevent compromised versions from being automatically integrated into your pipelines.

I checked the breaking changes for all actions that had been upgraded, and made the necessary changes.
There were two breaking changes that affected us:

Here is the link to the tags for the actions I've pinned, if you want to check the hashes:

Pinning versions requires a bit of maintenance, since you have to perform manual upgrades regularly, but in your case, with workflows that handle secrets (such as secrets.GITHUB_TOKEN), it’s a best practice to avoid troubles.

Checklist

  • If code changes were made then they have been tested.
    • I have updated the documentation to reflect the changes.
  • This PR fixes an issue.
  • This PR adds something new (e.g. new method or parameters).
  • This PR is a breaking change (e.g. methods or parameters removed/renamed)
  • This PR is not a code change (e.g. documentation, README, ...)

@mikeshardmind

Copy link
Copy Markdown
Contributor

(Not to suggest this isn't worth doing, seems like a positive change to me)

The latest versions (not the versions currently in use) of some of these actions are actually immutable release tags.

upgrading setup-python to 7.0 and setup-node to 7.0 would achieve the same level of trust (if an attacker can subvert GitHub's immutable releases, they can do much worse)

Would be great if all actions were published using this feature, as it's sufficient to trust a versioned tag and use it in that case.

@mdevolde

Copy link
Copy Markdown
Author

@mikeshardmind Thanks for that comment! I checked, and that’s indeed the case for setup-python and setup-node: their latest releases are marked as immutable by GitHub, which in practice offers the same level of assurance as hash pinning.

However, hash pinning seems better to me for now, just to have a uniform common method across all actions in the workflow. Some third-party actions we use haven’t necessarily adopted this immutable release mechanism, and rather than checking on a case-by-case basis which ones support it, it seems simpler and safer to me to use a single consistent method for all of them.

Finally, beyond the hash vs. immutable release debate, the primary goal of this PR is also to lock down the version of the actions themselves. Currently, references such as actions/checkout@v3 point to a floating major tag, which can be moved to new minor or patch versions without us realizing it.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants