We are excited to release a public beta of actions-permissions, a tool which monitors your GitHub Actions workflows and recommends the minimum permissions required to run them.
Every GitHub workflow receives a temporary repository access token (GITHUB_TOKEN). These tokens originally had a very broad set of permissions with full read and write to the repository (except for pull requests from forks). In 2021, we introduced a more fine grained permission model for workflow tokens and today the default permissions for new repositories and organizations are set to read-only. However, a significant number of workflows still use a write-all token due to default workflow permission settings without actually requiring write permissions. If you want to check if you are using a broad default permission for your workflow tokens, you can go to the repository (or organization) settings->actions and check the “Workflow permissions” section:
While changing this setting to read-only is a best security practice, it may potentially break existing workflows which currently “just work” with write-all permissions. Applying the least privilege security principle and assigning the minimal needed permissions for the repository token in every workflow case by case can also be a potentially breaking change because complex workflows may include multiple actions and it is easy to miss a permission required for the workflow to function properly. Because workflows can execute a variety of steps, pending error and success criteria, it is also challenging to uncover the full privilege set required for more complicated workflow definitions.
To help you more smoothly navigate the transition to a least-privilege workflow token model, we have published a set of GitHub Actions that allow you to monitor and enumerate the set of privileges that are required by a given GitHub workflow.
The Monitor action installs a local proxy (no information is sent to any third parties) into your workflow runner, collects information about any GitHub API interactions initiated by the workflow, and then displays the recommended minimal permissions as part of a workflow run summary:
The Advisor action, which you can also use as a local tool, is able to summarize the recommendations from multiple runs of the workflow:
Once you apply the recommended permissions in the workflow you can stop using the tools. Any newly required permissions for future iterations of your workflow can be added as needed.
We are excited to make the beta of our permission monitoring GitHub Actions available to you and hope they will help you transition to a more secure workflow permission model. Please give them a try and share your feedback with us!
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.