[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?

[cphoover]

That's exactly the issue that npm-audit seeks to ameliorate. It's not perfect, but it's better than nothing.