5 Effective Third-Party GitHub Actions Governance Best Practices

Introduction 

When we talk about GitHub Actions security, we cannot skip mentioning third-party GitHub Actions. GitHub Actions, with its vast repository of over 20,000 third-party actions, presents both opportunities and challenges for organizations. While these actions offer convenience, they also introduce potential security vulnerabilities. As third-party GitHub Actions run in the context of enterprises’ GitHub Actions environment, they have access to highly sensitive assets such as deployment cloud credentials, source code, and production builds. A breach in a GitHub Actions workflow can have far-reaching consequences, leading to the compromise of enterprise data and production environment.  As organizations increasingly rely on third-party actions to enhance their GitHub workflows, ensuring the security of these actions is a pressing concern for the security team. 

In this blog, we will talk about best practices for securely managing third-party GitHub Actions. Check out our other blogs from the GitHub Action security series: 

GitHub Actions Security Best Practices (With Checklist) 

8 GitHub Actions Secrets Management Best Practices to Follow

GITHUB_TOKEN: How It Works and How to Secure Automatic GitHub Action Tokens

But first, let’s understand the basics of third-party GitHub Actions. 

What are Third-Party GitHub Actions and Why Do you Need to Secure Them? 

Third-party GitHub Actions are actions created and maintained by an individual or organization that can be reused by other users on GitHub in their CI/CD pipelines. These actions may involve a bad actor that may pose a risk to your projects. Even though it may be very convenient to use a third-party GitHub Action in your workflow, you must ensure that it goes through a screening process and is deemed safe by the security team.  

Risks of using third-party GitHub Actions 

Using an unchecked or unreviewed third-party GitHub Action comes with various risks: 

1. Open-source maintainers typically work with limited resources to maintain their open-source Actions. In many cases, maintainers lose motivation to maintain their Actions. Such Actions while still usable, are considered abandoned as no-one is maintaining it anymore. These abandoned Actions are highly risky because of unmitigated vulnerabilities in their code or dependencies. 

2. Malicious actors can add a backdoor into the Action, which gets executed in your enterprise environment when the Action is run.  

3. Deletion of a repository is also possible causing your GitHub Actions CI/CD pipelines to break.  

Now, let’s understand how you can securely leverage third-party GitHub Actions in your workflows and ensure the highest level of GitHub Actions security.  

Enforce “allow specific third-party GitHub Actions” policy 

The default setting on GitHub allows enterprises to use all third-party GitHub Actions. To ensure you do not use unmaintained and unsafe third-party actions (or abandonware) that may pose a risk to your workflows, make sure to change this setting to “allow enterprise, and select non-enterprise, actions and reusable workflows”. This setting will enable you to limit the third-party actions being used in your organizations and explicitly choose the safe ones. Typically, after the setting has been changed, DevOps or Security teams of an organization will perform due diligence and approve or decline the use of a third-party GitHub Action.  

Here’s a screenshot of the setting showing how to choose the “allow enterprise, and select non-enterprise, actions and reusable workflows” option. 

Which option to choose under “allow select actions” 

1. One good option under “allow select actions” is the “allow actions created by GitHub” box. This will allow the usage of all GitHub-owned Actions as they’re well maintained and secure to use. This also means the only people who can make changes to the action are the people at GitHub.  

2. The next option under the “allow select actions” is “allow marketplace actions by verified creators”. Verified creators are partners who work closely with GitHub and can be trusted when it comes to third-party actions.  

3. And finally, the last option “allow specified actions” enables you to explicitly specify the actions you want to allow in your organization for usage.  

Review the Source Code 

Before using a third-party Action in your workflow, make sure you’re auditing the source code. This must be done to ensure that there are no malicious agents or questionable actions in your workflow.  

Checklist for source code auditing 

Here are a few things you should be checking when auditing the source code of the Action. There are several guides on the internet on how to perform security code assessment depending upon the resources you have. At a high level, you should look for code or patterns that: 

1. Access sensitive information as part of their operations such as environment variables, hosts files, etc. 

2. Dynamically download code and execute it 

3. Outbound network calls to unexpected and unknown sources 

Make sure you understand what the Action is doing and that it is handling the GitHub secrets as it should. Any malicious code found should be properly audited and the action be rejected to keep your GitHub Actions security intact.   

