| 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. |
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.