(if you want to disable such hooks yourself, then you may get some security by diversity because you're not using the common configuration. But if it becomes the default then these worms will switch to a different vector)
Sure, solve the problem of "auditing and trusting codebases". Go for it. Shouldn't take you until, oh, let me be generous and give you until next Monday. No sweat.
(if you want a better mitigation: don't automatically update dependencies in CI. At a minimum have a cooling-off period that you only bypass on manual review. This is not hard to implement and at least gives some time for alarm bells to be sounded before you're pwned. Probably while doing the updates you can also just do a quick sanity check on the changes, that'll also catch the ones using a blatant install hook)
One of the problems a lot of companies are having right now is trying to determine a proper window size between CVE release and patching.
On one hand, you have LLM created 0days and attacks are happening almost as fast as CVEs can be posted, and CVEs are being posted at lightning speed. You maybe had a month or a few weeks to patch before, now the window may be down to days or even hours.
On the other hand, you want to prevent these repo bombing attacks.
There's a tension there but I think we're going to end up measuring that window in hours within the year, if we're not already there.
I mean that's a big window of time now.
(If you find you do need updates when you're sleeping, you probably need to delegate that process or at least the process of checking the update to someone you trust, and you're probably paying for the service. This blog post is in large part an ad for just such a service).
I also blocked a proposed mandatory dependabot at work a few months back because I didn't like the way it created a pipeline for any hacker to push a hacked dependency straight into someone's codebase. I'm lifting my objection now that dependabot is defaulting to a 3-day cooldown, though the code bases I'm managing I'm setting to 7 days. (Not to be behind everyone else; I'd be fine if everyone joined me at 7 days. I don't really accept the freeloading objection, there's plenty of entities scanning things now no matter what cooldown you set. I just think 3 is a little tight to expect the full discovery and remediation to take place.)
So, whatever sort of "but it's really hard! I bet you don't do it yourself" implications you may be trying to draw fall very flat. Or whatever you may have been trying to imply about trusting this step but not trusting others... no, I do defense in depth. Giving up on defense in depth because one step isn't enough... well, I think I've probably played the "you won't get very far in engineering" card enough, but hey, here's one last time.
You can see my other responses in this thread about what I think of this in the context of defence in depth. I think disabling install hooks is a very weak defence with substantial downsides and defence in depth does not mean just taking every option that might foil some attack. There are much better means to get a robust extra layer of defence in this context, which is mainly about protecting your publishing pipelines from become a vector for a worm.
Man, I wish.
Anti-tank measures are unnecessary because they can just use missiles
In most sane environments, like for example native languages, this is already the case. Downloading a .dll file and putting it in an appropriate directory won't, by itself, execute code in that library.
You may argue that the code will get executed at some point anyway, but that's besides the point. Sandboxing the build environment is a different problem than sandboxing the test/staging/production environment.
I think we both agree that "adding random obstacles that don't actually protect anything" is not a valid approach to security, but my mental model of the build step is "transformation of input data into output data", and while this step may produce a malicious output from malicious inputs, it should not do anything malicious itself. For example, "gcc source.c" should not execute arbitrary code by itself.
Installing a node package is much more like compiling a dll, not downloading it. The same is true for most package managers that exist for C and C++ as languages as opposed to for an OS. These are two different tools for different use-cases. (though still pretty much all installation processes for all OSs involve an opportunity for arbitrary code execution, as well, apart from just downloading a zip file and extracting it, which is not the norm)
In other words: people should be auditing their software, but we should also design systems and schemes that provide varying degrees of defense and protection when people invariably fail to review the code they run.
Definitely. On the other hand, in my opinion, "not running arbitrary code during package install" is not a "half-measure", it's a basic sanity. This whole arbitrary code execution at install time is a convenience feature that was adapted by some package managers, but it was never a good idea.
Fortunately, nixos solves that for me in most cases.
The idea is to have a local proxy that injects real secrets into requests in-flight, so a compromised library has nothing to steal because it never had access to any of your secrets: https://github.com/inflightsec/agent-vault-proxy
Prod also won't be wormable the way that CI/CD is. With CI/CD I can own another dev, use their creds to push another malicious build script, etc. "Attacker is in my prod env" isn't wormable.
Yes, capabilities in prod would be hugely beneficial but removing CI/CD is massive as a win.
To be clear, just solving the CI/CD portion is insufficient, but it is a massive win.