Post

most of these github actions driven breaches are because of pull_request_target. here's some tips of what to look for when reviewing your own workflows. worth noting - it is safe, and necessary, when used correctly 🧵

22 reposts109 likes

it's "safe" in the same way that a mandolin slicer is "safe" - it's possible to use it safely, but requires care and constant attention. I don't think I'd call it generally, "safe"

that's fair. the risk of misconfiguring it is very high, especially in a not-so-secure way. so, in that way, it is unsafe to use

the pull_request_target trigger runs a workflow when a PR is opened against the target (base) repo. this means the workflow runs in _context_ of that repo, i.e. has access to secrets and what not. by default, the `checkout` action will checkout _the base repo_ (NOT the fork)

it needs a lot more care when this is introduced... now we're checking out the FORK in the context of the base repo. still safe, though! as all we've done is check out some sources - we haven't run anything at this point.

now is where we need to take extra care. if we now run `pnpm i` (with install scripts enabled), the fork can just declare a prepare script which sends github secrets off somewhere - excellent. TIP: `--ignore-scripts` _or_ avoid running install in this context at all

even with `--ignore-scripts`, a build can do just the same. so the tip here is: EXECUTE NOTHING. if you checkout a fork in pull_request_target, do not install, do not build, don't run anything in the checked out code.

Interesting write up. Especially the artifact pattern is nice. I hope though that GitHub will introduce ways to mitigate this as well. The comment is a great example. We should have a way to make an action which can explicitly only comment, or in some cases can see very specific secrets.