Hacker News Reader

Comment by ramesh31 | Hacker News Reader

I was digging through node_modules today and almost had a heart attack. We are running this code across millions of users right now.

View on HN

Did you ever audit the code in that package or read the source at least once?

That's a tremendous expectation. There are 913 node_modules in the first project I glanced at. That's millions of lines of code.... More than one person can reasonably audit even if it's their full-time job. Where would this responsibility end? Should they also be auditing Node.JS source code? And nightly browser builds? No, we necessarily federate our trust at some point in these things being raised by others (like now, albeit 23 days late).

It seems like you're attempting to suggest that third party javascript is on equal trust footing with major tools and things by international corporations

My point was that it's unreasonable to expect the exhaustive audit of all node modules. That said, "major tools and things by international corporations" like Gatsby depend on the topic library [0].

https://www.npmjs.com/browse/depended/event-source-polyfill

There is a distributed code review system that is intended to make it feasible to do the necessary review:

https://github.com/crev-dev/

I don't run nigtly browser builds because that's too much to keep up with. I have actually read quite a bit of the code for the browser I use. I read almost everything I deploy because I'm responsible for it. Using other people's code absolves you from maintenance but not responsibility, that's something people need to start understanding. It's a very reasonable expectation that you read through your dependencies, if it's too much then it's time to trim some fat.

I feel like this question has good intentions but comes across wrong. It's virtually impossible to audit literally every nested dependency.

Depends on how much the company values (i.e. is paying for) that supply chain security. And if enough companies cared they could even save money by pooling efforts.

The crev folks aim to create a tool to allow that pooling:

https://github.com/crev-dev/

If nobody can audit the dependency tree, should you really be using it?

"Depends". The benefits of leaning on open source pays off the majority of the time. Are you exposed to more risk? Yes. Does that mean you shouldnt take that risk? Not really. Otherwise you'd struggle to move quickly and be competitive.

Of course certain things change this balance. Hopefully nuclear power plants dont have NPM in their toolchain. And I believe financial orgs already have quite heavy auditing of dependencies.

Open source and large dependency trees are orthogonal. You can depend on closed modules in compiled languages, many people do. You can write open source software and only depend on the standard library, many people do.

It's literally possible. You just have to have that as a goal from the start of the project. I just looked at our call center product. Across frontend and backend we have 70 npm dependencies required for build/runtime. Most are small.

It's not that hard to do some superficial review once and do a diff of node_modules when updating npm-shrinkwrap.json for whatever reason.

It's utterly irresponsible to not do so when pulling code from untrusted sources like npm.

Don't pull in dependencies which have many dependencies themselves. There are many projects that pride itself on minimalism and lack of transitive dependencies. Choose those. Etc.

Good question, I'd love to see an honest answer...

Reply on news.ycombinator.com