Best Practices in GitHub Actions Security: A Case Study with Google’s Use of StepSecurity

If you’ve used GitHub Actions to automate your build, test, and deployment pipeline, you know how important it is to secure them. In this series of blog posts, we’ll dive into the intricacies of GitHub Actions security to help you understand the best practices with the help of real-world examples and use cases. In this blog, we’ll take a closer look at how Google’s open-source projects have secured their GitHub Actions workflows with StepSecurity.  

Introduction

GitHub Actions is a CI/CD platform that has revolutionized the software development landscape. The platform allows developers to automate workflows, from code compilation to deployment, directly within their GitHub repositories. Broadly, there are three types of GitHub Actions- Docker container, JavaScript, and composite. Under each of these types, you will find thousands of GitHub Actions to execute in the marketplace which comes with an equally large quantity of untrusted code and security threats. To help you safeguard your projects from these threats, we’ll take the example of how Google secured its GitHub Actions workflows in this blog post.  

Also Read: GitHub Actions Security Best Practices (With Checklist)

GitHub Actions Security

So why is it important to secure GitHub Actions? Since GitHub Actions have access to source code, build artifacts and cloud deployments, you need to secure it to protect your code and infrastructure. Some examples of how GitHub Actions can pose a threat are by stealing your organization's GitHub secrets, compromising your cloud infrastructure, or even tampering with your code. This can lead to severe supply chain attacks and disruption of organizational operations.  

CISA and NSA's Joint Guidance on CI/CD Security

The importance of CI/CD security has also been quite evident from the joint guidance released by CISA and NSA in June 2023. The guidance issued by the Cybersecurity & Infrastructure Security Agency and National Security Agency stated: “CI/CD environments are attractive targets for malicious cyber actors (MCAs) whose goals are to compromise information by introducing malicious code into CI/CD applications, gaining access to intellectual property/trade secrets through code theft, or causing a denial of service effects against applications”. Moreover, the increasing CI/CD attacks in the past year like the SolarWinds and Codecov breach, and many more have proven that there is a major need in the industry to adopt CI/CD best security practices.

Google's Open Source Projects on GitHub

Over the years, Google has created various open-source projects on GitHub to make significant contributions to the developer community. These open-source projects cover a wide range of domains, from machine learning frameworks to cloud computing tools. Google's open-source initiatives have not only empowered developers but have also demonstrated their commitment to fostering innovation and knowledge-sharing. In this blog, we’ll see many of their open-source projects as GitHub Actions security use cases.  

GitHub Actions Security Automation with StepSecurity

Projects using GitHub Actions can have multiple security threats. To secure these projects, you’ll need to abide by various best practices recommended by GitHub in their GitHub Actions Security Guide. This is where StepSecurity can help you out. With StepSecurity’s automation platform, you can automate GitHub Actions security for your projects- be it in public or private repositories. StepSecurity’s automation platform not only implements the fixes but also creates a pull request automatically with the recommended fixes.  

Here are some of the pull requests created by StepSecurity’s automation platform for Google’s open-source projects.

GitHub Actions Security Best Practices Adhered by Google

Here are 5 best practices adhered to by Google with the help of StepSecurity.  

1.  Limit GitHub Token Permissions

The GITHUB_TOKEN is a unique credential through which GitHub Actions workflows can access the GitHub API. This token is valid from the beginning to the end of the GitHub Actions workflow and gives access to different parts of the GitHub API. Note that permissions required to access different parts of the GitHub API are extensively documented. Based on the needs of each GitHub Actions job, you can adjust these permissions from its default settings.  

Why is it needed?

If the GITHUB_TOKEN has write access to the repository, and the token is compromised, it can result in someone pushing malicious code in the project. Therefore, it is important you only allow limited permissions to the GITHUB_TOKEN.  

How to limit token permissions?

You can set specific GITHUB_TOKEN permissions in a workflow file using the “permissions” attribute. When this attribute is set, the GITHUB_TOKEN is not assigned all the permissions, but only those listed in the workflow file.  

However, deciding what permissions to set for each workflow is hard. You need to know the different types of permissions and the minimum permissions that the workflow requires. If you assign fewer permissions than needed, the workflow can fail.  

An automated solution that helps decide the right set of permissions and can also add the appropriate permissions attribute in the workflow, can therefore save a lot of time and effort. StepSecurity has implemented such a solution, that creates a pull request with the required changes to set the minimum token permissions across all the workflow files.  

In the example below a developer from Google has used this feature in their project, which is one of the most popular open source projects in the Google Cloud Platform organization. Take a look at this pull request that was created automatically using StepSecurity: https://github.com/GoogleCloudPlatform/functions-framework-nodejs/pull/515.  

Note how the “permissions” attribute has been added with the right set of permissions needed for this workflow.

2. Hardening Runners

You must have heard about the Codecov breach and the SolarWinds supply chain attack. Do you know what both these attacks had in common? The breach happened because the runners, which are the build servers, or CI/CD servers, were never hardened. In the case of the Codecov breach, the exfiltration of CI/CD credentials could have been avoided by blocking egress traffic at network layers. And as for SolarWinds, the incident could have been avoided by detecting tampering with source code during the build.  

One easy way to prevent such CI/CD attacks is to use the StepSecurity Harden-Runner GitHub Action like Google did in this project: https://github.com/google/automotive-design-compose/pull/454  

