5 ms·
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
by dmix 5mo 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/b294a6c39ee700d24073c0e5a4e93104 https://gist.github.com/mcollina/b294a6c39ee700d24073c0e5a4e...
- phoronixrly 5mo agoWhat happens when everyone adopts this policy? You just change it to two weeks?
- deleted 5mo ago[deleted]
- Tomte 5mo agoYou rely on the security companies scanning the packages.
- exitb 5mo agoWell, if that actually works, it should be part of the release process, before the packages get placed onto the regular channels.
- blm126 5mo agoI think the key right now is that these are semi-automated scanning processes. Right now, companies like step security selectively publish. So, in order for a hacking group to find out if their malware is detected or not, they have to burn access to a useful package. None of this is to say I think Microsoft shouldn't be doing something as part of the release process on NPM. However, there is real value in giving more independent third parties a window to do things semi-manually.
- pixl97 5mo agoIt works because there are multiple companies doing it and double checking the results. For example, is a crypto miner actually an attack? If the package presents itself as a miner, then no. Is connections to other repositories an attack? Again, depends on what the package does. Connections to some other hostname? Depends. There is still a lot of human analysis that occurs in making the call that an attack is occurring.
- saghm 5mo agoYeah, this is the part that I don't get. If the solution is "security testing should come before people install it", why is the big push to have people intentionally add this artificial delay to install later rather than moving the security testing earlier to before the release? If you want to make people not drive on the road until the pavement dries, you don't try to convince everyone to push back their workday by an hour; you just lay the asphalt an hour earlier.
- sandos 5mo agoThen 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.
- Ukv 5mo agoSecurity scanners won't be "manual in-depth analysis of all new code" or "Just running and seeing it do things", but somewhere in-between - utilizing static analysis/machine learning. It's a cat-and-mouse game, but the attacker adding code that waits X days to run something obfuscated would be another pattern that they could look for. I think these attackers are unlikely to add a delay in the first place because the chance of their attack being found out before it activates would be too high. They seem to generally work on the assumption that they have a day or so before the package is yanked (e.g: from maintainer noticing their account is compromised) so need to move fast.
- ZiiS 5mo ago@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.
- BoredPositron 5mo agoAlways 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.
- JoshTriplett 5mo agoA 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.
- blm126 5mo agoThe 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.
- phoronixrly 5mo agoThank 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.
- _flux 5mo ago> Maybe NPM should run scanners before distributing malware? I suspect there's always a human checking these results. If NPM straight out rejects an update due to suspected malware, they might end up rejecting correct updates as well. If they grant some "safe" patterns a special pass, they might get exploited. So I think this only works if you have security scanners that are well-maintained and kept in secret. NPM folks could of course co-operate with some security companies to have a first stab with the releases before they are put to public access. At some point some parties might start want to have monetary compensation for such an arragnement, though.
- bakugo 5mo agoThis will never happen unless it's made the default. Most people will always stick with the defaults.
- Ukv 5mo agoSecurity 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.
- iwhalen 5mo agouv supports the same for any Python developers out there: https://docs.astral.sh/uv/concepts/resolution/#dependency-cooldowns https://docs.astral.sh/uv/concepts/resolution/#dependency-co...
- darth_avocado 5mo agoAnd somehow poetry doesn’t in 2026.
- dist-epoch 5mo agoso? nobody uses it anymore
- armanckeser 5mo agoI don't use poetry anymore but do check the updates before claiming such things https://python-poetry.org/blog/announcing-poetry-2.4.0/ https://python-poetry.org/blog/announcing-poetry-2.4.0/
- genxy 5mo agoMay 3rd 2026. Release too new, didn't read.
- darth_avocado 5mo agoFair, I didn’t do a “as of this morning check”. Should’ve done better. It’s sad because I moved away exactly because this feature was missing and now I’m not going back.
- KORraN 5mo agopip 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-uploaded-prior-to https://pip.pypa.io/en/stable/cli/pip_install/#cmdoption-upl...
- no-name-here 5mo agoSadly I haven't seen that Visual Studio/Rider/dotnet/VS Code have such a feature for the C#/dotnet/nuget ecosystem.
- darth_avocado 5mo agoThere 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.
- Waterluvian 5mo agoI’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.
- red-iron-pine 5mo ago[dead]
- chrisweekly 5mo ago"maybe high and critical vulnerabilities don’t need to be a minor version upgrade" huh? what do you suggest instead?
- darth_avocado 5mo agoA 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.
- mihaelm 5mo ago`pnpm` also has that and it's on by default since `v11`: https://pnpm.io/settings#minimumreleaseage https://pnpm.io/settings#minimumreleaseage
- vinnymac 5mo agoIt’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 https://github.com/yarnpkg/berry/pull/7135
- user3939382 5mo agoIf this were a universal default, would the strategy defeat itself?
- Normal_gaussian 5mo agoNo. Many places run analyzers on published code; many security users have reason to shorten the period. The default period becomes the period where white hats have a chance to detect it and stop it passing the threshold.
- zwily 5mo agoEven if everyone used it, the security scanners would still have time to do their static analysis of new packages. Basically, all the clients implementing a delay would create a de facto quarantine status for new packages so they can be examined before everyone starts installing them. (Why npm doesn't just implement that themselves, I do not know.)
- user3939382 5mo agoThen shouldn’t the analyzers just be part of NPMs acceptance requirements?
- zwily 5mo ago
- olejorgenb 5mo agopnpm also support this
- dmix 5mo agoThe gist link above covers how to use it in yarn, npm, and pnpm
- kylebebak 5mo agonpm supports this now as well, with e.g. `min-release-age=7` in `.npmrc`
- winrid 5mo agonot if you have internal repos?
- hedora 5mo agoI think you can set it on internal repos, but then you need to allow-list internal code. People act like this is simple + solved, but it's not. It turns into 100K-1M's of LLM tokens on a semi-regular basis, or "just hire a build infra team for your side project" pretty quickly.
- winrid 4mo agodid you write this with an LLM? also, no, there are no docs for allow listing internal libraries or namespaces in NPM that I can find
- bram98 5mo agoWhy not the other way around, I man by default and can be changed.
- deleted 5mo ago[deleted]
- 0xbadcafebee 5mo agoThe package event-stream was compromised and went unnoticed for 60 days: https://medium.com/intrinsic-blog/compromised-npm-package-event-stream-d47d08605502 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-package-compromised.html 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-open-source-attack 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-modules-656638c6ec5e 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-uncovers-year-long-pypi-supply-chain-attack-using-ai-chatbot-tools-as-lure https://www.kaspersky.com/about/press-releases/kaspersky-unc... "LoftyLife" packages were exploited for several months: https://securelist.com/lofylife-malicious-npm-packages/107014/ 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.
- Sayrus 5mo ago> 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.
- pixl97 5mo agoInstant attacks are much easier and more common than delayed attacks. Security is an onion.
- throwawayffffas 5mo agoOk so no external dependencies, or pull versions from 2021 and apply security patches?
- wg0 5mo agoIf everybody starts to delay for 3 days, wouldn't it be the case that everyone would discover it on the 3rd day?
- cortesoft 5mo agoVulnerability scanners and security researchers would be looking those first 3 days
- pixl97 5mo agoMost attacks are discovered 'pretty quickly' via scanning services and groups that monitor repositories. The problem is even an hour gap could mean tens of thousands of downloads and executions.