Security best practices for authors of GitHub Actions
Improve your GitHub Action’s security posture by securing your source repository, protecting your maintainers, and making it easy to report security incidents.
GitHub Actions, which enables developers to automate, customize, and execute software development workflows right from their repositories, has been gaining in popularity with developers. GitHub’s latest Octoverse report highlights this trend, revealing a 169% increase in GitHub Actions minutes used by developers for tasks in public repositories. There are now over 20,000 Actions available in the GitHub Marketplace.
The growth is wonderful to see, but it’s equally important to maintain the health of the growing GitHub Actions ecosystem, which is why we’re providing best practices to authors of GitHub Actions.
Anyone can use GitHub Actions in their workflows, which is awesome; you don’t have to start from scratch every time you need to automate a particular task, like deploying to Azure or building a Docker image. Although this blog is focused on authors of GitHub Actions, if you are consuming GitHub Actions from the Marketplace in your workflow, we recommend following these security best practices.
Now, let’s dive into steps you can take as the author of a GitHub Action to improve your security posture.
Secure your GitHub Action’s source repository
As a GitHub Actions author, securing the source repository where your action resides is vital, as it serves as a potential attack vector since the action’s source code is held here. There are tons of ways to make sure your source repository is secure, but we’ve outlined a few minimum steps that you can take.
- Enable Dependabot
Dependabot automatically can monitor your project’s dependencies, identifying updates and vulnerabilities as they arise. This is important for source repositories of GitHub Actions because any vulnerability in dependencies can compromise your action and others that have implemented the action in their workflow. When enabled, Dependabot scans your dependencies against the GitHub Advisory Database and alerts you to any potential risks, such as vulnerabilities.Learn more about enabling Depandabot on the source repository of your action.
-
Enable code scanning
Code scanning checks your own code for vulnerabilities and security issues. Unlike Dependabot, which focuses on external dependencies, code scanning scrutinizes the code you write, identifying potential security threats within it. You can either enable CodeQL or a third-party scanning tool that outputs Static Analysis Results Interchange Format (SARIF) data.Learn more about enabling code scanning on the source repo of your action.
-
Resolve critical alerts
Enabling Dependabot and code scanning are proactive steps in maintaining the security of your GitHub Actions, but they are just the foundation. Establishing a process to address the critical alerts those tools generate and resolving them in a timely manner is really what will help to keep your source repository safe. This demonstrates a commitment to security and helps maintain the trust of the community that relies on your actions. -
Create a security policy
Make it easy for users to discreetly report security issues related to your action or its source repository. Security issues reported publicly could lead to even more damage as those with malicious intent may be monitoring these types of posts in public areas like GitHub Issues. You can do this by configuring aSECURITY.md
file in the source repository of the action.
Enable multi-factor authentication (MFA)
In addition to securing your source repository, it’s equally important to protect the maintainer of the action. If the maintainer of the action’s account is compromised it could lead to security risk for those using your action. Ensure maintainers have enabled MFA on their GitHub accounts. It’s a simple yet effective method to help ensure that only authorized individuals can make changes.
Learn more about enabling MFA.
Obtain verified badge
Lastly, actions with the verified creator badge indicate that GitHub has verified the creator of the action as a partner organization. Ensure you have this enabled so users will know it’s the official action from your organization. This badge is enabled during the onboarding to GitHub’s Technology Partner Program.
Learn more about the Actions verified badge.
Wrap-up
By following these best practices, you can improve the security posture of your action and contribute to a better ecosystem. This is an evolving list of best practices and will be added to over time with feedback from our community. If you have questions or feedback on these security best practices for authors of GitHub Actions, please don’t hesitate to reach out to partnerships@github.com.
We’ve curated a list of actions from GitHub Technology Partners that have self-attested to completing these best practices. In the future, we plan to add support to empower you to filter out actions that don’t adhere to best practices.
Tags:
Written by
Related posts
Execute commands by sending JSON? Learn how unsafe deserialization vulnerabilities work in Ruby projects
Can an attacker execute arbitrary commands on a remote server just by sending JSON? Yes, if the running code contains unsafe deserialization vulnerabilities. But how is that possible? In this blog post, we’ll describe how unsafe deserialization vulnerabilities work and how you can detect them in Ruby projects.
10 years of the GitHub Security Bug Bounty Program
Let’s take a look at 10 key moments from the first decade of the GitHub Security Bug Bounty program.
Where does your software (really) come from?
GitHub is working with the OSS community to bring new supply chain security capabilities to the platform.