undefined

points

[-]

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

by 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.

by 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.

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