Lock GitHub Actions dependencies to SHAs for security and predictability

[larouxn]

Description

Lock GitHub Actions dependencies to specific version SHAs for security and predictability. Doing so is a best practice as we then know exactly which version of a given dependency is being used. Without locking to SHAs, Actions will simply use whatever latest version is available for the given specified version, usually a major such as "v4", leading to "silent bumps" at the GitHub Action runtime level.

Locking to SHAs will also allow us to receive patch and minor level dependency upgrade PRs as opposed to, in most cases, just bumps for major versions.

How has this been tested?

CI and Danger runs will prove if these changes are proper or not as they only affect GitHub Actions.

For reference here are the GitHub Actions dependencies releases so we can check the SHAs.

• https://github.com/actions/checkout/releases/tag/v5.0.0 (actions/checkout@08c6903)
• https://github.com/ruby/setup-ruby/releases/tag/v1.255.0 (ruby/setup-ruby@829114f)
• https://github.com/actions/setup-node/releases/tag/v4.4.0 (actions/setup-node@49933ea)
• https://github.com/actions/upload-artifact/releases/tag/v4.6.2 (actions/upload-artifact@ea165f8)
• https://github.com/coverallsapp/github-action/releases/tag/v2.3.6 (coverallsapp/github-action@648a8eb)

[tomhughes]

So basically the end result is more work for us to merge PRs for minor version changes?

[Firefishy]

So basically the end result is more work for us to merge PRs for minor version changes?

I think dependabot is able to handle the pinned versions without issue. It also supports updating the version comments.

Update: Ah yeah, minor version upgrades would likely be some extra work. Maybe we could tune dependabot to only update weekly or monthly if the updates were too frequent.

[tomhughes]

I don't know how often these things change - you'd think they'd be fairly stable but the version numbers suggest otherwise ;-)

What I do know is that there's little you can do to evaluate a pull request other than shrug your shoulders and click merge.

[larouxn]

So basically the end result is more work for us to merge PRs for minor version changes?

For sure it will result in more PRs but I don't think it would be a ton. Can certainly tune the Dependabot config if it turns out to be a large burden. For reference regarding update frequency per action:

• actions/checkout just had its first two releases (v4.3.0 and v5.0.0) since Oct 2024 (+9 months) last week (releases)
• ruby/setup-ruby has had quite a few updates in the last couple months though mostly we can expect bumps every 2 months re: new Ruby versions being released (Ruby release schedule noted, releases)
• actions/setup-node hasn't had an update since April and before April not since March, then January, then last October (releases)
• actions/upload-artifact has only had 3 updates this year (releases)
• coverallsapp/github-action hasn't had any updates since January and before that last October (releases)

Overall I think most won't result it much in terms of bumps other than ruby/setup-ruby which could prove a bit burdensome. We could remove the SHA lock for that since it's typically one of the safer actions to silent bump anyway since it usually just adds support for new Rubies.

[tomhughes]

I see the PR that @Firefishy pointed at says GitHub recommend this... Does anybody have a pointer to that?

I'm sure we probably should do it but the ugliness makes me sad 😞

[larouxn]

To be clear, SHA pinning GitHub Actions dependencies is considered a best practice because someone could:

1. Release a bugged/infected/malicious version which without pinning runs would automatically use. Example: actions/upload-artifact is locked to v4 now so while the latest is v4.6.2, someone could release a v4.6.3, v4.7.0, v4.x.x and runs would automatically use that next time they run. A vulnerability.
2. More concerning to me, even pinning to an exact semantic version is vulnerable to the moving of an existing tagged release to a new commit. Example: We could pin actions/upload-artifact to v4.6.2, no SHA. Then someone could pull down the pushed v4.6.2 tag and re-tag a different commit with v4.6.2 and push that up and the next runs would automatically use that instead. A vulnerability.

ℹ️ I'll admit that given this repo is only using official GitHub, Ruby, and Coveralls GitHub Actions dependencies the risk of the above happening is rather low compared to if we were using an action from an arbitrary GitHub account but the risk still exists.

[pnorman]

But we don't release anything through GH actions, do we? A malicious party could break our CI but they can do that by taking down their actions.

I'm not sure what we're trying to protect against. I know supply chain attacks are real, but what's the impact beyond CI?

[tomhughes]

I understand the logic of pinning, but when dependabot opens a PR to update the pin to a new version how am I supposed to evaluate if that is a genuine version or a bugged/infected/malicious version?

Without that it just becomes me manually doing what happens automatically now...

[larouxn]

Like I said, it's highly unlikely anything actually malicious will occur since 1. all the actions in use are official ones and 2. the actions are only used for CI and PR utility. The inspiration behind this is that it's a best practice for security and predictability.

how am I supposed to evaluate if that is a genuine version or a bugged/infected/malicious version?

When a Dependabot PR appears one can read the README and if desired can click in and see the diff between the previous tag/commit and new tag/commit. This change at least allows us a chance to actually see what's changing in the GitHub Actions dependencies we use. Without it the underlying dependencies are just changing (excluding major version bumps) whenever a new version is released without any review.

[tomhughes]

OK let's give it a go and see how we get on...