Live data from Hacker News

How to harden GitHub Actions

wiz.io

1–10 of 74 posts

Re: How to harden GitHub Actions

#4
post #3
post #2

I 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.

We use linux distributions.

How do apt, dnf, and apk prevent malicious software from getting into repositories?

Re: How to harden GitHub Actions

#6
Glad this got posted. It's an excellent article from the Wiz team.

GitHub 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.

[0] https://depot.dev/products/github-actions

Re: How to harden GitHub Actions

#9
post #5

Great article! I also found this open source tool for sandboxing to be useful: https://github.com/bullfrogsec/bullfrog

It's pretty depressing that such functionality isn't a core feature of GHA. Seems like low hanging fruit.

Re: How to harden GitHub Actions

#10
I’ve been reviewing the third party Actions we use at work and seen some scary shit, even with pinning! I’ve seen ones that run arbitrary unpinned install scripts from random websites, cloning the HEAD of repos and running code from there, and other stuff. I don’t think even GitHub’s upcoming “Immutable Actions” will help if people think it’s acceptable to pull and run arbitrary code.

Many 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.

Post reply on HN