NPM and blindly including libraries/frameworks; same mentality and risks as client-side JAVA/Flash/ActiveX?

A recent discussion with a friend over certain aspects of web development, and the string of malicious code being injected into libraries, frameworks, and so forth grabbed from NPM reminded me of something I said when I first encountered the concept:

That it was opening up security holes server-side that mirrored those of Flash in the browser, client-side Java, or worst of all ActiveX extensions.

It's a bold statement, one that when I said it seven or so years ago I was shot down for being "crazy' or "not knowing what I'm talking about".

... and yet here we are, with repositories of libraries people started to trust being taken over by malicious maintainers, code injected into the NPM copies that don't match the GIT listings, and people blindly going "this is neat I'm going to include it" without taking the time to look at or understand the code, much less how one maintainer getting in a huff and pulling their projects can take down everyone using it.

I mean look at the stupid poorly written left-pad library hundreds of other libraries went into dependency hell over, that basically brute forced something any version of Node.js would/should have been able to do in a fraction the code thanks to String.repeat (and now requires no extra code with String.padStart). One guy gets in a pissing contest with a company and the folks running NPM, takes down his code that was such garbage people shouldn't have even been using it anyways, and boom, half the projects using NPM get kneecapped.

But that was just the start of the cracks showing. Look at this year, a bug in NPM itself that if you ran it as root (or sudo) would change permissions willy-nilly all over the filesystem breaking any *nix you were using it on?!? Malicious code injected into eslint-scope that sent your NPM credentials to the attacker? event-stream having code added that would steal bitcoins from certain wallet applications? Then endless stream of coin miners masquerading as useful libraries?

But we've seen this before, in client-side development. People blindly using third party activeX plugins was the start. Maliciously formed Flash files that exploited old versions of flash having far more system access than it should ever have, and of course the king of them all, JAVA in the browser.

It's just now we're repeating those exact same mistakes server-side, where the stakes are much, MUCH higher!

So guess what? I wasn't "crazy", and it appears I did know what I was talking about. Whoddathunkit?!?

There's a saying:

"you shouldn't use a framework without knowing how to do it without the crutch first"

... to which I often append:

"otherwise you are unqualified to know if what the framework is doing is correct, worth using, or even saving you any time/effort"

The blind inclusion of off the shelf libraries via NPM is the same thing, people trusting code that is so easily manipulated, creating a dependency hell, leaving you wide open to attack. Yet such sloppy, sleazy, insecure practices are endlessly justified with lame excuses -- such as it's "Easier" or "simpler" or even laugh "more reliable" when nothing of the sort is actually true.

Though the king of lame excuses seems to be "it lowers the bar so more people can do it, that's a good thing".

Sometimes folks, that bar exists for a reason; "You must be this smart to ride the Internet". That's not being elitist, that's being protectionist given the risks letting any unqualified shmoe who doesn't know any better slop together a bunch of off the shelf answers and blindly hoping it works. That bar is the same one as found at roller-coasters, because some kid flying out of their seat because they're too small for the harness isn't just a danger to that child's welfare, but also anyone else on the ride.

Simply put, this particular "lowering of the bar" is endangering everyone.

There's a reason I have a distrust of NPM, PEAR, and so forth, it's the same distrust client-side browser plugins engender -- but I seem to be relatively alone in this distrust; confusing when the avenues of attack and lack of protections are so plain and easy to see. It's the same reason you don't trust public repositories for script includes, it's the same reason browsers implemented XSS blocks for certain actions.

I think a lot of this is -- again -- the credit mentality in action. People are so obsessed with having something "now" and so impressed by having a "result" now -- ANY RESULT -- that it blinds them to all the things that could go bits-up face-down in the long run. "Pay more later for something you can't afford now" is a scam, no matter the fact that said attitude is why the majority of average Americans will die in debt. A fiscally unsustainable situation. We have created a society where debt is the norm, not the exception, and that mentality has spread into almost every activity and profession.

Sometimes I think we really need to start treating when people say "Well I don't have the time to learn that right now" as actually meaning "I don't really want to put the proper effort into doing this as I'm more interested in hope and wishful thinking than I am the reality of it."

Just seems that as an industry, web development is often far too naive and trusting. But then I spent a decade working in ADA, where security paranoia is the rule of law.