Most of these attacks don't make it into the upstream source, so solutions[1] that build from source get you ~98% of the way there. If you can't get a from-source build vs. pulling directly from the registries, can reduce risk somewhat with a cooldown period.
For the long tail of stuff that makes it into GitHub, you need to do some combination of heuristics on the commits/maintainers and AI-driven analysis of the code change itself. Typically run that and then flag for human review.
[1] Here's the only one I know that builds everything from source: https://www.chainguard.dev/libraries
(Disclaimer: I work there.)
This was supposedly discovered by "Socket researchers", and the product they're selling is proactive scanning to detect/block malicious packages, so I'd assume this would've been discovered even if no regular users had updated.
But I'd claim even for malware that's only discovered due to normal users updating, it'd generally be better to reduce the number of people affected with a slow roll-out (which should happen somewhat naturally if everyone sets, or doesn't set, their cool-down based on their own risk tolerance/threat model) rather than everyone jumping onto the malicious package at once and having way more people compromised than was necessary for discovery of the malware.
Having the forge control it half-defeats the point; the attackers who gained permission to push a malicious release, might well have also gained permission to mark it as "urgent security hotfix, install immediately 0 cooldown".
And no, however compromised packages to the forge happens, that is not the same thing as marking “urgent security hotfix” which would require manual approval from the forge maintainers, not an automated process. The only automated process would be a blackout period where automated scanners try to find issues and a cool off period where the release gets progressively to 100% of all projects that depend on it over the course of a few days or a week.
But for researchers who aren't sufficiently effective until the first victim starts shouting that something went sideways, the malicious actor would be wise to simply ensure no victim is aware until well after the cooldown period, implementing novel obfuscation that evades static analysis and the like.
While bad actors would be wise to ensure low-cooldown users are unaware, I would not say they can "simply" ensure that.
Code with any obfuscation that evades static analysis should become more suspicious in general. That's a win for users.
A longer window of time for outside researchers is a win for users -- unless the release fixes existing problems.
What we need is allowing the user to easily change from implicitly trusting only the publisher to incorporate third parties. Any of those can be compromised, but users would be better served when a malicious release must either (1) compromise multiple independent parties or (2) compromise the publisher with an exploit undetectable during cooldown.
Any individual user can independently do that now, but it's so incredibly time-consuming that only large organizations even attempt it.
Ir seems like if you were at all likely to be giving dependencies the extra scrutiny that discovers a problem, you’d probably know it? Most of the people who upgraded didn’t help, they just got owned.
A cooldown gives anyone who does investigate more time to do their work.
Also, check out the VW Diesel scandal.
In the context of TFA, don't rely on third party github actions that you haven't vetted. Most of them aren't needed and you can do the same with a few lines of bash. Which you can also then use locally.
Needless to say I’m running all my JS tools in a Docker container these days.
isn't it obvious?
it should be obvious.
why isn't obvious?
With pnpm, you can also use trustPolicy: no-downgrade, which prevents installing packages whose trust level has decreased since older releases (e.g. if a release was published with the npm cli after a previous release was published with the github OIDC flow).
Another one is to not run post-install scripts (which is the default with pnpm and configurable with npm).
These would catch most of the compromised packages, as most of them are published outside of the normal release workflow with stolen credentials, and are run from post-install scripts
By contrast, a client-side cooldown doesn't require very much ecosystem or index coordination.
This kind of thinking is why I don't trust the security of open source software. Industry standard security practices don't get implemented because no one is being paid to actually care and they are disconnected from the users due to not making income from them.
(With that said, I think it also varies by ecosystem. These days, I think I can reasonably assert that Python has extended significant effort to stay ahead of the curve, in part because the open source community around Python has been so willing to adopt changes to their security posture.)
There's risk there of a monoculture categorically missing some threats if everyone is using the same scanners. But I still think that approach is basically pro-social even if it involves a "cooldown".
Exceptions to quarantine rules just invites attackers to mark malicious updates as security patches.
If every kind of breakage, including security bugs, results in a 2-3 hour wait to ship the fix, maybe that would teach folks to be more careful with their release process. Public software releases really should not be a thing to automate away; there needs to be a human pushing the button, ideally attested with a hardware security key.
TypeScript on its own is a great language, with a very interesting type system. Most other type systems can’t run doom.
https://simonwillison.net/2025/Feb/27/typescript-types-can-r...
That doesn't sound like a compliment.
Note the if you get
failed to parse year in date "7 days": failed to parse "7 da" as year (a four digit integer): invalid digit, expected 0-9 but got
uv self updateIf you're brave you can run whonix.
The issue is developers who have publish access to popular packages - they really should be publishing and signing on a separate machine / environment.
Same with not doing any personal work on corporate machines (and having strict corp policy - vercel were weak here).
I know it's far from watertight (and it's useless if you're working with bitwarden itself), but I hope it blocks the low hanging fruit sort of attacks.
I think this is a bad idea, because it means the permissions of any new folders have to be closely guarded, which is easy to forget.
Avoid software that tries to manage its own native (external, outside the language ecosystem) dependencies or otherwise needs pre/post-install hooks to build.
If you do packaging work, try to build packages from source code fetched directly from source control rather than relying on release tarballs or other published release artifacts. These attacks are often more effective at hiding in release tarballs, NPM releases, Docker images, etc., than they are at hiding in Git history.
Learn how your tools actually build. Build your own containers.
Learn how your tools actually run. Write your own CI templates.
My team at work doesn't have super extreme or perfect security practices, but we try to be reasonably responsible. Just doing the things I outlined above has spared me from multiple supply chain attacks against tools that I use in the past few weeks.
Platform, DevEx, and AppSec teams are all positioned well to help with stuff like this so that it doesn't all fall on individual developers. They can:
- write and distribute CI templates
- run caches, proxies, and artifact repositories which might create room to
- pull through packages on a delay
- run automated scans on updates and flag packages for risks?
- maybe block other package sources to help prevent devs from shooting themselves in the foot with misconfiguration
- set up shared infrastructure for CI runners that
- use such caches/repos/proxies by default
- sandbox the network for build$
- help replace or containerize or sandbox builds that currently only run on bare metal on some aging Jenkins box on bare metal
- provide docs
- on build sandboxing tools/standards/guidelines
- on build guidelines surrounding build tools and their behaviours (e.g., npm ci vs npm install, package version locking and pinning standards)
- promote packaging tools for development environments and artifact builds, e.g.,
- promote deterministic tools like Nix
- run build servers that push to internal artifact caches to address trust assumptions in community software distributions
- figure out when/whether/how to delegate to vendors who do these things
An alternative hypothesis: what if 7-day cooldowns incentivize security scanners, researchers, and downstream packagers to race to uncover problems within an 7-day window after each release?
Without some actual evidence, I'm not sure which of these is correct, but I'm pretty sure it's not productive to state either one of these as an accepted fact.
Many companies exist now whose main product is supply chain vetting and scanning (this article is from one such company). They are usually the ones writing up and sharing articles like this - so the community would more than likely hear about it even if nobody was actually using the package yet.
> This plan works by letting software supply chain companies find security issues in new releases. Many security companies have automated scanners for popular and less popular libraries, with manual triggers for those libraries which are not in the top N.