11–20 of 129 posts
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 `.
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.
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.
> 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 `.
(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 matter of hygiene and misuse prevention.)
[flagged]
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.
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.
GitHub has a page on this:
https://securitylab.github.com/resources/github-actions-prev...
> 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 `.
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 "bypass" though. Wouldn't the adversary need push access to the repository to edit the workflow file? So, the portion that needs hardening is ensuring the wrong people do not have access to push files to the repository?
On public repositories I could see this being an issue if they do it in a section of the workflow that is run when a PR is created. Private repositories, you should take care with who you give access.
That sinking feeling when you search for how to do something and all of the top results are issues that were opened over a decade ago...
It is especially painful trying to use github to do anything useful at all after being spoiled by working exclusively from a locally hosted gitlab instance. I gave up on trying to get things to cache correctly after a few attempts of following their documentation, it's not like I'm paying for it.
Was also very surprised to see that the recommended/suggested default configuration that runs CodeQL had burned over 2600 minutes of actions in just a day of light use, nearly doubling the total I had from weeks of sustained heavy utilization. Who's paying for that??
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.
“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