[mbesto]

> this “vulnerability” is absurd in this context

Yes that's exactly the point. The audit tool has no awareness of the context and nor do the people who create severities.

If severities were absolute then there would be no reason for anyone to review them. You would simply upgrade your libraries and be done with it, but that can't always be achieved nor may make business sense.

I do agree with the author's note about providing a better way to provide feedback on severity reviews.

npm audit is better than no npm audit...telling people it's broken by design is going to discourage them from using it completely. smh.

[city41]

I do think he makes a valid point towards the end though. create-react-app, and projects like it, get a lot of bug reports about these vulnerabilities. It's a lot of energy dedicated to something that ultimately isn't that important if you understand the context. I can understand the frustration.

[raziel2p]

Exactly. Why does it matter if it's absurd in this context? Just upgrade it to be on the safe side. Asking vulnerability databases to judge whether vulnerabilities are safe in devDependencies or not is a ridiculous idea, even more so when you consider that the line between static and dynamic have gone blurry long ago.

[danabramov]

>Just upgrade it to be on the safe side.

A big part of the problem is there is no reliably way to "just upgrade it" today in npm:

- `npm audit fix --force`, which is supposed to do that, is buggy and doesn't work

- There is no way to override a transitive dependency with npm (there is with Yarn though, so hopefully this feature will come to npm soon)

- Sometimes the fix in transitive dependency _also_ includes breaking changes (e.g. because it wasn't backported), and so updating it subtly breaks the logic

>Asking vulnerability databases to judge whether vulnerabilities are safe in devDependencies or not is a ridiculous idea

I don't think databases can do it, but what I'd like to be able to do is to be able to provide advisory that the way _my package_ uses a concrete transitive dependency is not affected by that vulnerability. Because as the package owner I _do_ have that context. I understand there may be significant issues with this approach though!

[cphoover]

> * - There is no way to override a transitive dependency with npm (there is with Yarn though, so hopefully this feature will come to npm soon)*

I do not think this is a good idea as it allows consumer's of a library to utilize that dependency with untested, and unspecified transitive decencies What happens when a transitive dependency breaks the 1st level dependency? What a PITA that would be to try and fix.

[cphoover]

> Because as the package owner I _do_ have that context. I understand there may be significant issues with this approach though!

But what if one of your contributors slips in a merge that uses the vulnerable code path of your dependency... Does this "not affected" marker still exist, and now you have vulnerable code? Does it disappear with each version?

What if someone maliciously adds a "not affected" marker? To a package they intend to exploit?

Edit: Again why the heck am I being downvoted?

[TheDong]

> what if one of your contributors slips in a merge that uses the vulnerable code path of your dependency

If your threat model is a contributor submitting malicious code, your problem is not something npm audit will help with either way.

If a malicious actor is able to add the "not affected" marker, you have bigger problems.

The threat model you're talking about neither seems realistic, nor like something npm audit can help with. The attack vector of a contributor sneaking in malicious code is dealt with by only giving the commit bit to trusted people, and reviewing code yourself.

[cphoover]

> The threat model you're talking about neither seems realistic, nor like something npm audit can help with. The attack vector of a contributor sneaking in malicious code is dealt with by only giving the commit bit to trusted people, and reviewing code yourself.

How is this not realistic when it has already been seen in the npm ecosystem multiple times. For an example of this in the wild see the event-stream (crypto-mining trojan) fiasco: https://github.com/dominictarr/event-stream/issues/116

Dependencies are a target for exploit, your package may be safe now and then become unsafe in the future, either intentionally or unintentionally.

[enumjorge]

The problem is, if a security vulnerability snaked past the maintainers of a project, what hope do I have as someone who consumes the package to a) catch it b) know how to fix it?

[nirvdrum]

I don't think anyone should be blindly upgrading anything. Doing so brings about its set of problems and in many cases makes things worse. This is particularly true in the case of Create React App where just upgrading dependencies will often break the application.

The last Create React App I worked on (~3 months ago) had over 500 "vulnerabilities" reported by npm/yarn audit. Most of the reported vulnerabilities were obviously junk. As the author noted, there's no need to report vulnerabilities in the same dependency in every path through the dependency graph. The noise made it very difficult to sift through the output for anything useful. Even then, I have my doubts about how applicable the results are because with tree shaking of an SPA, it's quite possible the vulnerable part of a dependency is never even used.

[city41]

> Just upgrade it to be on the safe side

Upgrading a dependency can go anywhere from trivial to absolute nightmare. Usually somewhere in the middle where it takes time and effort to do right. A typical JS app nowadays has hundreds if not thousands of dependencies. I'd love to see a world where "just upgrade" is reasonable advice, but we are not there.

[mmis1000]

Or even undoable because it is a dependency of dependency, that vulnerable major version is no longer maintained, and your dependency heavily relies on specific feature of that major version.

At this point, what should you do now?

The author of dependency of dependency is probably not going to touch it because it is fixed in the new major version. The author of dependency is probably also not going to fix it instantly because it requires major rewrite.

[glotgizmo]

Fork the repo and fix it yourself, ideally basing the change off the fix on the new major version if possible.

Yes, you now don't get vuln. notifications for the original repo, which is an issue in itself. It would be nice to mark a CVE as mitigated in your package.json and to also mark a resolution to still pick up CVEs from the original package. E.g

{

  "dependencies": {
    badRepo: "1.0.0" // has a dependency that is vulnerable
  },

  "resolutions": {
    "badRepo/**/dependency": "git://github.com/org/dependency" // fixed, but now won't report new cves from the original badRepo/**/dependency package. Would be good to specify that we still want reports for the original repo

}

That is how we handle such issues in our team, we also review any forks at the start of every sprint to see if it has been resolved and we can remove the fork dependency.

If the vuln is valid and exploitable in your system, what other choice do you have? It's the pitfalls on depending on 3rd party packages. If you are using an old major version that now has a vuln that is only fixed in a newer version, NPM doesn't make that situation worse.

Caveat: These are my 5 minutes thoughts, I could probably do a better, more thorough write up.

[michaelt]

> Why does it matter if it's absurd in this context?

If I wanted shitty false alarms about bogus security issues, I'd get a PCI-DSS audit.

[alerighi]

Have you ever worked with a complex project? Upgrading isn't easy if you have a moderate number of dependencies, also you risk introducing bugs for fixing a problem that really doesn't impact you. It doesn't make much sense to me...