Date posted: 06 Feb 2021, 1 minutes to read

GitHub Actions & Security: Best practices

I’ve been diving into the security aspects of using GitHub Actions and wanted to share some best practices in one place.

Image of locks on a fence

Photo by Jon Moore on Unsplash

Forking action repositories

In the post on Forking action repositories I show these best practices:

  • Verify the code the Action is executing
  • Pinning versions
  • Forking repositories
  • Keeping your forks up to date

Secure your private runners

In the post on Private runners I explain these best practices:

  • Limit the access of your private runner
  • Do not use a runner for more than one repository
  • Never use a private runner for you public repositories

Do not reuse a runner, ever!

Untrusted input

An overview from GitHub on untrusted input, from the issue title to the commit message, if you act upon them (even just echoing them to the output!), they can be misused and therefor are an attack vector.

Preventing pwn requests

It used to be the case that you would trigger your workflow by using the pull_request in the trigger definition. That scope had to much rights, so GitHub has dialed that down. The scope with more rights (to your access token with some write permissions for example) has now been created to be pull_request_target. You need to be really careful with using that scope. Best practice here is to use a label for the pull request so you can manually check the PR and authorize its actual execution.

You need to be very careful with incoming Pull Requests from any fork: potentially they are changing scripts/commands in your workflow or even the workflow itself. There have been examples where a PR was send in that updated the workflow and made good use of the 10 concurrent jobs available for open source projects to generate some bitcoin for the attacker. This is why we can’t have nice things 😲!