Shared code repositories for OSS are much older than npm. See at least maven central for Java.

What makes npm a more relevant target is a much smaller standard library and thinner dependencies, leading to more chances that a random project will have code of suspicious provenance. The vast majority of what a backend Java project depends on was probably written either by the same 3 companies, or large, established OSS repos. So this is relatively solvable if people in steering committees decided they cared. It's improving, but I'd argue not fast enough.

▲

ctkhn 4 hours ago | parent | next [-]

I noticed this a lot with java where most of what I needed that wasn't specific to our company's business logic was already available in the standard library, and a lot of the OSS libraries I needed were relatively reputable and well-known. I did a few personal backend projects with js and the amount of functionality I had to crate-dig from npm drove me insane, on top of the more complicated chain of trust for how many layers packages from npm can have.

▲

hoppp 5 hours ago | parent | prev [-]

Generally we don't hear much about attacks in Java like that. But they probably exist but python and javascript are targeted mainly because everyone uses them. They cover a lot of ground.

▲

td521534f12 4 hours ago | parent [-]

A big reason Python and Java are juicy targets are because for a very long time pip and npm executed code on the user's machine on package install, not just on import. (This is changing in newer versions of pip and npm IIRC)

▲

eddythompson80 3 hours ago | parent [-]

I think it's mostly about attach surface. There is nothing fundamentally different in the threat model or security boundary between any language in terms of how they manage their dependencies. Even platforms like Maven or NuGet that don't have an install script, you're still likely to trigger a build or a quick run for the application right after installing that would trigger code execution anyway.

The chances of a person getting hit during the `npm install` phase is bigger but not that different than the `dotnet add package ... && dotnet run`.

I do agree though that the massive surface of npmjs, pip, and even cargo means that package signing is also not realistic. If you have the average 300 npm packages, no one is gonna pay attention to the authenticity of 200 different signing keys. It would be a lot easier with something like java where you probably just need to trust a handful like openjdk, jackson, junit, or log4j keys and be 90% there. (And hope the supply chain attack hasn't compromised the signing keys too of course)

	▲	td521534f12 an hour ago \| parent [-]
		The reason execution on install is a bigger deal than execution on import/run is because a lot of developers today run their code inside of sandboxed environments (containers, VMs, etc.) which prevents the malware from easily accessing stuff like session tokens.