141–150 of 287 posts
It's a good idea, but not without weak points, I think. One of the classic scammer techniques is to introduce artificial urgency to prevent the victim from thinking clearly about a proposal. I think this would be a weakness here as well: If enough projects adopt a "cooldown" policy, the focus of attackers would shift to manipulate projects into making an exception for "their" dependency and install it before the regu…
My understanding of a cooldown, from video games, is a period of time after using an ability where you can't use it again. When you're firing a gun and it gets too hot, you have to wait while it cools down.
I was trying to apply this to the concept in the article and it wasn't quite making sense. I don't think "cooldown" is really used when taking a pie out of the oven, for example. I would call this more a trial period or verification window or something?
You could do a lot of this with CI if you scheduled a job to fetch the most recent packages once a month and record a manifest with the current versions, then, if no security issues are reported before the end of the cooldown period, run integration tests against the new manifest. If no tests fail, automatically merge this update into the project. For projects with hundreds or thousands of active dependencies, the fe…
I think there’s a much stronger argument for policies that both limit the number and complexity of dependencies. Don’t add it unless it’s highly focused (no “everything libraries” that pull in entire universes of their own) and carries a high level of value. A project’s entire dependency tree should be small and clean. Libraries themselves should perhaps also take a page from the book of Linux distributions and offer…
Won't using highly focused dependencies increase the amount of dependencies? Limiting the number of dependencies, but then rewriting them in your own code, will also increase the maintenance burden and compile times
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…
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…
I think it also depends on the community as well. Last time I touched Node.js and Javascript-related things, every time I tried to update something, it practically guaranteed something would explode for no reason. While my recent legacy Java project migration from JDK 8 -> 21 & a ton of dependency upgrades has been a pretty smooth experience so far.
I'd prefer to upgrade around the time most of the nasty surprises have already been discovered by somebody else, preferably with workarounds developed.
At the same time, you don't want to be so far back that upgrading uncovers novel migration problems, or issues that nobody else cares about anymore.
It's a good idea, but not without weak points, I think. One of the classic scammer techniques is to introduce artificial urgency to prevent the victim from thinking clearly about a proposal. I think this would be a weakness here as well: If enough projects adopt a "cooldown" policy, the focus of attackers would shift to manipulate projects into making an exception for "their" dependency and install it before the regu…
How would they create that noise?
If it's "only" technical access, it would probably be harder.
> 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
Instead of a period where you don't use the new version, shouldn't we instead be promoting a best practice of not just blindly using a package or library in production? This "cooldown" should be a period of use in dev or QA environments while we take the time to investigate the libraries we use and their dependencies. I know this can be difficult in many languages and package managers, given the plethora of libraries and dependencies (I'm looking at you in particular JavaScript). But "it's hard" shouldn't really be a good excuse for our best efforts to maintain secure and stable applications.
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.
Sure I'll go suggest that to my C-suite lol
Earlier quoted context omitted.
Upgrading to new version can also introduce new exploits, no amount of tests can find those. Some of these can be short-lived, existing only on a minor patch and fixed on the next one promptly but you’ll get it if you upgrade constantly on the latest blindly. There is always risks either way but latest version doesn’t mean the “best” version, mistakes, errors happens, performance degradation, etc.
Personally, I choose to aggressively upgrade and engage with upstreams when I find problems, not to sit around waiting and hoping somebody will notice the bugs and fix them before they affect me :)