[daze42]

It's a minor problem until it becomes a major one. All it takes is one common dependency to go rogue or a bug to be exploited without the maintainers being around to fix it and a large part of the ecosystem becomes unusable. Using a dependency implies an element of trust and now we have a huge web of trust between thousands of maintainers that we really have no way to check. The larger that number grows, the higher the chance of catastrophic failure.

[speedgoose]

Indeed you can't trust that many people and check all the code of that many dependencies. It's a chain of trust, but how is it different than other parts of your stack?

Do you trust every employee working on the Intel CPU microcode? Every maintainer of the Linux kernel? The people who maintain the glibc? The developers of V8 and nodejs? Do you do the same for your database? Your cloud provider? The codebase of your business partners?

I would guess you don't, despite most of what I cited being highly critical in terms of security, and some being written in memory unsafe programming languages with tons of critical issues all the time.

If a NPM dependencies goes rogue, you will get notified. It will also do the frontpage of HN and be mentioned in a comment of news about javascript for years.

But what will most likely happen : a maintainer will fix the issue. If the maintainer is in jail because s•he killed someone, well, someone else can still maintain it or someone else will fork it and other maintainers will use the fork.

In practice when a NPM dependencie of your project has a security issue, all you have to do is to accept a pull request from a robot on Github.

I know it's not perfect, but it's really not that bad.

[daze42]

You bring up very good points. I certainly don't trust most if any of the other critical pieces of the stack. I think those are attack vectors or points of failure as well and that risk needs to be mitigated. But on the other hand, the NPM package web is much larger and the barrier to entry is much lower so I would consider it to be much higher risk than the rest of the stack.

We as an industry need to put work into reviewing, simplifying, and increasing visibility at all levels of the stack, especially firmware. We're building high and fast and while standing on the shoulders of giants is a great place to be, we need to make sure the giant is more than just a house of cards.

[kinjba1]

The Linux kernel, glibc, V8 and nodejs are some of the most vetted software existing. Of course I trust them. If my business partner has security breach it's possible to sue them.

That is different than adding 1000 barely looked at dependencies to my JavaScript project. Every addition is another chance for an undetected security vulnerability. "It's really not that bad" is probably what Equifax thought before the magnitude of what happened was revealed.

[jart]

https://qz.com/646467/how-one-programmer-broke-the-internet-...