[cphoover]

Vulnerabilities are just code paths that can behave in unexpected ways and be abused.... I'm not sure the author's point, that development configuration could not hide malicious code? Why not?

All NPM does is scan to the dependency graph for vulnerability reports, it doesn't make any assessment of your consuming application's use-case. If you don't find this useful that is fine, don't use it.

I think it's totally worthwhile to figure out which tools rely on insecure dependencies.

Also looks like you can specify npm to ignore dev dependencies:

> Any packages in the tree that do not have a version field in their package.json file will be ignored. If any --omit options are specified (either via the --omit config, or one of the shorthands such as --production, --only=dev, and so on), then packages will be omitted from the submitted payload as appropriate.

[danabramov]

>I'm not sure the author's point, that development configuration could not hide malicious code? Why not?

Quite the opposite! Quoting the article:

As any security professional will tell you, development dependencies actually are an attack vector, and perhaps one of the most dangerous ones because it’s so hard to detect and the code runs with high trust assumptions. This is why the situation is so bad in particular: any real issue gets buried below dozens of non-issues that npm audit is training people and maintainers to ignore. It’s only a matter of time until this happens.

My point is that in the sea of non-issues, real issues are easy to miss and ignore.

>If you don't find this useful that is fine, don't use it.

You can't "not use it" because it's literally the default behavior built into `npm install` now. Of course there are ways to opt out, but this doesn't alleviate the confusion.

[cphoover]

All it does is look to see if either your direct dependencies or descendant dependencies exist in the advisory database....

It seems like a simple algorithm that works pretty well. Perhaps ignoring certain dependencies makes sense, via an ignore list.

I just find the title "NPM is broken by design" to be a little hyperbolic, when it seems like the complaint is that it's tedious removing all the low-quality dependencies from your project. node security/npm-audit has at least increased the conversation around security for many around the npm ecosystem, where there wasn't much-if-any discussion prior. I think they deserve credit for this.

EDIT: I'm not sure why I'm being downvoted.

[argomo]

Think of the article as customer feedback. The customer may not appreciate everything the product does for them, nor may they be using it in the fashion where it would be most effective.

So what? Your job (if this was your customer) would be to figure out how to make them happier. Maybe you are getting down-voted because (while you're correct on some fine points), you're broadly dismissing the concerns of the article. Case in point: those "low-quality dependencies" aren't something you can easily switch out for quality parts... they're deep dependencies of many of npm's flagship tools and frameworks.

[cphoover]

Perhaps the problem is that user's are entirely too entrenched with using blackbox frameworks they don't fully understand like create-react-app, and not that we have a tool that discloses when these frameworks contain vulnerable dependencies.

If we are in a situation where swapping out dependencies becomes so difficult that we just throw our hands up, is that really an issue with tooling?

EDIT:

BTW I'm not opposed to a PR that would allow for a .gitignore style list to ignore warning on specified deps. That could be useful. The issue I have would be respecting other peoples "auditignore" list or whatever... Because just because someone like @danabramov thinks including some package is not a threat, I may or may not agree with him.