Check for .nsprc files in dependencies

[alert-debug]

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).

[jeemok]

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!)

[alert-debug]

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.)

[alert-debug]

To provide some more context, you might be interested to read about a discussion in the React community titled "Help, npm audit says I have a vulnerability in react-scripts!" (issue 11174 of the Create React App repo).

I won't link directly to the issue from here, as it might not be the right time to bring their attention to better-npm-audit yet, but it does seem like there is widespread demand for a tool that lets developers confirm that a specific vulnerability in one of their dependencies doesn't in practice make their package vulnerable.

Once you've implemented a full version the feature request discussed above, you could offer this package as a solution, or I would be happy to mention it on your behalf, as a positive review from a satisfied user. 😄

[jeemok]

hey @alertme-edwin, thought of updating you here quickly, apologies for the delay in further developing this, I got some urgencies in another project that needed to be done, so will get back to this as soon as I finished that, I think you have mentioned some really good points above.

Glad that you were able to test the new version!

didn't cover the package better-npm-audit, which also has a dependency on a vulnerable version of glob-parent

I think I must have committed that into the dependencies list by mistake, thanks for pointing it out! hmm... the current package vulnerability should be included as well, I'll double-check it. 🕵🏻

it should look in ./node_modules/react-dev-utils/.nsprc

yeah, I realized that too when building the auto-scanning, but I remember the npm ls should give us the path of the installed package correctly? let me test that again (hopefully, it will work out smoothly 🤞🏻)

the \n literals in the npm audit security report table sometimes

I couldn't reproduce it on my side so far so didn't actually fix it. Let me try it with other terminals to see if I can spot anything anomaly. Do you mind sharing the details of your terminal/vulnerability details?

Enable Dependabot alerts in the Security tab of this repo

I have enabled them in this repo, but it didn't create any alert/PR for the vulnerability 🤔 I do receive some alerts for my other repos from time to time though...

display these as a list by using a bullet point symbol at the start of each chain

You mean under debug mode right? initially, I tried not to put all the paths into the report as some popular or common package might be used by many other package hence the report will get really really long. I think it is a good idea to style and organizing the scan paths well, will definitely help the one that trying to understand the process and investigate any issues 👍🏻 this could probably be an enhancement later instead of a blocker now to release v4 imo.

Will look into them soon and get back to you! Do let me know if there's anything that comes to your mind in the meantime!

[alert-debug]

Hi @jeemok, thanks for the update! It's completely understandable that you have other commitments, and I'm just grateful to have your feedback on my previous comment.

npm ls should give us the path of the installed package correctly?

I ran npm ls browserslist and it correctly shows the dependency tree leading to browserslist@4.14.2, but you're right to point out that the path to the installed package isn't necessarily inferable from that output if there are multiple versions of the same package installed. In this case, I think better-npm-audit is looking in:
node_modules/react-scripts/node_modules/react-dev-utils/node_modules/browserslist
instead of:
node_modules/react-dev-utils/node_modules/browserslist
which might partially explain why it is not picking up the .nsprc file I added to:
node_modules/react-dev-utils

This would probably be less confusing to me if I had actually studied the algorithms and APIs that NPM uses, but hopefully the information I am providing you is still useful. I really think that, long term, this project needs a suite of integration tests which install packages with known vulnerabilities, and add .nsprc files in specific locations, and check that they are found (or skipped) appropriately. That will be invaluable for finding regressions (especially if NPM changes the way audits work in a later version), but for now I think it is just worth keeping track of any edge cases we find.

Do you mind sharing the details of your terminal/vulnerability details?

I think it's safe to say that one scenario where I detected this \n literal issue is when looking at the row for vulnerability 1751 in glob-parent in Apple Terminal Version 2.11 (440). For what it's worth, when I run $ echo -e "a\nb" I see the expected result:

a
b

I have enabled them in this repo, but it didn't create any alert/PR for the vulnerability

I'm glad the alerts are enabled, but I'm surprised that it didn't warn you that better-npm-audit@4.0.0-rc.2 has a dependency on the vulnerable glob-parent@3.1.0. Another way to check it is to look at the advisory page specific to that vulnerability, which should have a tab for "Dependabot alerts" relevant to projects you are part of.

You mean under debug mode right?

It would be nice to eventually add some more structure to the debug output, but I actually meant the Paths column in the default npm audit security report table. Actually, having thought about it some more, I'm wondering if that table (and the auto exclusion scan report table beneath it) are too wide for a reasonable terminal interface. Perhaps the NPM devs were right to split the audit output into separate tables for each vulnerability (even though that sort of defeats the purpose of having a table). UI design is a very specific skill, and somewhat subjective, so I agree that it is best to leave the layout changes for a later update. If we keep it in the back of our minds as we keep using v4, then maybe we'll have some inspiration for an even nicer design at some point.

Let me know when there's a new version to test, and I'll update you if I can think of anything else that would benefit the release of v4.

[jeemok]

hey @alertme-edwin, small updates on the \n bug, I tested with Terminal Version 2.10 (433) and still couldn't see what you see

maybe it's worth creating a new issue for this separately to keep track

---

the path to the installed package isn't necessarily inferable from that output if there are multiple versions of the same package installed.

regarding this I think I have an idea on how to implement this already:

• using npm ls {reported_vul}@{vul_version} --json to get the dependencies/modules
• for each of the module, use npm ls {module}@{module_version} --parseable to get its installed path and check if .nsprc file exists

but I actually meant the Paths column in the default npm audit security report table.

thanks for clarifying, glad that I asked! You're right about the debug mode output being a little messy, I'll look into that too 👍🏻

[alert-debug]

Hi @jeemok. Thanks so much for trying to reproduce the \n issue like that, and providing such a clear screenshot. As mentioned, though, "It seems to only occur ... when that vulnerability has been auto-excluded.", i.e. when the text is black/white/default. (For what it's worth, my terminal is in "light mode", so the background colour is white). I've never seen the literal \n when the text is yellow/amber, which makes this a very peculiar bug. If you still can't reproduce it then don't worry, I'll file a bug when the new version is released.

regarding this I think I have an idea on how to implement this already

That's really smart, and I hope it means that your code can find out all the package data it needs without encountering any ambiguities.

You're right about the debug mode output being a little messy

Debug information doesn't have to look pretty, of course, but if it's possible to make any part of the output easier to read, then that's worth considering as an eventual goal.

[alert-debug]

@jeemok Thanks for version 3.4.0, by the way, I've only just seen it. I've also just seen another quirk in the text layout for the npm audit security report. For a project with the package ansi-regex as a dependency, the tool detects vulnerability GHSA-93q8-gq69-wqmw, and (whether or not you have an exception for it) the Title field in the table says:

|  Inefficient Regular Expression Complexity i       |
│ chalk/ansi-regex                                   |

so there seems to be a missing literal n at the end of the first line, and also an unwanted space at the beginning of that line. I hope that turns out to be relevant to the problem of the literal \n appearing in the Paths column.

Sorry to distract you with more small problems, but this software continues to improve and I really appreciate it. Keep up the great work!