[efitz]

Writing my comments in the snarky tone of the article.

So the article boils down to “a bunch of these vulnerabilities aren’t applicable to my app which is built using a specific NPM package”.

Congratulations. Welcome to the world of practical information security.

As a security engineer, we’re lucky if your favorite package manager even associates vulnerability information with your packages. Never mind that you’re pulling in code at build time from who-only-knows-where that almost certainly wasn’t security reviewed. But that’s for another post.

Now you have a package manager that is kind enough to tell you that there might be a vulnerability, and you’re upset because NPM did not have specific logic to understand the mechanics of one of the packages it manages? And the upshot is that you have to apply judgment and attention to each notification? Is that a tear in my eye- no, wait, it’s just an eyelash.

How many packages are there? I’m sure the NPM guys have nothing better to do than to build context awareness for every package in their repository.

In all seriousness, I would love to see context awareness in vulnerability reporting. But expecting a package manager to understand that because of your specific choice of framework, that the DoS could only be conducted by an admin of your app, seems unreasonable to me.

[Touche]

Typical security engineer opinion. This "feature" is costing the industry tens, perhaps hundreds of million of dollars in wasted salary hours but it's worth it to you in the off-chance .1% are even potentially affected. Because only your job matters.

[overgard]

The point is that if the feature is going to constantly produce false positives, it's useless. I concur with the author, I never check those warnings anymore.

[efitz]

It’s not a false positive, as described. It’s “mitigated by environment”. The vulnerability is real. The severity is arguably too high.

People throw around “false positive” as a catch-all for “I don’t care about this”. But there are a number of distinct reasons one might not care:

- the scanner is wrong (e.g. there’s a code bug in the scanner like detecting “printed” instead of “sprintf”.

- the output is wrong because the vulnerability isn’t a vulnerability anytime, anywhere under any circumstances

- the scanner is correct, but environment or mitigation’s mean it doesn’t apply to me or the severity is wrong in my environment (this is the case here)

- the scanner is correct, but is giving me output I don’t care about (eg I want to filter for only high/critical but I can’t)

- there is so much output that I can’t pay attention to all of it; it’s so overwhelming that I can’t stand to look at it

Many security products have problems with output that is too verbose. This seems like a trivial problem to work around here; after you’ve triaged that a particular vulnerability doesn’t apply to a particular project, then filter it out with grep -v (our put a bunch of such lines in a bash script and always pipe npm audit output to the script.

Also, I sympathize with concerns that the vulnerability reporter perhaps scored the vulnerability too high. But there’s no perfect solution for that, and I’d rather be aware of a vuln and choose to ignore it, than not be aware at all.

[jeroenhd]

In my opinion, most of these vulnerabilities are completely useless. A React developer performing a DoS on themselves or their build servers with a complex regex is theoretically a problem, but in practice I'd rate it below "low" importance. If a developer wants to ruin a company with huge building costs, why not add a cryptominer to the build process? Why not just spawn hundreds of build tasks? Why bother with generating complex regexes as an attack vessel when you have access to the code?

I'm not even sure if I'd classify it as a security bug at this point, I'd just classify these examples as configuration options to be aware of. Document and ignore.

With the explosion in Javascript packages to implement trivial behaviours, the NPM dependency hell and all the other cruft that "modern" frontend development requires, there are more important security issues to monitor.

Many real issues exist, but their classification is ridiculously flawed. Every security researcher tries to mark their vulnerability up to be the next Eternal Blue of Javascript development, but these vulnerabilities rarely matter.

I think a much bigger problem from a security standpoint is not necessarily the quality of these bug reports, but the sheer number of dependencies even a basic React project has these days. Supply chain attacks are real and the javascript world can do with some dependency purging. Any of the 200 single-line Javascript libraries can be compromised at any point and infect developers all over the world the next time they update their dependencies.

The way people "just" seem to add new dependencies to projects terrifies me. left-pad hit the frontend world and changed nothing. twilio-npm infected developer machines, and create-react-app imports over 1500 libraries as if it's the most normal thing in the world. It's absolute madness.

I have no idea how to fix all of this. It's only a matter of time before someone replicates the research people have done in uploading packages with typos in the name (which have reached into big, famous companies like Apple and Facebook) and start doing some serious damage. Maybe it's already happening: a package having been taken over for scraps, the owners lying in wait while everyone downloads and updates their React/Svelte/etc. packages, ready with their cryptolockers to strike frontend devs and build servers the world over with the push of a button. I wouldn't be surprised, not in the slightest.

[kaishiro]

As a security engineer, do you feel like the addition of npm audit is a net positive for the security of the npm ecosystem?

[efitz]

Net positive for awareness. Not sure I like the “force update with dependency that might break me”. NPM audit needs the ability to filter by severity and the ability for users to tune vuln severities per project.