What does Harden-Runner do?

When you integrate Harden-Runner, here’s what gets automated:  

• Monitoring of egress traffic from each job at DNS and network layers  
• Filtering of egress traffic to allowed endpoints  
• Detecting source code tampering that may occur during the build process  
• Running jobs without sudo access  
• Security alerts for when outbound traffic is blocked or source code is overwritten  

How to use Harden-Runner

To block calls to unauthorized endpoints, you need to first know what calls are currently being made. To do so, you can run Harden-Runner in audit mode. When you do that, you can see all the outbound calls being made on the runtime security insights page. As an example, here is the insights page for the above workflow.  

Once you know the expected outbound calls, you can then take the recommended policy from the insights page and update your workflow. All future runs of the workflow will be secure and any unauthorized calls to outbound endpoints will be blocked.  

As an example, the screenshot below is from another Google project where the developer has set a block policy.  

Harden-Runner works not only for GitHub-hosted runners but also self-hosted VM runners and Actions Runner Controller-based Kubernetes runners. So even if you use self-hosted runners in your organization, security hardening of your workflows can be done using Harden-Runner.  

3. Pinning Actions to Full-Length Commit SHA  

The GitHub Actions Marketplace has over 10,000 GitHub Actions that can be used in workflows. These third-party Actions provide different functionality from linting, building, and testing code, to deploying code to different environments. When developers use an Action in their workflow, they refer to it by the Action’s repository name and can use a particular version using a tag.  

But as new versions of these Actions become available, that new version is typically published on the existing tag. As an example, the screenshot below shows the “actions/checkout” Action’s v3 tag being used. As bug fixes or new features are published for this Action, the v3 tag is updated to point to the latest changes. So, the tags are mutable.  

This creates a reliability and security problem. If one of the third-party Actions gets compromised and a new version gets released, your workflow will immediately start using it, without getting a chance to review the changes. To avoid this, you must ensure that your Actions are pinned to a full-length commit SHA. These full-length commit SHAs are immutable and are not affected by updates to tags.  

Modifying your workflows to use full-length commit SHAs instead of tags is cumbersome as you must look up the right commit SHA for each tag. StepSecurity automates this tedious task. As you can see in the example below, the automated pull request (https://github.com/flutter/gallery/pull/937) has changed the v3 tag to its corresponding commit SHA.  

4. Configure Dependabot Version Updates  

As you start using third-party GitHub Actions in your workflows, updates to those Actions will become available. Some of these updates may be bug fixes and new GitHub Actions features, and some may be fixes for security vulnerabilities. You might already be using a dependency update tool such as Dependabot to keep your dependencies up to date, and Dependabot also supports updating third-party GitHub Actions.  

But for Dependabot to update third-party GitHub Actions, its configuration needs to be updated to include the GitHub Actions ecosystem. This configuration needs to be done in each of your GitHub repositories and is a time-consuming process.  

StepSecurity can detect if your Dependabot file needs to be updated to include missing ecosystems such as GitHub Actions and updates it using a pull request. As an example, in this popular repository by Google, you’ll see how they were able to fix a lot of security issues including updating their Dependabot configuration with the help of StepSecurity: https://github.com/google/capslock/pull/6  

Once this change is merged, Dependabot will create pull requests to update third-party GitHub Actions in this repository as new versions become available. This works even if the Actions are pinned to their full-length commit SHA.  

5. Using security tools in CI/CD

As developers push code to their GitHub repository, the code may have security vulnerabilities. It is a good security practice to run security tools like Static Code Analysis tools in CI/CD to detect and address such vulnerabilities early. It helps to identify potential issues, weaknesses, and vulnerabilities in code that may cause problems later.  

Once you have decided what security tools you want to run in your CI/CD pipelines, it is hard to run them consistently across all repositories. In some cases, developers might have forgotten to integrate the required tools in their GitHub Actions workflows.  

StepSecurity helps by analyzing the existing GitHub Actions workflows and detecting missing security tools. It can then add the missing tools using GitHub Actions workflows. As an example, in the below screenshot, the CodeQL workflow is being added to a popular project by Google using an automated pull request.  

Take a look at the pull request here: https://github.com/google/libphonenumber/pull/2913  

Impact of StepSecurity on Google’s GitHub Action Security

StepSecurity’s CI/CD automation had a significant impact on Google’s multiple public repositories helping them be more efficient, save time, gain consistency, and much more. Here is StepSecurity’s impact on Google:  

1. Saving Developers’ Time  

StepSecurity’s solution for GitHub Actions security and monitoring enabled Google to save 100 developer hours approximately. The increased efficiency of developer teams enabled them to spend less time on security management and more time on innovation.  

2. Consistency Across Repositories  

StepSecurity's tools and policies provided Google with a consistent security framework across all its repositories. This uniformity ensured that best practices were applied consistently, reducing the risk of vulnerabilities or misconfigurations.  

3. Reduced Risk  

With StepSecurity’s automation solution, Google was able to reduce security risks across its open-source projects. This enhanced their overall security posture and helped them avoid disruptive supply chain attacks.  

GitHub Actions Security with StepSecurity

StepSecurity can help you follow all GitHub Actions security best practices in public and private repositories. If you’re looking to automate your projects’ CI/CD security, get in touch with us- our experts are always here to help you!