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.
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.
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.
`pip install --uploaded-prior-to P7D pre-commit`
https://pip.pypa.io/en/stable/cli/pip_install/#cmdoption-upl...
https://github.com/NuGet/Home/issues/14657#issuecomment-3573...
huh? what do you suggest instead?
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.
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.
Of course, this also assumes that Microsoft's internal scanners are much better than the scanners available to the attackers, since any reasonable attacker is going to just run their obfuscated code through a scanner as part of their CI job. (And maybe even use the MS scanner as an oracle by submitting fragments to NPM to see which pieces of their exploit chain get flagged.)
Waiting until everyone else canaries is much stronger, but even that doesn't work on a targeted attack.
* 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.
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.
https://github.com/rust-lang/rfcs/blob/master/text/3923-carg...
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.
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.
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.