DEV Community

0 seconds of 2 minutes, 12 secondsVolume 90%
Press shift question mark to access a list of keyboard shortcuts
00:00
00:00
02:12
 
Brian Douglas for GitHub

Posted on • Edited on

2 1

Keeping GitHub Action workflows secure

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.

Image of Timescale

🚀 pgai Vectorizer: SQLAlchemy and LiteLLM Make Vector Search Simple

We built pgai Vectorizer to simplify embedding management for AI applications—without needing a separate database or complex infrastructure. Since launch, developers have created over 3,000 vectorizers on Timescale Cloud, with many more self-hosted.

Read full post →

Top comments (0)

Billboard image

Try REST API Generation for MS SQL Server.

DreamFactory generates live REST APIs from database schemas with standardized endpoints for tables, views, and procedures in OpenAPI format. We support on-prem deployment with firewall security and include RBAC for secure, granular security controls.

See more!

👋 Kindness is contagious

Please leave a ❤️ or a friendly comment on this post if you found it helpful!

Okay