I suppose.

But that's a "Perfect is the enemy of good"-like argument. Wherein: Why even reduce an easy to exploit attack surface when there could be holes elsewhere?! Because, you know, it makes things much more secure even if imperfect.

Plus, to me, it is a culture issue. npm just doesn't take security seriously, so we don't see these improvements, and if there was additional test hardening later, I don't expect we'd see them in npm either. Since, they just don't care.

▲

Kuinox 2 hours ago | parent | next [-]

The biggest problem is not software but culture, not at npm, but in the js ecosystem. The js ecosystem is simply a juicy targets, the attack surface is enormous. The attacker can make their attack more sophisticated, there will always be a maintainer that can seed the worm spread.

Meanwhile in the nuget ecosystem is way smaller and have way less mainteners involved for a single given dependency.

	▲	lenerdenator an hour ago \| parent [-]
		I'd go further and say that how JS and the web itself has been run over the years has predisposed it to this sort of thing. JS didn't have a passable stdlib until ES6. It had bugs built into it because Eich was given a stupidly short time window to deliver the first version. Everyone (particularly MS) had (and still sort of do) their own way of interpreting the language. In spite of all of this it became the primary way of developing applications for public consumption. This led to a bunch of people who wanted to be the 10x JS engineer to solve problems with their own libraries and technologies. None of them really talked, they just threw their packages on NPM's registry without second thought and some gained widespread use just by accident. Google tried fixing some of this with Dart but chickened out at the last second. TypeScript was designed by someone competent but can't fix the larger cultural issues. This is what happens when you put SV hubris and "moving fast and breaking things" over doing things the right way.

▲

CoastalCoder an hour ago | parent | prev [-]

> Why even reduce an easy to exploit attack surface when there could be holes elsewhere?! Because, you know, it makes things much more secure even if imperfect.

I'm still trying to calibrate my take on this view.

If attacks are randomly chosen from the set of all potential vulnerabilities, without the attacker knowing which ones had been patched, then that logic clearly makes sense.

But in an adversarial situation where the attacker can guess which vulnerabilities you still have unpatched, or can try many different attack vectors, then having already patched some other vulnerabilities doesn't matter so much.

I guess reality is more complicated though.