%20Icon.svg){kind=small}
Get highlights of our research into the security of GitHub Actions, and our advice on mitigating the risk.
We recently published a report, called The State of GitHub Actions Security, which analyzes the security posture of GitHub Actions workflows and custom GitHub Actions. This report is based on an analysis of 2,500,000 GitHub Actions workflow files belonging to 553,000 organizations and personal users.
We found some troubling security issues in GitHub Actions, including lack of dependency pinning or limits on token permissions.
In this blog post, we share highlights of our findings, plus our recommendations on mitigating the risks of GitHub Actions use.
Avoiding vulnerabilities in GitHub Actions workflows
The Legit research team found a significant number of the following vulnerabilities in GitHub Actions workflows:
- Interpolation of untrusted input
- Execution of untrusted code
- Using untrustworthy artifacts
Avoid these vulnerabilities by:
- Making sure you do not interpolate untrusted data in your workflows. When needed, process user data with environment variables.
- Not executing code from forks (or any other external source) within a privileged workflow.
- Avoiding artifacts from different workflows; if you must, treat them as suspicious and do not trust any input they contain.
- Not using untrusted input to set environment variables. With this input, an attacker could configure environment variables that can lead to pipeline takeover.
- Auditing the third-party Actions you’re using and verify that they adhere to security best practices.
Avoiding the risks of custom Actions
Our research found the GitHub Actions marketplace security posture especially concerning. Most of the Actions there are not verified, maintained by one developer, and have low security scores based on OpenSSF Scorecard.
Custom Actions, although useful, pose a significant risk for workflow authors. To limit the risk, adhere to strict standards when using them. Make sure that you import Actions from verified owners, and those that are active, maintained, and have high security scores.
Avoiding the risks in the building blocks of GitHub Actions workflows
Using triggers securely
Some triggers inherently present more risk than others, for instance, pull_request_target and workflow_run. We found thousands of occurrences of both these triggers.
When possible, avoid using dangerous triggers, such as workflow_run and pull_request_target. If you can’t avoid them, use the following mitigation strategies:
- Do not run the workflow automatically.
- Require a maintainer approval before executing (using labels or environments).
- Set the workflow token permissions to the bare minimum.
- Do not trust any input from the originating workflow; treat any data as potentially malicious.
Using jobs and steps securely
Our research found that 98.4% of the references used by jobs and steps are not following the best practice of dependency pinning, which specifies which package or library an Action can rely on.
Dependency pinning in GitHub Actions (and in general) is crucial for ensuring workflows are stable and reproduceable. By pinning dependencies, you specify the exact versions
of the external packages or libraries your Actions rely on. This practice guards against unexpected changes or updates that could potentially introduce breaking changes, compatibility issues, or security vulnerabilities.
Using runners securely
There are two ways to use runners:
- Managed runners: GitHub owned virtual machines that anyone can use instantly.
- Hosted runners: Self-hosted runners deployed by the user to meet individual requirements such as security, performance, or memory.
Self-hosted runners pose significant security risks (see blog on self-hosted runner security), especially if untrusted workflows run on them.
We recommend only using self-hosted runners with private repositories. Forks of your public repository could potentially run dangerous code on your self-hosted runner machine by creating a pull request that executes the code in a workflow.
GitHub-hosted runners, on the other hand, are clean, isolated virtual machines that are destroyed at the end of the job execution and do not pose the same risks.
Using workflow permissions securely
Each workflow run is assigned a GitHub personal access token scoped to the current repository that enables it to communicate with a GitHub API. By default, this token is highly privileged.
Our research reveals that only 14% of workflows limit token permissions.
Without these limits, the token could be used to perform malicious actions or take over the repository.
Therefore, it is important that workflow authors use the “permission” key to specify the scope their workflow requires.
Overall recommendations on secure GitHub Actions use
The risk companies face from insecure GitHub Actions use is significant. GitHub Actions provide the key to a company’s most critical infrastructure. They are connected both to an organization’s source code and to their deployment environment, meaning that once exploited by attackers, the organization is completely in the attacker’s hands.
Awareness and training
Organizations should prioritize educating their development and operations teams about the security risks associated with GitHub Actions.
This education includes:
• The proper handling of secrets
• The risks of code injection
• The best practices for using third-party Actions
Training sessions should cover the identification and remediation of common vulnerabilities, with a strong emphasis on security-first coding practices and the regular auditing of workflows to detect any unauthorized changes. Moreover, continuous education programs should be implemented to keep all team members updated on the latest security threats and mitigation techniques.
Organization-wide best practice enforcement
Implementing organization-wide best practice configuration enforcement is crucial for maintaining the security of GitHub Actions workflows. Organizations should use GitHub’s built-in features for controlling GitHub Actions behavior to enforce best practices and organization policies.
These policies include:
- Create a list of allowed third-party Actions.
- Configure default permission for workflow tokens to be the least privileged.
- Control which users can execute workflows in the organization.
- Control which repositories are allowed to use self-hosted runners.
- Establish the forking policy in the organization.
- Determine where GitHub Actions should be allowed to approve pull requests.
Tooling
Organizations should leverage security tools that integrate seamlessly with GitHub to provide continuous scanning for GitHub Actions vulnerabilities, misconfigurations, vulnerable dependencies, secrets detection, and more.
Configure these tools to automatically scan the code for each code or configuration change, ensuring immediate feedback on potential security issues.
Get full research report
Get our full research, analysis, and recommendations on GitHub Actions security in the State of GitHub Actions Security report.