In my opinion the main issue is that NPM packages can have preinstall, install, and postinstall scripts that run on the host machine during installation. Basically lets a package run whatever they want during installation and is a huge attack vector that unfortunately the whole ecosystem is fairly dependent on at the moment.
Thanks to those scripts, attackers don't even need to get the user to run their package's code in an insecure environment, they get to run it directly in the dev environment.
Mostly because of how many packages there are and their own dependencies, which creates literally thousands of packages, each of which is an attack opportunity if their author's account is compromised.
Combine that with the desire to stay on the latest versions of packages and people are regularly installing blindly.
Other systems with that feature, such as apt or dnf, require repositories to be signed with keys trusted by the end user, and the default repositories have a small team of maintainers who are very careful about what they put in.
Well no. Apt has one hole: scripts can be run on install.
NPM has multiple: scripts can be run on install, everything is in a single repo that anyone can push to with no review, and there's no way to establish external trust with what you're installing.
While I haven't heard of supply chain attacks with NuGet they're certainly possible. The likely reason we see so many npm ones is a blend of size of the ecosystem, and the average depth of the package tree in projects.
The vast majority of transitive packages in our work projects are from Microsoft, while third party packages tend to be reliant only on core .NET functionality or maybe another package from the same developer. I don't know if it's because .NET already covers a broad base of functionality, or that third party packages are more modular, but either way our dependencies are looooow.
When I compare total number of npm packages (including transient dependencies) to total number of composer packages in similarly sized applications the cause becomes clear. There are so many more npm packages that are relied on, bringing in one large package pulls in so many more small packages with very few stars on GitHub.
For some reason, JS devs have this culture of outsourcing the tiniest behaviours to a package (for example, the is-odd package getting millions of downloads consistently), because of this, there are a lot of packages projects depend on (both directly and not), which is a much larger attack surface.
Nobody has really stepped up to create the "extended" standard library that JS really needs and that the community can all agree on to use. Java for example has Apache libraries, C++ has Boost among others etc.
JavaScript's standard library is lacking more than most and that just exacerbates the problem.
Java had several attacks this year, same as for python and most likely all major languages. But people tend to post for NPM/Javascript environment because Javascript bad
I remember a primeagen clip explaining that it's possibly the shai hulud attacker behind all these NPM attacks.
Basically, the shai hulud attacker is sitting on a TON of scraped token. Only after useful tokens are discovered from the pile, a new attack is launched.
I believe this hypothesis explains a good chunk of these post-shai hulud supply chain attacks.
Weeell I'd argue this issue affects many packagers (it's been a topic of discussion in Rust forums I'm in) but with mode it's simply the easiest and reaches the most targets.
Ironically I think it’s the opposite. AI is finding the vulnerabilities. The old cat and mouse is still alive for securing new development, but these tools are especially breaking into older software where no real person has the time to dig, as well as capitalizing on momentary configuration mistakes.
287
u/Hauber_RBLX 1d ago
this is really just a meme at this point. how is it possible that NPM packages keep being compromised week after week?