Fork Risky Third-Party Actions 

One fundamental best practice you can follow to secure your GitHub Actions workflows from threats is to fork risky third-party actions.

Benefits of Forking 

Here’s why forking can be very beneficial for securing your workflows:  

• By forking a repository, you will gain granular control over actions including updates and reviews  
• When you fork an action, it gives you a copy of it that can be used in case the repository is deleted or compromised 
• It provides change management, empowering you to review updates   before sending it out for production 
• It gives you the surety of the source code being intact between runs 

Post forking, you should apply missing security controls such as branch protection, code updates, etc. In addition, you need to make sure that the forked GitHub Action is being maintained regularly. This includes upgrading vulnerabilities and dependencies for security hardening of the actions. Maintaining forked actions can be quite a time-consuming task and may require dedicated personnel to specifically do it. As a good citizen, we also encourage enterprises following this practice to merge their code improvements upstream so that the entire community can benefit. 

Pin Third-Party Actions 

One of the first things you should do to enhance your GitHub Actions security after checking a third-party Action and choosing them is to pin them. This means you must pin the action’s major and minor versions to ensure you’re always using the same version in your workflows.  

In the following screenshot, you’ll see tags getting translated into pinned Hashes in one of the workflows in Azure’s project “bridge to kubernetes”.

The role of Full-Length Commit SHA 

To ensure that the source code of the version you’re using hasn’t been altered you must pin the action to the full-length commit SHA. The value of commit SHA is unique for each commit and is immutable. This ensures that your GitHub Actions workflows will always use the same release of the Action and forces developers to manually deploy every single update to the Action.  

If you’re using an Action by a reputed organization like GitHub, you can skip using the full-length commit SHA as they’re usually well maintained and updated. 

Check Who the Author and Contributors Are 

Author Verification 

If you’re using a third-party Action owned by an individual developer(s), it is important to verify the author. Doing this will help you understand if the action is secure for usage or not. Check the author’s profile. You can also check the links they’ve added in their profiles (like LinkedIn and X) to verify. If they’re from an organization, chances are, the author is a professional developer and may maintain the action regularly too. Although, if you find anything fishy, it is best to avoid using the action.  

Contributors Verification 

Analyzing the number of contributors and seeing who they are can also help you decide if a third-party Action is safe to use or not. If the action has a lot of contributors, it is more likely to be secured. Moreover, if the contributors are from the same organization, the action is more likely to be maintained properly over time and be secure for usage.  

Learn How to Confidently Manage Risks of Third-Party GitHub Actions in Your CI/CD 

StepSecurity’s January 2024 webinar on managing risks of third-party GitHub Actions talks about how you effectively maintain and securely use third-party Actions. Watch the full recording of the webinar in the summary blog post: 

• Gain insights on GitHub Actions risks and security best practices  
• Learn about third-party GitHub Actions, risks involved and current governance processes  
• Learn practical skills on maintaining third-party GitHub Actions in a hands-on lab 

Conclusion 

As organizations navigate the complexities of GitHub Actions security, a proactive approach to managing third-party actions is important. By integrating the third-party Actions best practices mentioned in this blog, you can actively fortify your GitHub Actions workflows against potential threats.  

And if you’re looking to further discuss your concerns and challenges about the GitHub Actions security of your organization, our team is here to help you out. Try the StepSecurity app for free and enhance your GitHub Actions security now!  

‍

Frequently Asked Questions

Are third-party GitHub Actions safe to use?

Third-party GitHub actions can have bad actors or malicious code that could compromise your workflows. Since third-party Actions are created by individual contributors, it is important to ensure you follow the best practices of third-party GitHub Actions management.  

How do I restrict access to GitHub Actions?

GitHub provides options to control access to Actions within your organization. You can restrict actions to local ones or disable them entirely for enhanced security. Additionally, managing the use of self-hosted runners can further reduce security risks if compromised.

What Should I Consider When Reviewing the Source Code of a Third-Party Action?

When auditing source code, focus on identifying any access to sensitive information, dynamic code execution, or outbound network calls to unknown sources. Ensure the action handles GitHub secrets securely and be vigilant for any signs of malicious code.