jeemok/better-npm-audit

Check for .nsprc files in dependencies

alert-debug opened this issue · 2 comments

I don't know if the tool already does this, but it would be really great for the ecosystem if the maintainers of popular packages could include an .nsprc file in the packages they distribute. I'm imagining a situation where a package has a dependency on another packages which has a vulnerability reported against it, but the parent package isn't in practice exploitable because it doesn't use the affected code path.

The tool would have to look at the dependency chain from the top level project down to the vulnerable package, and check all the relevant subdirectories of node_modules for an .nsprc file covering that vulnerability. However, it might not be possible to extract the necessary information from the vanilla npm audit output, and we don't want excluded vulnerabilities from one package to influence the determination of validity of that vulnerability in another package, so this will require some careful consideration of edge cases.

(By the way, I'm a little surprised that you've already closed the other ticket I filed this month, and limited conversation on it. If someone else came up with the same idea, they wouldn't be able to find my ticket by doing a search of the open Issues, and even if they did find it, they wouldn't be able to make improvement suggestions because of the restriction on commenting. Nevertheless, I do trust you that you won't forget about that ticket, and I look forward to trying the next update whenever it is released).

I think that is a great initiative we could start here, it shouldn't be a problem to look through the dependencies chain for the .nsprc file and notes left by the maintainers; but you are right about the issue on how should we determine the validity of a reported vulnerability?

Perhaps we could start by simply checking if there is any .nsprc file managed by the package and display the information as references? then we will see how it goes and expand the feature.

The other issue that you raised; I have moved it over to the discussion board, I think that is a better place built for discussion rather than treating it as an "issue".

(Side note: I'm actually working on the next release now and should be ready this weekend! The newer features will be built on top of that new version, stay tuned!)

Yes, it would be good to see what sort of information the tool can find in the .nsprc files of a project's dependencies.

The only danger I can imagine is a situation where someone is maintaining package A, which has dependency chains A->B->C and A->D->C, and the developer of B has correctly indicated in B's .nsprc that the vulnerability in C doesn't affect B, but D still is affected by vulnerable dependency C, so we don't want B's .npsrc to mute the warning which applies to D.

(So it's not as simple as just taking the union of all .nsprc files and applying that combined list to all the vulnerabilities found. I hope I'm explaining this clearly.)