How to harden GitHub Actions
1–10 of 74 posts
Re: How to harden GitHub Actions
#2I wonder how we get out of the morass of supply chain attacks, realistically.
Re: How to harden GitHub Actions
#3I support places that use GH Actions like its going out of style. This article is useful. I wonder how we get out of the morass of supply chain attacks, realistically.
Re: How to harden GitHub Actions
#4Re: How to harden GitHub Actions
#5I also found this open source tool for sandboxing to be useful: https://github.com/bullfrogsec/bullfrog
Re: How to harden GitHub Actions
#6GitHub Actions is particularly vulnerable to a lot of different vectors, and I think a lot of folks reach for the self-hosted option and believe that closes up the majority of them, but it really doesn't. If anything, it might open more vectors and potentially scarier ones (i.e., a persistent runner could be compromised, and if you got your IAM roles wrong, they now have access to your AWS infrastructure).
When we first started building Depot GitHub Actions Runners [0], we designed our entire system to never trust the actual EC2 instance backing the runner. The same way we treat our Docker image builders. Why? They're executing untrusted code that we don't control.
So we launch a GitHub Actions runner for a Depot user in 2-5 seconds, let it run its job with zero permissions at the EC2 level, and then kill the instance from orbit to never be seen again. We explicitly avoid the persistent runner, and the IAM role of the instance is effectively {}.
For folks reading the Wiz article. This is the line that folks should be thinking about when going the self-hosted route:
> Self-hosted runners execute Jobs directly on machines you manage and control. While this flexibility is useful, it introduces significant security risks, as GitHub explicitly warns in their documentation. Runners are non-ephemeral by default, meaning the environment persists between Jobs. If a workflow is compromised, attackers may install background processes, tamper with the environment, or leave behind persistent malware.
> To reduce the attack surface, organizations should isolate runners by trust level, using runner groups to prevent public repositories from sharing infrastructure with private ones. Self-hosted runners should never be used with public repositories. Doing so exposes the runner to untrusted code, including Workflows from forks or pull requests. An attacker could submit a malicious workflow that executes arbitrary code on your infrastructure.
Re: How to harden GitHub Actions
#7Re: How to harden GitHub Actions
#8Re: How to harden GitHub Actions
#9Great article! I also found this open source tool for sandboxing to be useful: https://github.com/bullfrogsec/bullfrog
Re: How to harden GitHub Actions
#10Many setup Actions don’t support pinning binaries by checksum either, even though binaries uploaded to GitHub Releases can be replaced at will.
I’ve started building in house alternatives for basically every third party Action we use (not including official GitHub ones) because almost none of them can be trusted not to do stupid shit.
GitHub Actions is a security nightmare.