Bypassing GitHub Actions policies in the dumbest way possible
blog.yossarian.net
Bypassing GitHub Actions policies in the dumbest way possible
1–10 of 129 posts
Re: Bypassing GitHub Actions policies in the dumbest way possible
#2That 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.
Re: Bypassing GitHub Actions policies in the dumbest way possible
#3That 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.
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.
Re: Bypassing GitHub Actions policies in the dumbest way possible
#4That 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.
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.
Re: Bypassing GitHub Actions policies in the dumbest way possible
#5[deleted]
Re: Bypassing GitHub Actions policies in the dumbest way possible
#6This is a prime example of "If you make an unusable secure system, the users will turn it into an insecure usable one."
If someone is actively subverting a control like this, it probably means that the control has morphed from a guardrail into a log across the tracks.
Somewhat in the same vein as AppLocker &co. Almost everyone says you should be using it, but almost no-one does, because it takes a massive amount of effort just to understand what "acceptable software" is across your entire org.
Re: Bypassing GitHub Actions policies in the dumbest way possible
#7That 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.
“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
Re: Bypassing GitHub Actions policies in the dumbest way possible
#8Not only can you yourself manually check out a specific repo, but if you have submodules and do a recursive checkout, it's also possible to pull in other security nightmares from places you never expected now. That would be one complicated attack to pull off though, chain of compromised workflows haha
Re: Bypassing GitHub Actions policies in the dumbest way possible
#9This is a prime example of "If you make an unusable secure system, the users will turn it into an insecure usable one." If someone is actively subverting a control like this, it probably means that the control has morphed from a guardrail into a log across the tracks. Somewhat in the same vein as AppLocker &co. Almost everyone says you should be using it, but almost no-one does, because it takes a massive amount of e…
The implied fix to the “unusable secure system” is forking the checkout action to your org and referencing it there.
Re: Bypassing GitHub Actions policies in the dumbest way possible
#10Meh. Arbitrary code execution allows you to execute arbitrary code. If you curl | sh something in your github action script then that will "bypass the policy" too.