GitHub Security Lab’s mission is to inspire and enable the community to secure the open-source software we all depend on. In a recent disclosure, they disclosed 84 vulnerable GitHub Action workflows ranging from pull_request_target abuse to script injections reported to maintainers.
If you have been following my daily tips, you know I am a big of the pull_request_target event for my open-sourced GitHub Actions. Today I am going to talk about and how you can ensure your use of it is secure.
GitHub Actions is a powerful feature, but with that power comes the responsibility to secure your code.
TL;DR: To prevent access to sensitive repository information; Refrain from using the pull_request_target with the actions/checkout.
| workflow trigger event | access | access to repo secrets |
|---|---|---|
| pull_request | merge commit | no |
| pull_request_target | target repository (including secrets) | yes |
Using actions/checkout stores secrets in a local .git/config folder in the environment. This is not enabled if the action config set persist-credentials: false. By default, GitHub Actions scrub secrets from memory that are not explicitly referenced in the workflow or in an included Action.
Any automated processing of PRs from external forks is potentially dangerous and should be treated like untrusted input. As a precaution, reviewing the code from the GitHub Actions enabled on your project to validate its source.
You can treat PR's from forks as untrusted input, by not including write access to forked repositories PR'd again your project.
GitHub's standard pull_request workflow trigger by default prevents write permissions and secrets access to the target repository. However, in some scenarios, such access is needed to properly process the PR. To this end, the pull_request_target workflow trigger was introduced.
The pull_request_target runs in the context of the target repository of the PR, rather than in the merge commit. This means the standard checkout action uses the target repository to prevent accidental usage of the user-supplied code.
With all this said, if you can trust/validate all the input from a user's PR then you are in the most secure position.
To keep up to date on other vulnerabilities through GitHub, checkout GitHub's full vulnerability list.
https://securitylab.github.com/advisories
This is part of my 28 days of Actions series. To get notified of more GitHub Action tips, follow the GitHub organization right here on Dev.
08:04
Top comments (0)