What's to stop attackers from making a one-off harmless edit ("forgot a comma in readme") and then, once they're whitelisted, deploying a malicious executable to the CI pipeline.
I think the root issue is that people without write access to your repo can queue arbitrary compute on your dime by simply creating a PR and changing the GitHub workflow files (the definition for GitHub actions). This is even a bigger issue for companies with self-hosted runners who can't use those for public repos as an attacker could file a PR with malicious code and compromise a machine (https://docs.github.com/en/actions/hosting-your-own-runners/...)
One possible solution here is that a maintainer needs to okay any change that changes a workflow file before it runs. Not sure if that introduces other problems...
Or put the action definitions outside of the repository for which they apply.
I see the advantages of having CI configuration right next to the code, but once you start deploying multiple branches or accepting outside contributors, the downsides start to outweigh the benefits.
What's to stop attackers from making a one-off harmless edit ("forgot a comma in readme") and then, once they're whitelisted, deploying a malicious executable to the CI pipeline.
I think the root issue is that people without write access to your repo can queue arbitrary compute on your dime by simply creating a PR and changing the GitHub workflow files (the definition for GitHub actions). This is even a bigger issue for companies with self-hosted runners who can't use those for public repos as an attacker could file a PR with malicious code and compromise a machine (https://docs.github.com/en/actions/hosting-your-own-runners/...)
One possible solution here is that a maintainer needs to okay any change that changes a workflow file before it runs. Not sure if that introduces other problems...