Live data from Hacker News

We should all be using dependency cooldowns

blog.yossarian.net

51–60 of 287 posts

Re: We should all be using dependency cooldowns

#51
post #6

Earlier quoted context omitted.

Do you upgrade all your dependencies every day ? If not, then there’s no real difference in upgrading as if it were 7 days ago.

I upgrade all dependencies every time I deploy anything. If you don't, a zero day is going to bite you in the ass: that's the world we now live in. If upgrading like that scares you, your automated testing isn't good enough. On average, the most bug free Linux experience is to run the latest version of everything. I wasted much more time backporting bugfixes before I started doing that, than I have spent on new bugs…

> I upgrade all dependencies every time I deploy anything. If you don't, a zero day is going to bite you in the ass: that's the world we now live in.

I think you're using a different definition of zero day than what is standard. Any zero day vulnerability is not going to have a patch you can get with an update.

Re: We should all be using dependency cooldowns

#52
post #20

People in this thread are worried that they are significantly vulnerable if they don't update right away. However, this is mostly not an issue in practice. A lot of software doesn't have continuous deployment, but instead has customer-side deployment of new releases, which follow a slower rhythm of several weeks or months, barring emergencies. They are fine. Most vulnerabilities that aren't supply-chain attacks are o…

> for critical vulnerabilities to assess whether your product is affect by it. Only then do you need to update that specific dependency right away. This is indeed what's missing from the ecosystem at large. People seem to be under the impression that if a new release of software/library/OS/application is released, you need to move to it today. They don't seem to actually look through the changes, only doing that if a…

> Sadly, not enough tooling seems to take this into account

Most tooling (e.g. Dependabot) allows you to set an interval between version checks. What more could be done on that front exactly? Devs can already choose to check less frequently.

Re: We should all be using dependency cooldowns

#53
post #51

Earlier quoted context omitted.

I upgrade all dependencies every time I deploy anything. If you don't, a zero day is going to bite you in the ass: that's the world we now live in. If upgrading like that scares you, your automated testing isn't good enough. On average, the most bug free Linux experience is to run the latest version of everything. I wasted much more time backporting bugfixes before I started doing that, than I have spent on new bugs…

> I upgrade all dependencies every time I deploy anything. If you don't, a zero day is going to bite you in the ass: that's the world we now live in. I think you're using a different definition of zero day than what is standard. Any zero day vulnerability is not going to have a patch you can get with an update.

Zero days often get fixed sooner than seven days. If you wait seven days, you're pointlessly vulnerable.

Re: We should all be using dependency cooldowns

#54
post #4

> we should all Except if everyone does it chance of malicious things being spotted in source also drops by virtue of less eyeballs Still helps though in cases where maintainer spot it etc

(Author of the post.)

The underlying premise here is that supply chain security vendors are honest in their claims about proactively scanning (and effectively detecting + reporting) malicious and compromised packages. In other words, it's not about eyeballs (I don't think people who automatically apply Dependabot bumps are categorically reading the code anyways), but about rigorous scanning and reporting.

Re: We should all be using dependency cooldowns

#55

This assumes that most exploits are discovered by pro-active third-party security vendors, instead of being noticed in deployed projects. Is this actually true?

> Is this actually true?

I don't know, but it's the claimed truth from a lot of vendors! The value proposition for a lot of supply chain security products is a lot weaker if their proactive detection isn't as strong as claimed.

Re: We should all be using dependency cooldowns

#56
I do this with my pull-thru-proxy. When new stuff shows up, I know, makes it easy to identify if urgent update is needed. I usually lag a bit. Make a dependency update a dedicated process. Update a few at a time, test, etc. slower but stable.

Re: We should all be using dependency cooldowns

#57

Earlier quoted context omitted.

The point is to apply a cooldown to your "dumb" and unaccountable automation, not to your own professional judgment as an engineer. If there's a bugfix or security patch that applies to how your application uses the dependency, then you review the changes, manually update your version if you feel comfortable with those changes, and accept responsibility for the intervention if it turns out you made a mistake and rush…

You're not thinking about the system dependencies. > Meanwhile, most of the time, most changes pushed to dependencies are not even in the execution path of any given application that integration with them Sorry, this is really ignorant. You don't appreciate how much churn their is in things like the kernel and glibc, even in stable branches.

> You're not thinking about the system dependencies.

You're correct, because it's completely neurotic to worry about phantom bugs that have no actual presence of mind but must absolutely positively be resolved as soon as a candidate fix has been pushed.

If there's a zero day vulnerability that affects your system, which is a rare but real thing, you can be notified and bypass a cooldown system.

Otherwise, you've presumably either adapted your workflow to work around a bug or you never even recognized one was there. Either way, waiting an extra before applying a fix isn't going to harm you, but it will dampen the much more dramatic risk of instability and supply chain vulnerabilities associated with being on the bleeding edge.

Re: We should all be using dependency cooldowns

#58
post #4

> we should all Except if everyone does it chance of malicious things being spotted in source also drops by virtue of less eyeballs Still helps though in cases where maintainer spot it etc

You might read the source if something breaks but in a successful supply chain attack that's unlikely to happen. You push to production, go home for the evening and maybe get pinged about it by some automation in a few weeks.

Re: We should all be using dependency cooldowns

#59
post #3

Doesn't this mean you're leaving yourself open to known vulnerabilities during that "cool down" time?

TFA shows that most vulnerabilities have a "window of opportunity" smaller than one day. Are you anxious going on week-end because Friday evening a zero-day or a major bug could be made public?

Re: We should all be using dependency cooldowns

#60
post #21

Earlier quoted context omitted.

I upgrade all dependencies every time I deploy anything. If you don't, a zero day is going to bite you in the ass: that's the world we now live in. If upgrading like that scares you, your automated testing isn't good enough. On average, the most bug free Linux experience is to run the latest version of everything. I wasted much more time backporting bugfixes before I started doing that, than I have spent on new bugs…

> zero day is going to bite you in the ass Maybe your codebase is truly filled with code that is that riddled with flaws, but: 1) If so, updating will not save you from zero days, only from whatever bugs the developers have found. 2) Most updates are not zero day patches. They are as likely to (unintentionally) introduce zero days as they are to patch them. 3) In the case where a real issue is found, I can't imagine…

My codebase runs on top of the same millions of lines of decades old system code that yours does. You don't seem to appreciate that :)
Post reply on HN