Why You Should Not Use The Version Tag Or Branch Name When Using GitHub Actions
The Secure Way to use GitHub Actions
4 min read
Malicious code can be inserted into any GitHub action, even those which are tagged.
With these words, Julien Renaux's article titled "Use GitHub actions at your own risk" begins.
Before reading this article from late 2019, I gave little thought to the potential risks from using GitHub Actions (e.g. one that adds your latest blog posts and YouTube videos to your GitHub profile). I mean doesn't that sound familiar? You search for a certain GitHub action, find the right tutorial, set up the
yml file, and stare at the result. How many times have you looked at the source code of the action to see what happens to your data and secrets?
Have you never wondered if your secrets are used elsewhere? There have been similar scandals with npm packages in the past. It happens again and again that potential malware is infiltrated and no longer does what it promises. This makes it all the more important to pay attention to the security of your data, even with GitHub Actions. How can you do that?
The Problem - Maintainers can update tags and branches anytime
First, let's look at the problem. Tags and releases on GitHub can be deleted and recreated at any time. If you install the innocuous code for v1.2.3 today, the same version number may be infected tomorrow. Julien has drawn attention to this problem in his article. He has also created an example repository for it. Okay, now we know the problem. How do we fix it?
The Solution - Use commit hash instead of release tags
Before that, I would like to say something about the following solution. Even if you do this in the future, you need to be aware that it might already contain malicious software. Install GitHub Actions only from trusted developers or look at the source code carefully beforehand.
Okay, so what's the solution?
Instead of using the release tag, or as other GitHub Actions suggest the
main branch, use the commit hash (SHA-1) in the GitHub Action configuration. It is unique and cannot be changed afterward.
Here is an example:
name: Blog Posts on: schedule: # Runs every hour - cron: '0 * * * *' jobs: update-readme-with-blog: name: Update this repo's README with latest blog posts runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 # instead of: # - uses: gautamkrishnar/blog-post-workflow@master - uses: gautamkrishnar/blog-post-workflow@94531d3fc177a2753683dc4342c10aa4420fc4f1 with: feed_list: "https://blog.natterstefan.me/rss.xml"
Instead of pulling the code from
@master I tell GitHub to pull and use
This ensures that you do not install and use a newer version without your knowledge. You have to make a conscious decision to update and you can look at the code beforehand at your leisure. This way you and your data are on the safe side.
Do you like this article? Do you want to support me? Tell your friends on Twitter about it. Thank you!
Questions and Feedback
You got any questions or want to add your thoughts? Let me know in the comments below, please.