upvote

points

by jerf7 hours ago |
comments
upvoteby csomar6 hours ago|
next
[-]
These half-measures is why everything has gone to shits. Instead of properly auditing software, reducing the quantity and increasing the quality, we keep pushing more and more garbage where all you find is 2FA that, captcha this, not supported this, app not signed, etc..
reply
upvoteby radku1 hours ago|
parent|
next
[-]
Can't agree more. I'm working on OSS security tool that can protect you from Shai-hulud, no half measures.

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

reply
upvoteby woodruffw4 hours ago|
parent|
prev|
[-]
Defense in depth is the “meat and potatoes” of security.

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.

reply
upvoteby rcxdude3 hours ago|
parent|
[-]
Defence in depth is not just 'throw anything in that might improve security' though. The idea is to have multiple strong layers, not a hundred half-measures that are all easily bypassed. A stronger layer might be sandboxing, or separating your build and publishing steps as others have suggested (and also probably worth restricting the credentials the publishing step to just the relevant packages as well). These will at least robustly prevent a malicious dependency from spreading horizontally, but you'll still potentially ship malware to your customers.
reply
upvoteby woodruffw3 hours ago|
parent|
[-]
I would consider 2FA and signing to be strong layers, when applied well. I think everybody agrees we shouldn’t add layers just for the sake of it.
reply
upvoteby rcxdude6 hours ago|
prev|
[-]
The fact that it's not sufficient also largely means it's not necessary either, because the real solution is auditing and trusting the codebase as a whole. All you do when disabling install hooks is make a lot of situations much more difficult to handle.
reply
upvoteby jerf6 hours ago|
parent|
next
[-]
You will also not get very far in engineering if you have a production incident, someone proposes a thing that will mitigate it partially but significantly, and you insist that we can't deploy that mitigation because we need to do the multi-year project that will actually fix it instead. Even if we still need that project, we also need that mitigation.

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.

reply
upvoteby rcxdude5 hours ago|
parent|
next
[-]
Feel free to turn it off yourself, just don't be surprised when the attackers switch tactics. And don't make life harder for everyone else by pushing it as mandatory.

(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)

reply
upvoteby esseph5 hours ago|
parent|
[-]
> 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.

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.

reply
upvoteby rcxdude4 hours ago|
parent|
[-]
If you need quick responses to such things, you're gonna need some intelligence in the loop regardless, even if it's just deciding when it's worth pushing a new release to prod.
reply
upvoteby esseph3 hours ago|
parent|
[-]
What if it needs to get patched and pushed while you and everyone else in the org are asleep?

I mean that's a big window of time now.

reply
upvoteby rcxdude3 hours ago|
parent|
[-]
Always has been, arguably. Either way I don't think most people have their CI configured to automatically re-run when a dependency updates (imagine the thundering herd!), the compromises are more incidental to runs happening for other reasons, and that configuration neither guarantees a quick response nor protects against supply chain attacks.

(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).

reply
upvoteby BigTTYGothGF4 hours ago|
parent|
prev|
[-]
> You will also not get very far in engineering if

Man, I wish.

reply
upvoteby lkjdsklf5 hours ago|
parent|
prev|
next
[-]
Missile defense systems are unnecessary because they could just use tanks

Anti-tank measures are unnecessary because they can just use missiles

reply
upvoteby rcxdude5 hours ago|
parent|
[-]
What's your solution to using a library without executing the code in it?
reply
upvoteby fhdkweig5 hours ago|
parent|
prev|
next
[-]
The term you are looking for is Defense in Depth/Layers
reply
upvoteby rcxdude5 hours ago|
parent|
[-]
That makes sense if it's actually a layer. You can create a thousand minor obstacles and it still won't be a very secure system.
reply
upvoteby jitl6 hours ago|
parent|
prev|
[-]
"make no mistakes" is not the "real solution"
reply
upvoteby rcxdude6 hours ago|
parent|
[-]
Neither is 'close the gate with no fence on either side of it'. If you want to run code, you either need to run it in a sandbox or trust it. Choosing to run only part of the code is not really a solution.

(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)

reply