Security Recommendations For Github Actions

I recently moved our continuous integration (CI) tests from Travis-CI to Github Actions for Brave’s Publisher application. When working on the migration I found there was a lot of 3rd party actions that you can integrate into your workflows. However that raises the question: Are they secure?

I begin to think about this a little more and with the help of some of my coworkers came up with the following notes.

Reduce use of 3rd-party actions#

This is the same concept as with dependency management. Most of what can be done in Github Actions can be done simply by using the normal actions workflow and bash. Take this step for example, we don’t have to use a 3rd party bundle install action, instead we can run the commands to execute “Bundle Install”

- name: Bundle install
  run: |
    bundle config path vendor/bundle
    bundle install --jobs 4 --retry 3

Always use commit hashes for the Github Actions#

Action versions can be unsafe, as the maintainer or attacker can later revise the version.

Do not use hosted runners for public repos#

This one might be a little of a stretch, but unless you can guarantee the runner is ephemeral and virtualised then code secrets could be leaked to other processes. For extra-security you can host your own Github Runner. However be careful, someone may be able to submit a pull request against the project and someone could abuse that functionality.

Don’t use secrets that could compromise your application#

Keep production values out of your Github account, and try to use dummy values if you need to insert secrets into the code. This might not always work for every codebase so consider regularly rotating secrets throughout the year to prevent leakage.

For iOS, use fastlane match for credentials storage#

This advice was presented by a coworker of mine. His advice was to use Fastline for cerdentials storage because the repo will be completely encrypted with a password known only to the builder (a secret).

Consider integrating tooling#

Adding tooling around your code and secrets greatly reduces your risk for expore. Amazon’s Git Secrets hook or Mozilla’s Secrets OPerationS (SOPS) are great options to integrate.