GitHub Actions is the weakest link

KolmogorovComp

This should really what LLM ought to bring in terms of security. Be able to break things faster considering it is now easier for the maintainers to fix them. This has downsides of course, moving further into the "everything rot so fast these days" trope, but we will in a adversarial world where the threat is constantly evolving. Tomorrow (today) the servers and repo won't be scanned by scripts anymore but by increasingly capable models with knowledge about more security issues than many searchers.

tomaytotomato

<tangent> Github actions is running like treacle now. Even when our company pays lots of money for cloud and private Github runners. I know its the go-to punchbag but I think enabling Copilot reviews globally for a large proportion of Github was a bit hasty. The security problems aside, if it continues this way, people won't be able to ship and deploy code from Github actions. We might dare I say it, have to go back to self hosted Jenkins or Travis CI.

rmunn

Back when GitHub Actions first came out, I used commit hashes rather than tags in all my `uses:` lines. Some of my colleagues disagreed, saying that tags were secure enough. I eventually said, "Well, for well-known actions like actions/checkout, sure; if that one gets compromised it'll be all over the news within minutes." But for all the third-party actions, I kept commit hashes. I feel rather vindicated now. There's still a small possibility of getting supply-chain attacked via a SHA collision, or a relatively much larger (though still small in absolute terms) possibility of getting supply-chain attacked via NPM dependencies of the action you're relying on. But if you're not using a commit hash in your `uses:` lines, go switch to it now. And if you're just using major-version-only tags like `v5` then do it RIGHT now, before that action gets a compromised version uploaded with a `v5.2.3` tag.

faangguyindia

I just have a Spot instance we use for our builds. It's turned on via serverless, runs it's job with a timeout and exits. Lately i don't use any managed services and life couldn't be any simpler.

indigodaddy

This aligns nicely with today's/current GitHub Actions outage

recursivedoubts

Programming in YAML has always seemed crazy to me. Actions seem like a great place to create a simple mixed imperative/declarative scripting language (js extension or whatever) with a solid instrumented/observable/debuggable runtime and an OO API that can be run locally against mock infrastructure.

shykes

I apologize in advance for the plug. I've spent the last 5 years warning of the importance of not leaving CI locked in a black box platform and proprietary DSL. All the while going on a quest to reinvent CI as an open, programmable platform. Honestly it's still a work-in-progress: it turns out that reinvention is hard! But, if you want a glimpse of what CI can be when you shed 30 years of legacy, consider checking out Dagger ( https://dagger.io ). Or, if you just want to talk about the future of CI with like-minded systems engineers, without committing to using a particular product, consider joining our Discord: https://discord.com/invite/dagger-io

electricapps

Great writeup. Though combined with the lack of lockfiles for transitive actions, relying purely on static analysis is tough. Linter like zizmor are great, but they struggle with deep composite actions trees and runtime template injection. I got frustrated with the lack of security to started working myself on an open-source runtime sandbox for GHA: https://github.com/electricapp/hasp The first check was inspired by the trivy attack. hasp enforces SHA pinning AND checks that a comment (# v4.1.2) actaully resolves to its preceding SHA. That grew into a larger suite of checks. Instead of just statically parsing YAML it hooks into the runner env itself. Some of its runtime checks mirror what zizmor already does including resolving upstream SHAs to canonical branches (no impostor commits) and traversing the transitive dependency tree. I have a PR up with a comparison document here (hasp vs. zizmor): https://github.com/electricapp/hasp/pull/13/changes#diff-aab... Furthermore, it sandboxes itself to prevent sensitive exfiltration by acting as a token broker which injects the secret at runtime -- the GH token can only ever be used to call the GH API. It uses landlock, seccomp, and eBPF via Rust, so no docker. The token broker sandbox can also be used to wrap a generic executable giving hasp generic applicability beyond GHA context (i.e. agentic or other contexts, where token runtime injection seems quite in vogue) I'm using this as a stopgap until GH rolls out some of the features on its roadmap. I'm moving torward treating the runner as a zero-trust or actively malicious environment, so this was my small contribution on that front.

peterldowns

Yup! Still haven't switched off of Github, but considering it at this point. If you're in my shoes, here's some tools we use that help: - https://github.com/sethvargo/ratchet for pinning external Actions/Workflows to specific commit hashes - https://www.warpbuild.com/ for much faster runners (also: runs-on/namespace/buildjet/blacksmith/depot/... take your pick) - soon moving to Buildkite for orchestration of our CI jobs I still just need a reasonable alternative for the "store our git repo, allow us to make and merge prs" part of things. Hopefully someone takes all the pieces that the Pierre team is publishing and makes this available soon. The Github UI and the `gh` cli are actually really nice and the existing alternative code storage tools are not great IMO.

kfarr

I still don't understand why the official github pages action is on an account called "peaceiris" ?? peaceiris/actions-gh-pages@v3

ossianericson

The OIDC federation between the runner and the cloud resources it touches , that credential gets created once. Permissive enough to not block the first deploy, and it is not what is reviewed when a pinning incident happens. Every one is looking at the action. The identity it runs as just sits there.

globular-toast

I thought GitHub was great back in the day. My account goes back to 2009. It was so much better than what came before, e.g. Sourceforge. Admittedly, the centralised nature was a problem. I was heartbroken when Microsoft bought it. There should be a way for citizens to rebel against such things. It feels like it's been on a downward trajectory ever since.

octorian

I'm personally not a fan of GitHub actions, because of those dependencies outside your control and more because they're a pain to debug. A lot of the time, it feels like I'm tinkering with this huge script then holding my breath and hoping I got it right. The reason I use them, however, is because its more trouble than its worth to maintain build servers for the 3 platforms I care about (Windows, macOS, Linux) myself. Especially for projects that get built sporadically. I think one reason for this pain is that while you can easily run VMs for Windows and Linux on the same host, macOS is kinda its own special unicorn and might need a dedicated box. (But even that aside, maintaining machines you don't use every day can get annoying.)

60secs

pull_request_target is criminally negligent -- github should simply disable it. The security risk for running unvalidated code on any random PR with access to account secrets has no legitimate use case which outweighs its unbounded risk.

pimeys

We just use GHA as a simple caller, and everything is coded in nix scripts. The best part of this is how you can call the CI run directly from your own machine and it works the same.

pss314

John Howard (one of the maintainers of Istio and currently with Solo.io) blogged about "Fast GitHub Actions with Blacksmith" [1]. The blog also contains a link to "GitHub Action Runner Alternatives" [2]. [1]: https://blog.howardjohn.info/posts/blacksmith-gha/ [2]: https://binhong.me/blog/github-action-runner-alternatives/

a1o

Question: could someone make a GitHub pages website that runs zismor in a dropped yml file and tells if it’s bad in some way?

blinded

The crazy thing is there are sooo many good alternatives and things built on top of it that github / ms could purchase and integrate. Product is asleep at the wheel.