GitHub Actions provides a platform for continuous integration and continuous delivery (CI/CD), enabling your build, test, and deployment process automation. It allows you to establish workflows that build and test each pull request in your repository and deploy approved pull requests to the production environment.
In this Help Net Security interview, Varun Sharma, CEO at StepSecurity, talks about misconceptions about the security of GitHub Actions, the potential risks of using third-party actions, recommended best practices for using GitHub Actions securely, and more.
What are some common misconceptions about the security of GitHub Actions?
Misconception #1: GitHub Actions security only means using SCA, SAST tools in CI/CD
When people think about GitHub Actions security, their first thought is about adding security tools, like SCA and SAST tools, in the CI/CD pipeline. While this helps find security issues in code, it does nothing to secure the GitHub Actions environment. GitHub Actions, or CI/CD environments in general, have access to the source code, are used to generate release builds, and have access to CI/CD secrets that are used to publish these builds to the cloud. This makes GitHub Actions a target for attackers. GitHub Actions security is about mitigating the risk of attackers compromising the CI/CD environment to steal code or CI/CD credentials (as was the code in the Codecov breach) or tamper with source code or release artifacts during the build process (as was the code in the SolarWinds breach).
Misconception #2: You only need GitHub’s Security features to secure your GitHub Actions
Another misconception is that to secure GitHub Actions, you only need to turn on the security features provided by GitHub, like the ability to set least-privilege token permissions and pin third-party Actions. Since GitHub Actions run on a CI/CD server (also called a runner), the security of the CI/CD server is of paramount importance. For example, in the SolarWinds breach, the CI/CD server was compromised and used to tamper a source code file during the build process to inject a backdoor. In this case, none of the security controls provided by the CI/CD provider would have helped. So, GitHub Actions security also extends to securing the CI/CD servers on which GitHub Actions run.
Could you explain the potential risks of using third-party actions from the GitHub marketplace or other public repositories?
The risk of using third-party Actions from the GitHub Actions marketplace or other public repositories is that this code may be malicious or have a vulnerability that can be used to run arbitrary code in the pipeline. It could be malicious for various reasons, e.g., the Action could have been compromised or a malicious maintainer scenario.
What makes this a high-risk situation is that GitHub Actions workflows have access to secrets, and these secrets could be signing keys or credentials used to push images to container registries or to deploy to the cloud. For example, in the Codecov breach, the bash uploader that Codecov used was compromised by an attacker, who then tampered with the uploader to exfiltrate CI/CD credentials to the attacker’s IP address. This led to the compromise of CI/CD credentials from thousands of organizations. As an example, the GPG private key used for signing hashes to validate HashiCorp product downloads was exposed due to this incident.
What are some recommended best practices for using GitHub Actions securely, especially when integrating them into an existing DevOps pipeline?
Here are some recommended best practices for using GitHub Actions securely, in addition to the security features provided by GitHub:
Use ephemeral GitHub Actions runners
Using ephemeral GitHub Actions runners ensures that each job is run in a fresh environment, so a compromised Action or dependency cannot persist in the CI/CD server and affect other build jobs. GitHub-hosted runners are ephemeral. For self-hosted GitHub Actions runners, the open-source Actions Runner Controller (ARC) project is a great option for doing this. Actions Runner Controller is a Kubernetes operator that orchestrates GitHub Actions jobs as pods. Each job runs as a separate pod, which is then deleted after the job ends.
Filter outbound traffic from GitHub Actions runners
To counter the risk of exfiltration of code and CI/CD credentials, the best practice is to monitor outbound traffic from GitHub Actions runners and, if possible, limit access to only those endpoints that are needed. For example, if egress monitoring and filtering were in place, attackers would not have been able to exfiltrate credentials in the Codecov incident.
Real-Time file monitoring on CI/CD servers
To counter the risk of tampering of source code or artifacts during the build process, it is recommended to use a real-time file monitoring solution on the CI/CD server. For example, if such a real-time file monitoring solution were in place, it would have detected the tampering of source code during the build process, and the SolarWinds breach could have been avoided.
One great way to get hands-on experience with GitHub Actions security threats and countermeasures is to explore GitHub Actions Goat, an open-source educational project.
What future developments do you anticipate in the field of GitHub Actions security?
The current security solutions don’t work well for CI/CD scenarios. The industry is realizing the need for better CI/CD security. For example, CISA and NSA recently published guidance on defending CI/CD environments, highlighting the urgency for robust CI/CD security controls. Compared to more mature security industries like cloud security, CI/CD security is nascent. As GitHub Actions adoption is accelerating, I believe there will be a rich ecosystem of first-party and third-party GitHub Actions security solutions.