Proposal to pin GitHub Action Runners to commits instead of versions

Development
1

Last week a GitHub action was compromised, malicious code injected and the version updated: Harden-Runner detection: tj-actions/changed-files action is compromised - StepSecurity

It printed secrets in the build logs, which were then visible publicly.

Luckily we did not use that action, but it raised awareness on how they work: The version is just a tag in the actions repository, which can be moved to a different commit, making it an attack vector.

I wanted to bring up this topic and ask if we feel threatened enough by this to pin our GitHub actions to commits instead of tags, making such supply chain attacks way harder / not updating our action to the hijacked version. The donwside is worse readability, manual effort when update those actions.

Currently we use the following actions:

    actions/cache/restore@v4
    actions/cache@v3
    fastify/workflows/.github/workflows/plugins-ci-package-manager.yml@v4.1.0
    fastify/workflows/.github/workflows/plugins-ci.yml@v4.2.0
    github/codeql-action/analyze@v1
    github/codeql-action/autobuild@v1
    github/codeql-action/init@v1
    ljharb/rebase@master
    ljharb/require-allow-edits@main
    stefanzweifel/git-auto-commit-action@v5
    actions/cache/save@v4
    actions/cache@v2
    actions/setup-java@v3
    jreleaser/release-action@v2
    actions/checkout@v1
    actions/setup-java@v4
    ljharb/actions/node/matrix@main
    actions/setup-node@v2
    mikepenz/action-junit-report@v4
    coverallsapp/github-action@master
    actions/cache@v4
    actions/setup-node@v3
    actions/upload-artifact@v4
    ljharb/actions/node/run@main
    mvasigh/dispatch-action@main
   actions/checkout@v3
   actions/checkout@v4
   actions/setup-node@v1
   actions/checkout@v2

I don’t want to raise the question if we trust the authors of these plugins enough to expose all of our build secrets to them (at least not in this thread), but concentrate on the question above.

What do you think?

2

Inspiration and script to list our actions from this blog post: Whose code am I running in GitHub Actions? – alexwlchan

3

Interesting question. Referring to a commit makes it really hard to tell which version is in use. At least I would leave a comment then which version tag is represented by the commit.

I would like to avoid this as much as possible, tend to trust all the above mentioned actions. Maybe we could say that at least the actions provided by GitHub are considered safe (all starting with actions/). Others are subject for discussion.

Actually, also a pinned commout does not grant safety, too. Do we really check that these actions are uncompromised? Actually not.

4

Thanks for your reply.

I agree in assuming that the official GitHub Actions should be considered safe. Also, most of the actions we used are used by a ton of projects and I would not assume that the creators will add something malicious itself (even if they could). As you said, we don’t check if the actions are uncompromised, we don’t check our other dependencies, too.

What concerns me a little is the ease and swiftness of a possible attack after account takeover. To single out an action (not that I mistrust it!), mabye GitHub - stefanzweifel/git-auto-commit-action: Automatically commit and push changed files back to GitHub with this GitHub Action for the 80% use case. is a good example.

The repository is owned by a single person and used by 150k repositories. If an attacker compromised the persons account (we don’t even know if they use 2FA or their password ist “password!”), it would take one commit and moving one single tag to inject anything you want via supply chain attack into those 150k repositories.

Incentives for these attacks are high, the payoff is potentially high, and if the malicious commit is prepared, it takes ~10 seconds to publish it and change the version tag. Usually, systems for distributing software and dependencies have a lot more safeguards in place for a reason

5

This action would be an example where I think that it is worth to change it to to a commit and documenting the actual tag. Same for the action-junit-report, and maybe others, too.

And it makes me aware that we should introduce a review process to revise used or new actions. Can we maybe agree on the following

  • actions owned by github are considered safe
  • seperate actions can be considered safe after proper discussion (e.g. I would consider jreleaser as safe)
  • actions from personal github accounts are considered unsafe
  • @main is disallowed
6

That sounds like a good middle ground, I’d be happy with such an approach

7

I have started with the Operaton main repo and changed according to these rules. Where would be a central place to document such guidelines?

2 Likes
8

We could add a BUILD.md (similar to the TESTING.md), or add a README.md to the root of the .github folder.

The first alternative would suit the approach so far, the second one would prominently render in the GitHuib webview when one visits the folder.

wdyt?

9

I tend to alternative 2. Just because in this README GitHub workflow specific stuff could be documented.

1 Like
10

I would like that approach, too

2 Likes