6 ms·

Some of the comments in this thread are wild. Huge dependency trees are bad pattern, plain and simple. The problem isn’t only ridiculous amounts of untrusted c

by dpweb 5y ago

Some of the comments in this thread are wild. Huge dependency trees are bad pattern, plain and simple. The problem isn’t only ridiculous amounts of untrusted code, but thousands of new developers of the last 10 years who think this is the way to write reliable code. Never acknowledged the risks of having everyone write your code for you, and overestimate how unique and interesting their apps are. If you must participate in this madness, static analysis tools exist to scan your 10000 dependencies, taking security seriously is the issue.

deleted 5y ago
[deleted]
noway421 5y ago
Most of those dependencies have well defined, stable api. They use or at least try to follow semver. And you're probably only hitting about 10% of your dependencies on the critical path you're using, meaning that a lot of potentially vulnerable code is never executed. I get the supply chain attacks. I get that you have a tree of untrusted javascript code that you're executing in your app, on install, on build and in runtime. But there's also Snyk and Dependabot which issue you alerts when your dependency tree has published CVEs. We can talk about alert fatigue, but to be honest, I feel more secure with my node_modules folder than I do with my operating system and plethora of DLLs it loads. I don't wanna turn this into a whataboutism argument, but at some point you gotta get to work, write some code and depend on some libraries other people have written.
- laurent92 5y ago
  > Snyk and Dependabot Wait, I’m not safe using “npm audit”?
- grey-area 5y ago
  Semver will not save you.
- ptx 5y ago
  > And you're probably only hitting about 10% of your dependencies on the critical path you're using, meaning that a lot of potentially vulnerable code is never executed. If a dependency has been compromised it doesn't matter if its code is actually used, since it can include a lifecycle script that's executed at install-time, which was apparently the mechanism for the recent ua-parser-js exploit.
pcthrowaway 5y ago
> Huge dependency trees are bad pattern, plain and simple. And what's the alternative? Do you write your own libraries to store and check password hashes complete with hash and salt functions? Roll your own google oauth flow? Your own user session management library? It's madness on either side, the difference is `npm install` and pray allows you to actually get things done
- strogonoff 5y ago
  When vetting a dependency consider whether it depends on packages you already depend on, if new dependency tree is too large try breaking down desired functionality—multiple lower level smaller direct dependencies may have lighter overall footprint, take them and some built-ins and some of your own glue code and you get the same thing with fewer holes. More tangentially, use persistent lockfiles and do periodic upgrades when warranted (e.g. relevant advisories are out) and check new versions getting installed.
- grey-area 5y ago
  You use a trusted standard library which has crypto functions (and lots of other helpers) and for small things you write your own. Yes you can write your own things like session management, yes that is better than the entire web depending on a module for session management which depends on a module which depends on a module maintained by a bored teenager in Russia. Please do check out other ecosystems, there is another way.
- fps_doug 5y ago
  When I'm writing a C program I can somehow depend on only one library for password hashing and one for oauth (maybe two if it also needs curl). In javascript land it's probably a couple dozen, probably from a couple dozen different people.
  - interactivecode 5y ago
    How many developers write C programs versus how many developers write JS apps? Without accounting for that, your comparison makes no sense! Not even mentioning that you’re comparing two very different level languages. A low level language like C would never behave like a high er level language
tempodox 5y ago
> static analysis tools exist to scan your 10000 dependencies Maybe this is a dumb question but could you please suggest some of these tools that can scan dependencies?

by dpweb 5y ago

deleted 5y ago

[deleted]

noway421 5y ago

Most of those dependencies have well defined, stable api. They use or at least try to follow semver. And you're probably only hitting about 10% of your dependencies on the critical path you're using, meaning that a lot of potentially vulnerable code is never executed. I get the supply chain attacks. I get that you have a tree of untrusted javascript code that you're executing in your app, on install, on build and in runtime. But there's also Snyk and Dependabot which issue you alerts when your dependency tree has published CVEs. We can talk about alert fatigue, but to be honest, I feel more secure with my node_modules folder than I do with my operating system and plethora of DLLs it loads. I don't wanna turn this into a whataboutism argument, but at some point you gotta get to work, write some code and depend on some libraries other people have written.

laurent92 5y ago
> Snyk and Dependabot Wait, I’m not safe using “npm audit”?
grey-area 5y ago
Semver will not save you.
ptx 5y ago
> And you're probably only hitting about 10% of your dependencies on the critical path you're using, meaning that a lot of potentially vulnerable code is never executed. If a dependency has been compromised it doesn't matter if its code is actually used, since it can include a lifecycle script that's executed at install-time, which was apparently the mechanism for the recent ua-parser-js exploit.

pcthrowaway 5y ago

> Huge dependency trees are bad pattern, plain and simple. And what's the alternative? Do you write your own libraries to store and check password hashes complete with hash and salt functions? Roll your own google oauth flow? Your own user session management library? It's madness on either side, the difference is `npm install` and pray allows you to actually get things done

strogonoff 5y ago
When vetting a dependency consider whether it depends on packages you already depend on, if new dependency tree is too large try breaking down desired functionality—multiple lower level smaller direct dependencies may have lighter overall footprint, take them and some built-ins and some of your own glue code and you get the same thing with fewer holes. More tangentially, use persistent lockfiles and do periodic upgrades when warranted (e.g. relevant advisories are out) and check new versions getting installed.
grey-area 5y ago
You use a trusted standard library which has crypto functions (and lots of other helpers) and for small things you write your own. Yes you can write your own things like session management, yes that is better than the entire web depending on a module for session management which depends on a module which depends on a module maintained by a bored teenager in Russia. Please do check out other ecosystems, there is another way.
fps_doug 5y ago
When I'm writing a C program I can somehow depend on only one library for password hashing and one for oauth (maybe two if it also needs curl). In javascript land it's probably a couple dozen, probably from a couple dozen different people.
- interactivecode 5y ago
  How many developers write C programs versus how many developers write JS apps? Without accounting for that, your comparison makes no sense! Not even mentioning that you’re comparing two very different level languages. A low level language like C would never behave like a high er level language

tempodox 5y ago

> static analysis tools exist to scan your 10000 dependencies Maybe this is a dumb question but could you please suggest some of these tools that can scan dependencies?