Conversation
|
(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. |
|
@mikeshardmind Thanks for that comment! I checked, and that’s indeed the case for 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 |
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:
actions/upload-artifact, for which I had to update the artifact names to ensure they were unique (since artifacts are immutable sincev4) (https://github.com/actions/upload-artifact/blob/main/docs/MIGRATION.md)actions/github-script, in the JS script that was launched, wheregithub.issues.updatewas used, which has been replaced bygithub.rest.issues.update(https://github.com/actions/github-script#v5)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