Protect against malicious usage of GitHub Actions

[Vadorequest]

I've been deceived by the GitHub Actions Marketplace today.

My understanding of what it actually does was wrong, I have been completely mistaken.

I thought the purpose of the Marketplace was to host our Actions, and act as a way of version-control, similar to what NPM does.

The actual purpose of the Marketplace is Find tools to improve your workflow.

That might seem obvious to people, but I was under the impression GitHub Actions Marketplace would somehow protect us against evil-intended action. The short answer is that it's not.

I ended up there by trying to understand how an Action could be unpublished.

Eventually, I figured a few things, thanks to:

• https://julienrenaux.fr/2019/12/20/github-actions-security-risk/
• https://github.community/t/version-numbering-for-actions/16307/5?u=vadorequest

What's critical for devs to understand:

• GitHub Actions Marketplace role is only to index existing Actions, so they're easier to find.
  • It doesn't host any source code
  • You don't have to use it, it's completely optional (you can use actions that aren't indexed in the Marketplace)
• The only source of truth for GitHub Actions is the repository where they're stored.
  • Actions are usually referenced in our source code using peter-evans/create-or-update-comment@v1, which can target either a tag or a branch.
  • Whether it targets a tag/branch, the code can be changed afterwards! Meaning, if you install this today and the author changes the implementation tomorrow and update the branch/tag, it might break your CI. Also, it's possible to do that to do many malicious/evil things (like storing your secrets on some external server).
  • Using a SHA instead of a tag/branch is safer, because it cannot be overwritten, even using git --force and rewriting the history.
    • But even though, the author might just decide to convert his repository from public to private, or delete it altogether. In such case, there is no way to recover from it unless you have an up-to-date fork you can use.

What's recommended for a max of security/reliability

• Never use @v1 for production-grade tools
• Even less use @latest - This is great for dev, not for production usage
• Use commit hash/SHA, to have confidence the code won't be changed without your prior knowledge/consent
  • E.g: Use peter-evans/create-or-update-comment@42d0000ec46183c565239510fdf1db5aca86fc8b instead of peter-evans/create-or-update-comment@v1
  • Specifying the version number (as a comment) would be a recommended good practice for readability
• Forking the repository and using a SHA is probably the safest way to go, and will effectively protect you against unforeseen changes in the actions you rely on
  • It won't protect you if you blindly update your fork and change the version you use without reading what's changed in the code, though. But that's true for any dependency upgrade, so it's not different from what you should do with NPM packages anyway.

Follow-up action plan:

Based on those findings, here's what I intend to do:
#224

---

Were you aware of that?
How come so few people care about it, considering how bad it went with NPM a few years ago with similar stories about published packages?

Feel free to share your thoughts.

[samuelcastro]

I've also never considered this and I totally agree, we need a better strategy. I'm also going to take the same approach for my other projects. This is a huge thing, thanks for bringing that up.

[Vadorequest]

Yeah, this came out so unexpectedly, I'm still not sure about what to do for our company.

• The most obvious first step is to replace refs (branches/tags) using SHA instead.
• Then, automating this would be better to avoid human mistake and improve DX.
• Much more complicated/advanced would be to clone all actions we rely on and keep them up-to-date automatically somehow while not allowing erasing of tags to avoid bad surprises, but this is not trivial to set up and maintain, it's a real burden.

At this time I still haven't done much about that, kinda working on it as a background task when I have time.

[boldandbusted]

Thank you for this excellent post, @Vadorequest. Cheers.