If this is what will take for folks to move away from JS ecosystem, I'll take it.
This x1000. This is the culmination of 15 years of frontend dev culture. Why does RedHat even have an NPM repo?
Malicious npm packages detected across Red Hat Cloud Services
231–240 of 494 posts
Re: Malicious npm packages detected across Red Hat Cloud Services
#232Why blame on NPM? Would you blame GitLab if an opensource maintainer was hacked and as a result the repo contains malicious changes? All of these recent incidents is just developers doing stupid things ... like using their compromised devices for making production changes, which is basically a big red flag to begin with. In fact, the entire situation has been exacerbated by coding agents because now practically every…
Days since last malicious packages in NPM: 0 (evergreen)
Days since last malicious packages in PyPI: 30
Days since last malicious packages in Maven: 120
I'm sure this isn't 100% accurate, and there are probably better metrics (average number of malicious packages per year, average number of developers affected per year, etc) but they aren't as easy as a quick Google News search.
Re: Malicious npm packages detected across Red Hat Cloud Services
#233Earlier quoted context omitted.
Yes, none of npm's lifecycle hooks. You're just pulling bytes over the wire.
Except now you're making http calls to remote servers that could be compromised.
As long as you embed it with an SRI integrity hash, you're safe, even if the remote server is compromised.
Re: Malicious npm packages detected across Red Hat Cloud Services
#234Hope it's ok I hijack this thread again about setting up cooldowns... (copy pasting my last comment when tanstack was compromised):
I know people have opinions about cooldowns, but they would have saved you from axios, tanstack, (+ @redhat-cloud-services) and many other recent npm supply chain attacks. If you have Artifactory / Nexus, you probably already have cooldowns, but it's easy to set up if you don't. Why cooldowns? Most npm (or pypi) compromises were taken down within hours, cooldowns simply mean - ignore any package with release date younger than N days (1 day can work, 3 days is ok, 7 days is a bit of an overkill but works too)
How to set them up?
- use latest pnpm, they added 1 day cooldown by default https://pnpm.io/supply-chain-security
- or if you want a one click fix, use https://depsguard.com (cli that adds cooldowns + other recommended settings to npm, pnpm, yarn, bun, uv, dependabot and, disclaimer: I’m the maintainer)
- or use https://cooldowns.dev which is more focused on, well, cooldowns, with also a script to help set it up locally
All are open source / free.
If you know how to edit your ~/.npmrc etc, you don't really need any of them, but if you have a loved one who just needs a one click fix, these can likely save them from the next attack.
Caveat - if you need to patch a new critical CVE, you need to bypass the cooldown, but each of them have a way to do so (described in detail in depsguard.com / cooldowns.dev) In the past few months, while I don't have hard numbers, it seems more risk has come from Software Supply Chain attacks (malicious versions pushed) than from new zero day CVEs (even in the age of Mythos driven vulnerability discovery)
Re: Malicious npm packages detected across Red Hat Cloud Services
#235I came across this interesting rant the other day: https://github.com/uNetworking/uWebSockets.js/blob/master/mi... It does make sense that the right way would be to fork every dependency you use and install from your own repo reviewing and merging from upstream as needed. Would be a giant PITA though. :)
The problem is the volume of dependencies. Most modern JavaScript, Python, Rust, Go, etc. projects have many dozens of transitive dependencies.
Hum... You should check your JavaScript numbers again.
I have never seen a project that uses npm and has only dozens of dependencies. Normal numbers are in the 10s of thousands (including different versions of some deps).
Re: Malicious npm packages detected across Red Hat Cloud Services
#236Earlier quoted context omitted.
Furthering the idea that not all package managers are the same, there are entire cycles of the moon where I don't open nuget once. Some ecosystems simply don't need to vendor out very often, and these are the ones where you generally find the least news like this. In about 99% of cases, I have the option to pick between Microsoft, a 3rd party or myself. I'm picking that first option every time I can. If M$ can't hand…
How large a project do you typically use dotnet for? IME dotnet dependency situation is a tire fire, not a month goes by without another dependency biting the dust or going fully commercial with no notice. Which is fair, I suppose, but Go and Java ecosystems don't have it nearly as bad.
> How large a project do you typically use dotnet for?
The largest dotnet project I am responsible for has around 50 megabytes of source files sitting on its main branch right now. If you include the generated WCF references it's probably closer to 100 megabytes.
Re: Malicious npm packages detected across Red Hat Cloud Services
#237Earlier quoted context omitted.
Let me provide context, since a bunch of people responding with "every package manager can be hit!!!" npm, by design, allows all packages to run package supplied arbitrary code as the logged-in user after an update completes. That's an INSANE default. pnpm, by contrast, allows you to essentially "opt-in" only specific packages that need this (e.g. four out of thirty, in one of our projects). Then tacks on tons of oth…
>Putting not just your project at risk, but your entire machine/network. Between average hackers and extortion groups, foreign governments and state sponsored actors and last but not least my own government, I don't think there's much room left for non-compromised supply chains these days. Treat everything that can run foreign code as potentially compromized and keep everything compartmentalized. If you keep your cry…
If I can - I avoid NPM completely and just go with no-build projects.
Re: Malicious npm packages detected across Red Hat Cloud Services
#238Question - is there no way to catch these criminals?
Re: Malicious npm packages detected across Red Hat Cloud Services
#239Earlier quoted context omitted.
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/nuget 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...
Re: Malicious npm packages detected across Red Hat Cloud Services
#240Our 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...
If everybody starts to delay for 3 days, wouldn't it be the case that everyone would discover it on the 3rd day?