30
GitHub Actions Cache Poisoning is eating open source
(neciudan.dev)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 17 May 2026
30 points (96.9% liked)
Security
2083 readers
8 users here now
A community for discussion about cybersecurity, hacking, cybersecurity news, exploits, bounties etc.
Rules :
- All instance-wide rules apply.
- Keep it totally legal.
- Remember the human, be civil.
- Be helpful, don't be rude.
Icon base by Delapouite under CC BY 3.0 with modifications to add a gradient
founded 2 years ago
MODERATORS
The solution is simple: stop using Github actions. If you simply must run CI, run it on a local machine or VM that is sandboxed.
Running actions on your own machine doesn't solve cache poisoning or supply chain attacks, your VM will download compromised npm package or github actions the same way GH runner does.
Version pinning/script disabling makes a compromise slightly less likely, rolling your own package server helps a lot (but who got time to maintain version whitelist).
Honestly the best solution is to have minimum amount of dependencies. You don't need a GH action to ping indexers or generic foreign key library for your backed, hammer one yourself.
That and scope all your keys so the leak won't be as devastating 🤷♀️
Isn't this a sane practice in programming anyway? Just don't go overboard with dependency minimalism.
Yes but the reality of JavaScript codebases is that you'll typically import hundreds if not thousands of dependencies fairly quickly. Last time I looked at the UI codebase at my job it was sitting at over 40k.
That's one of the reasons) why JS development is the shitshow it is.
IDK how other people are, but to me solving a problem with a single #include just feels right. Less code to maintain, responsibility is shifted to a dedicated person, obviously much faster.. But also constant anxiety and daily monitoring of security blogs, so I'm trying to cut back
How do you run it on a local machine?