Comment by dmix
2 hours ago
Our company uses yarn 4 which has an option to prevent you from installing an npm package for the first number of days of its release. Most of these seem to be caught within that timeframe (1-3 days).
https://gist.github.com/mcollina/b294a6c39ee700d24073c0e5a4e...
`pnpm` also has that and it's on by default since `v11`:
https://pnpm.io/settings#minimumreleaseage
It’s on by default in yarn 4 too now, but pnpm was the first to market that default minimum gate.
https://github.com/yarnpkg/berry/pull/7135
If this were a universal default, would the strategy defeat itself?
The package event-stream was compromised and went unnoticed for 60 days: https://medium.com/intrinsic-blog/compromised-npm-package-ev...
The package axios was compromised, and hijacked the author's credentials, so every attempt at a fix was unfixed. https://www.trendmicro.com/en_us/research/26/c/axios-npm-pac...
The xz utility was backdoored for 2 months: https://gigazine.net/gsc_news/en/20240403-timeline-of-xz-ope...
A student researcher took over Python ctx and PHPass package maintainership, pushing out malicious changes, and that took over 7 days to be detected and fixed: https://infosecwriteups.com/how-i-hacked-ctx-and-phpass-modu...
Kaspersky found multiple PyPI packages that had been exploited for more than a year: https://www.kaspersky.com/about/press-releases/kaspersky-unc...
"LoftyLife" packages were exploited for several months: https://securelist.com/lofylife-malicious-npm-packages/10701...
Now that the attack window has changed to 7 days, all new exploits like these will come with time bombs to not trigger until 8 days.
> Now that the attack window has changed to 7 days, all new exploits like these will come with time bombs to not trigger until 8 days.
Many automated scanners use static code analysis rather than run the installation script. Not all of them are caught, but a good part of them are and you'd be saved by a delay.
If everybody starts to delay for 3 days, wouldn't it be the case that everyone would discover it on the 3rd day?
Vulnerability scanners and security researchers would be looking those first 3 days
uv supports the same for any Python developers out there: https://docs.astral.sh/uv/concepts/resolution/#dependency-co...
Sadly I haven't seen that Visual Studio/Rider/dotnet/Vs Code have such a feature for the c#/dotnet ecosystem.
Yep, a bummer. The devs don't even consider it a priority, too busy designing the feature:
https://github.com/NuGet/Home/issues/14657#issuecomment-3573...
pip has recently added a similar option, i.e.
`pip install --uploaded-prior-to P7D pre-commit`
https://pip.pypa.io/en/stable/cli/pip_install/#cmdoption-upl...
And somehow poetry doesn’t in 2026.
I don't use poetry anymore but do check the updates before claiming such things
https://python-poetry.org/blog/announcing-poetry-2.4.0/
1 reply →
so? nobody uses it anymore
npm supports this now as well, with e.g. `min-release-age=7` in `.npmrc`
There is something to be said about the need to keep all the packages as the latest and the greatest at all times. Every minor version update doesn’t need to be immediately applied. And maybe high and critical vulnerabilities don’t need to be a minor version upgrade.
I’m having a real problem at work with security theatre and the growing push to obsess over numbers of “vulnerabilities” in our projects. And then auto Dependabot PRs that encourage churn to fix issues that if an informed person actually reviews easily concludes it doesn’t affect us in the slightest.
"maybe high and critical vulnerabilities don’t need to be a minor version upgrade"
huh? what do you suggest instead?
A separate pathway to updates. At the moment there is a pressure to keep all the packages updated at all times. Every time a new version of a random package deep in the dependency tree gets published, you roll a dice: is it a bunch of bug fixes that I don’t care about or a vulnerability patch that need to apply immediately? Since it could be either most devs just auto pilot on updates. This creates an environment where newly introduced vulnerabilities get promoted rather quickly before the version matures. Sure, waiting a few days to update a package sounds great, but there is no guarantee that the vulnerability will be found quickly.
To give you a context, I get 20-30 PRs a week across all my repos with potentially hundreds of packages (non distinct) from dependabot. I give it a cursory look and try to get a summary of changes. Do I evaluate every single package update? Nope.
What happens when everyone adopts this policy? You just change it to two weeks?
The one week cooldown option is not relying on other users to be a canary for you. Its just giving automated scanners a chance to notice. This is the perfect example. I don't think step security found this by accident. They are actively monitoring NPM package releases at some level.
There is something to be said that Microsoft should be scanning packages pre-release. They aren't, though, so for right now there is a ton of value with very little downside if people implement a one week cooldown period.
To answer your question directly, though. If everyone else moves to a one week cooldown, I would absolutely suggest a two week cooldown is a good idea. Being the "slow" moving organization is a good security trade-off so long as you don't take it to extremes and have escape hatches when you actually need to be moving quickly.
Thank you for the thorough response. I got the following from yours and other responses:
* The JS ecosystem has been and will most likely continue to be fast-moving, so it's quite a safe assumption that at no point will a quarantine period be wide-spread.
* This quarantine period is for (semi-)automated scanners to catch the issue. Although considering the above there will always be a non-zero amount of end-user canaries as well.
* Maybe NPM should run scanners before distributing malware?
* If the ecosystem by any chance adopts a week-long quarantine period, you'd be safer if you applied a longer quarantine period.
2 replies →
A large array of automated and semi-automated security scanners are finding things quickly. The main benefit of waiting before updating is to give those scanners time to work.
Would be nice if cargo had a cooldown flag and could respect lockfiles by default.
Security scans and authors realizing an unauthorized version was pushed will generally happen regardless of whether regular users updated. Even for compromises that are found by users updating, it'd generally be better to reduce the number of people affected with a slow roll-out rather than everyone jumping on at once.
You rely on the security companies scanning the packages.
Well, if that actually works, it should be part of the release process, before the packages get placed onto the regular channels.
1 reply →
@exitb it is much more desirable for security scanning companies to compete to find issues in a timely manor. If npm blessed one as a gatekeeper to the whole system they would be between a rock and a hard place. Unable to priorities high impact packages over the long tail of packages no one uses without pissing people off. Unable to add experimental new detections that may be a little noisy at first due to the huge disruption it would cause. Be trivial to game as obscure packages could brute-force their way though then use the same hole on a mainstream package.
Then the ... malware will just add delays? Or do they really do manual in-depth analysis of all new code? Just running and seeing it do things is probably a lot easier.
1 reply →
Always one day more than people on HN tell you. If something is compromised you will hear people complaining here that three days is not enough.
This will never happen unless it's made the default. Most people will always stick with the defaults.
pnpm also support this
The gist link above covers how to use it in yarn, npm, and pnpm