> Are people really this oblivious ...
Yes, yes they are. The vector of "I've been using this package and giving it full permissions for like forever and it has never been a problem." oblivious. One must understand the two-step here:
Step 1) Use someone else's package that solves your problem and doesn't have any issues. Yay you're doing DRY and saving time and effort!
Step 2) The package you got is now corrupted but you don't have any tools to checking to see if you're application is doing anything sus.
The alternative is that you audit every release and look at every change on every file. So suddenly your DRY because a weekly/monthly audit exercise for every single imported package that changes. Use three packages, that's three audit schedules. Use ten? That's ten audit schedules. It's stupid because if you actually used this alternative you'd be spending all of your time just auditing packages and 90+% of the time not finding anything to complain about.
So the ACTUAL alternative, is write your own damn code. You wrote it so you know how it works, and when you change it you know what you changed. And unless you are the bad guy, exploits don't "magically appear" in your code. Vulnerabilities will appear in your code if you don't do code reviews, but remember actualizing this stuff requires both knowing about the bug and exploiting it in the wild, you may end up coding in something that could be exploited but you are unlikely then to use your own vulnerability.
Step 1 sounds like npm, to me.
and Step 2.... ? yeah, we know.
"Write your own code" won't scale. Anyway that horse is out of the barn. We need better SBOM tools.
I disagree, writing your own code is the only thing that does scale. Even if you do nothing more than take the NPM package get source, and then do your own maintenance on it. But having been in different organizations that chose one path or the other, the durable organizations chose to write their own code.