Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We should all be using dependency cooldowns

blog.yossarian.net

Post reply on HN
Print view View original

241–250 of 287 posts

Re: We should all be using dependency cooldowns

#241

Post by m000 »

coredog64 wrote: post #126
dap wrote: post #86

Earlier quoted context omitted.

At my last job, we only updated dependencies when there was a compelling reason. It was awful. What would happen from time to time was that an important reason did come up, but the team was now many releases behind. Whoever was unlucky enough to sign up for the project that needed the updated dependency now had to do all those updates of the dependency, including figuring out how they affected a bunch of software tha…

My current employer publishes "staleness" metrics at the project level. It's imperfect because it weights all the dependencies the same, but it's better than nothing.

I wonder, are there tools to help you automate this? I.e. to assign a value to the staleness of each package instead of simple "oudated" boolean, and also a weight to each package.

E.g. something like:

  pkg_staleness = (1 * missed_patch + 5 * missed_minor + 10 * missed_major) * (month_diff(installed_release_date, latest_release_date)/2)^2

  proj_staleness = sum(pkg.staleness * pkg.weight for pkg in all_packages)

Re: We should all be using dependency cooldowns

#242

Post by teaganga »

macintux wrote: post #240
m000 wrote: post #238

Isn't the title kind of self-conflicting? Dependency cooldowns work because not everybody is using them. The more people start using dependency cooldowns, the less effective they become.

There are comments elsewhere in the discussion indicating that these attacks tend to be discovered by automated scanners and the maintainers themselves, not by customers negatively impacted.

i had the same thing in mind, though, is not that part of the process until the release of available? should not the release already have the maintainers input?

Re: We should all be using dependency cooldowns

#245

Post by swiftcoder »

IcyWindows wrote: post #162
BrenBarn wrote: post #130

Earlier quoted context omitted.

> The practical problem with this is that many large organizations have a security/infosec team that mandates a "zero CVE" posture for all software. The solution is to fire those teams.

Aren't some of these government regulations for cloud, etc.?

SOC2/FIPS/HIPAA/etc don't mandate zero-CVE, but a zero-CVE posture is an easy way to dodge all the paperwork that would be involved in exhaustively documenting exactly why each flagged CVE doesn't actually apply to your specific scenario (and then potentially re-litigating it all again in your annual audit).

So it's more of a cost-cutting/cover-your-ass measure than an actual requirement.

Re: We should all be using dependency cooldowns

#246

Post by goalieca »

compumike wrote: post #85

There's a tradeoff and the assumption here (which I think is solid) is that there's more benefit from avoiding a supply chain attack by blindly (by default) using a dependency cooldown vs. avoiding a zero-day by blindly (by default) staying on the bleeding edge of new releases. It's comparing the likelihood of an update introducing a new vulnerability to the likelihood of it fixing a vulnerability. While the article…

I’d estimate the vast majority of CVEs in third party source are not directly or indirectly exploitable. The CVSS scoring system assumes the worst case scenario the module is deployed in. We still have no good way to automate adjusting the score or even just figuring false positive.

Re: We should all be using dependency cooldowns

#247

Post by patrick451 »

embedding-shape wrote: post #46
layer8 wrote: 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…

Jumping straight to the new release because it fixed one security bug has always struck me as a round about way of trying to achieve security through obscurity, especially when the releases include tons of other changes. Yes, this release fixed CVE-123, but how many new ones were added?

Re: We should all be using dependency cooldowns

#249

Post by lambdaone »

compumike wrote: post #85

There's a tradeoff and the assumption here (which I think is solid) is that there's more benefit from avoiding a supply chain attack by blindly (by default) using a dependency cooldown vs. avoiding a zero-day by blindly (by default) staying on the bleeding edge of new releases. It's comparing the likelihood of an update introducing a new vulnerability to the likelihood of it fixing a vulnerability. While the article…

The big problem is the Red Queen's Race nature of development in rapidly-evolving software ecosystems, where everyone has to keep pushing versions forward to deal with their dependencies' changes, as well as any actual software developments of their own. Combine that with the poor design decisions found in rapidly-evolving ecosystems, where everyone assumes anyting can be fixed in the next release, and you have a recipe for disaster.

Re: We should all be using dependency cooldowns

#250

Post by hoistbypetard »

tracnar wrote: post #77
embedding-shape wrote: post #46

Earlier quoted context omitted.

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

You could use this funky tool from oss-rebuild which proxies registries so they return the state they were at a past date: https://github.com/google/oss-rebuild/tree/main/cmd/timewarp

That... looks like it would let me do this exactly the way I want to for npm and python. For my C++ stuff, it's all vendored and manual anyway.

I had not seen that tool. Thanks for pointing it out.

Post reply on HN