jeemok / better-npm-audit

The goal of this project is to provide additional features on top of the existing npm audit options

Better NPM Audit

The goal of this project is to provide additional features on top of the existing npm audit options. We hope to encourage more people to do security audits for their projects.

NPM version 6 and 7, and 8

NPM has upgraded to version 7 in late 2020 and has breaking changes on the npm audit. The output of npm audit has significantly changed both in the human-readable and --json output styles. Even more unfortunately, when NPM changed the JSON output in npm v7, they removed many of the other useful identifiers (cves, cwe, github_advisory_id) and the only thing left is the URL. We are trying our best to handle each version and provide consistent functionality to all of them. Related docs on v6 and v7 changes:

Docs	Link
NPM v6 & v7 changes	https://github.blog/2020-10-13-presenting-v7-0-0-of-the-npm-cli/
NPM v7 blog post	https://blog.npmjs.org/post/626173315965468672/npm-v7-series-beta-release-and-semver-major
Official NPM v6 audit docs	https://docs.npmjs.com/cli/v6/commands/npm-audit
Official NPM v7 audit docs	https://docs.npmjs.com/cli/v7/commands/npm-audit
Dealing with new npm audit	https://uko.codes/dealing-with-npm-v7-audit-changes

You may find the sample JSON outputs for each NPM versions in our codebase: v6, v7 & v8.

Installation

$ npm install --save better-npm-audit

or

$ npm install -g better-npm-audit

Usage

Run global

better-npm-audit audit

Run with exceptions

Unhandled or newly reported vulnerabilities will be highlighted:

Unused exceptions will be notified:

Add into package scripts

{
  "scripts": {
    "prepush": "npm run test && npm run audit",
    "audit": "better-npm-audit audit"
  }
}

Now you can run locally or in your CI pipeline:

npm run audit

Options

Flag	Short	Description
--exclude	-x	Exceptions or the vulnerabilities ID(s) to exclude; the ID can be the numeric ID, CVE, CWE or GHSA ID
--module-ignore	-m	Names of modules to exclude
--level	-l	The minimum audit level to validate; Same as the original --audit-level flag
--production	-p	Skip checking the devDependencies
--registry	-r	The npm registry url to use

Environment Variables

Variable	Description
NPM_CONFIG_AUDIT_LEVEL	Used in setting the audit level. Note: this will be disregard if the audit level flag is passed onto the command.

Using .nsprc file to manage exceptions

You may add a file .nsprc to your project root directory to manage the exceptions. For example:

{
  "1337": {
    "active": true,
    "notes": "Ignored since we don't use xxx method",
    "expiry": 1615462134681
  },
  "4501": {
    "active": false,
    "notes": "Ignored since we don't use xxx method"
  },
  "CWE-471": "CWE ID is acceptable",
  "GHSA-ww39-953v-wcq6": "GHSA ID is acceptable",
  "https://npmjs.com/advisories/1213": "Full or partial URL is acceptable too"
}

Fields

Attribute	Type	Description	Default	Examples
active	Boolean	If the tool should use it for exception	true	true
expiry	String | Number	Human-readable date, or milliseconds since the UNIX Epoch		- '2020-01-31' - '2020/01/31' - '01/31/2021, 11:03:58' - '1 March 2016 15:00' - '1 March 2016 3:00 pm' - '2012-01-26T13:51:50.417-07:00' - 'Sun, 11 Jul 2021 03:03:13 GMT' - 'Thu Jan 26 2017 11:00:00 GMT+1100 (Australian Eastern Daylight Time)' - 327611110417
notes	String	Notes related to the vulnerability.

When using a .nsprc file, a report will be displayed when it starts running:

Note: the expiry date will be styled in yellow and red color if it is detected more than one or five years ago.

Changelog

You can find the changelog here.

Contributors

Ian Wright, Edwin Taylor, Maarten Hus, Alex Burkowsky, David M. Lee, Kyle Clark, Guillermo Pincay, Grzegorz Pawłowski, CSLTech, Paul Clarkin, mgdodge, Ricky Sullivan, Sam Gregory, Tristan WAGNER, Zak

---

If you like this project,

better-npm-audit's Issues

Does not work with npm 7

I have an old project that has known vulnerabilities right now (35 low, 4 moderate, 8 high). Running better-npm-audit, I would expect it to throw an error, but it does not. The screen output shows the result of the npm audit, with "All good!" at the end. This is a really, really big problem.

It seems that the latest version includes the following code, which essentially creates an empty object when the npm audit doesn't return an advisories object:

const { advisories } = JSON.parse(jsonBuffer);

// Grab any un-filtered vunerablities at the appropriate level
const vulnerabilities = Object.values(advisories || {})

The json format of npm 7 changed drastically, and this change is entirely insufficient to handle the new format. This article explains the changes.

In its current state, better-npm-audit is returning a false result for anyone using npm 7, and is essentially useless. NPM really threw a lot of these audit utilities a curve ball with the change to the npm audit json format.

Other output formatting issues

When there are vulnerabilities found, the code does:

process.exit(1);

which causes output like this:

2 vulnerabilities found. Node security advisories: ####,####
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! ########## audit: `node node_modules/better-npm-audit audit`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the ############# audit script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     ##################/.npm/_logs/2021-05-20T13_48_02_404Z-debug.log

(with the hashes being my redactions). The pull request said that it now exits "cleanly", so I'm wondering if my npm or terminal config is incorrect.

Similarly, I'm getting output like this:

┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Moderate      │ Regular Expression Denial of Service                         │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       
0m│ ############                                                      │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Patched in    │ >=######                                                     │
├───────────────┼──────────────────────────────────────────────────────────────┤

(with the hashes redacting the package name and version number), which suggests there is some problem with the buffering of the long output still. The 0m appears to be in a light grey text colour, but other than that I'm not getting any colours in the output.

I hope this is a valid issue, and I apologise for reporting so many in this fantastic package!

(Add option to) remove vulnerabilities below specified level in the table

While running

better-npm-audit audit --level "high"

leads to a different output at the end (e.g. "12 vulnerabilities found") versus

better-npm-audit audit

(e.g. "25 vulnerabilities found"), all vulnerabilities with a severity/level below "high" are still present in the displayed table.

So I'd like (an option) to get the table with only the level specified (and higher).

Start maintaining a changelog or adding tags for releases

… so it's faster to get a glance of what's new :)

Even only tags would help to (faster) compare versions via the commit history.

Add option to skip over optional dependencies

By adding the --production flag, the audit will ignore any dev dependencies already. I have some dependencies that are marked as optional (like Cypress) that for ~ reasons ~ can't live in the dev dependencies.

Is there already, or would it be possible to add an option to not only ignore the dev dependencies, but also the optional ones?

Missing [ in truncation message

Just another small issue while I'm reporting things. I get output like this:

...
├───────────────┼──────────────────────────────────────────────────────────────┤



MAXIMUM EXCEEDED] Logs exceeded the maximum length limit. Add the flag `-f` to see the full audit logs.
...

From the code, it looks like there should be a [ at the start of the line, which would look nicer. I'm not sure what is swallowing that.

Weird formatting in table and handling of \n

As mentioned in discussion #53, the npm audit security report table sometimes has unexpected spaces and missing letters. For example, a package with a dependency on ansi-regex (version 3.0.0 or similar) can cause the table to include this value in the Title column:

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

This is for an Ex.cluded vulnerability, so it appears as black text on a white background in a terminal with a light theme. In particular, this is MacOS Terminal Version 2.11 (440).

README doesn't fully document "expiry"

In the Fields section of the README.md file, the Description text for the expiry row lists only UNIX timestamp, and probably needs to say Human-readable date, or milliseconds since the UNIX Epoch instead.

Actually I think it would be better to support seconds rather than milliseconds (since no one will be specifying a value more precise than 1 second, and I think most online tools use seconds since that is the definition used for UNIX time), so it might be better to say seconds since instead.

As this would be a backwards compatibility break, it's probably better to only document seconds but still detect and support milliseconds.

Audit should provide info if it affects dev dependency or production

Really like the package. The only thing that kind of bothers me that running the audit doesn't show you if it affects a dev dependency or a production dependency. When running the audit it would be great to have a separate column that indicates if the found vulnerability only affects a dev dependency or also a production dependency.
This makes it easier to decide if it should be excluded e.g. high severity on dev dependency is probably not as problematic as on production dependencies.

Json parse failure messages are misleading under some circumstances.

When an error occurs parsing the json from npm audit result while running better-npm-audit audit, the error message is:

Failed parsing .nsprc file: SyntaxError: Unexpected end of JSON input

Unable to process the JSON buffer string.

regardless of whether there is a .nsprc file.

The offending line is:

better-npm-audit/src/utils/common.ts

Line 23 in 0b7259f

console.log('Failed parsing .nsprc file: ' + e);

Support for the --audit-level flag passing to npm audit

It would be nice to only consider vulnerabilities after a given level.

Provide more output when parsing exceptions file

I really appreciate the ability to specify an expiry time for exceptions, but I must admit it took me a few attempts to realise that I had specified the timestamp in seconds rather than milliseconds. Unfortunately the README doesn't make this clear, and nor is there any indication in the output of the audit that an invalid expiry time has been specified.

Fixing those would be really helpful, as would having a mode which just validates the contents of the exceptions file. For example, it could confirm that the file has been found, is valid JSON, has valid timestamps, and that the ignore parameters are present.

More generally, the names related to this file are a little ambiguous:

1. There is the potential for confusion when using the word "exception" in a JavaScript context, when "exclusion" might be clearer.
2. The parameter ignore doesn't make it clear whether the tool is being instructed to ignore a vulnerability or to ignore the exclusion of that vulnerability. The README doesn't make it any clearer, since it gives examples of exclusions with ignore set to true and false respectively, and both have a reason starting with "Ignored".
3. When exceptions are specified on the command line, the --ignore flag is used. It might be better to name this flag --exclude, and use -x for short. The noun and verb pair exclusion/exclude are more clear than exception/ignore, or any alternative like exception/except or ignorance/ignore.

Again I hope that these suggestions are seen as constructive, so that more people can enjoy this great software.

[Feature Request] Ignore by module name

It would be great to have a cli flag to ignore a module name like lodash rather than dealing with the recurring ID's that pop up for it. Thanks for all the great work on this tool!

Brought on by the ever changing ids linked to the unaddressed disputed lodash issue:

A found vulnerability results in "throw new Error(message)"

Thanks for this excellent npm package. I was slightly surprised, though, that when a vulnerability is found by the audit, the output includes 20 lines more than the usual npm audit, including a stacktrace and npm denying all responsibility with its This is probably not a problem with npm. message.

There are times when throwing exceptions is the right way to control code flow, but the user experience here doesn't seem to be better than that of the original npm audit feature, which exits more cleanly. Also, if an audit tool correctly discovers that there are vulnerabilities in a project then arguably that should be treated as a success, although I understand that the purpose of this check is often to prevent a build pipeline from continuing, so it makes sense to provide an exit status which reflects that.

Hopefully you don't mind if I make an additional unimportant observation here, which is that line 11 of /index.js is missing a semicolon, unlike the lines around it. Perhaps you would consider including some sort of linting step to accompany your impressive testing procedure.

JSON output

Will there be an option to display the audit results in JSON format?

Using --full doesn't print the raw logs when an error is encountered

The flag --full, described as "Display full report", only prints the full report when no vulnerability is found. However, this flag should print the full report in both cases.

Normal usage without --full (-f):

Command: node node_modules/better-npm-audit audit

Using --full (-f):

Command: node node_modules/better-npm-audit audit -f

Adding -i to ignore the vulnerability (and hence get a "success" response):

Command: node node_modules/better-npm-audit audit -f -i 1523

The reason this isn't happening is because of the following code section:

better-npm-audit/index.js

Lines 107 to 113 in fc42a2b

	if (vulnerabilities.length > 0) {
	const message = `${vulnerabilities.length} vulnerabilities found. Node security advisories: ${vulnerabilities}`;
	throw new Error(message);
	} else {
	// Let's display the audit log instead
	auditLog(auditCommand, fullLog);
	}

It can be fixed by taking the auditLog() call outside of the if condition.

.nsprc seems to ignore exceptions when advisories have fields

having an .nsprc with the following format:

{ "1002373": "some notes" }

works. When I run it the first thing I see is the advisory that the exception is in effect.

> better-npm-audit audit -p

Exception vulnerabilities ID(s): 1002373
[production mode enabled]
...

If I add fields then the exception is ignored.

Tried the following :

{
  "1002373": {
    "notes": "some note"
  }
}

{
  "1002373": {
    "active": true,
    "notes": "some note"
  }
}

{
  "1002373": {
    "active": true,
    "notes": "some note",
    "expiry": "2022-01-01"
  }
}

They all have the following output:

> better-npm-audit audit -p

[production mode enabled]
# npm audit report

lodash  *
Severity: critical
Arbitrary code execution in lodash - https://github.com/advisories/GHSA-8p5q-j9m2-g8wr
No fix available
node_modules/lodash
  formik  >=1.4.0-0
  Depends on vulnerable versions of lodash
  node_modules/formik
    poc-1  *
    Depends on vulnerable versions of formik
    node_modules/poc-1
    poc-2 *
    Depends on vulnerable versions of formik
    node_modules/poc-2
  yup  <=0.5.1 || 0.19.0 - 1.0.0-alpha.1
  Depends on vulnerable versions of lodash
  node_modules/poc-2/node_modules/yup
  node_modules/yup

5 critical severity vulnerabilities

To address issues that do not require attention, run:
  npm audit fix

Some issues need review, and may require choosing
a different dependency.

1 vulnerabilities found. Node security advisories: 1002373

node version: v14.18.0
npm version: 7.24.2

Support for YAML in .nsprc

It would be nice to be able to use YAML in .nsprc config file.

Weird wording in "It can be removed" message

I've just been updating some dependencies of a project I'm working on, and an npm run audit produced this message before the All good!:

2 of the excluded vulnerabilities did not match any of the found vulnerabilities: 1064653, 1064843. They can be removed from the .nsprc file or --exclude -x flags. 1 of the ignored modules did not match any of the found vulnerabilites: . It can be removed from the --module-ignore -m flags.

There are two problems with this:

• It looks like a (one element) list is missing in the text any of the found vulnerabilites: .
• The word vulnerabilites should be vulnerabilities (which has the correct spelling the other two times it occurs).

Sorry for reporting these minor issues in this fantastic software, but hopefully they are easy fixes. 😄

IDs on the exception list missing from "audit" output

Thanks for the great version 1.9.1 update. I've installed it and run the audit again, but there seems to have been a small regression with the output. Here is a section from the audit report:

> node node_modules/better-npm-audit audit

Exception vulnerabilities ID(s): 
                                                                                
                       === npm audit security report ===

My guess is that consoleUtil on line 135:

consoleUtil.info('Exception vulnerabilities ID(s): ', exceptionIds);

does not work the way console did.

Support level being passed in as an environment variable

Hi,

I'd find it really useful if the level option could be passed in as an environment variable, as it can be to the native npm audit command via NPM_CONFIG_AUDIT_LEVEL environment variable. This would allow for setting a global audit level across all of our CI pipeline builds, some of which use 'npm audit' and some of which use 'better-npm-audit audit'.

Would you consider a PR which would set a default value for level as a fourth parameter here

better-npm-audit/index.js

Line 173 in 7ad4a72

.option('-l, --level <auditLevel>', 'The minimum audit level to validate.')

, taking the value from process.env.NPM_CONFIG_AUDIT_LEVEL?

Cheers

Ignore all vulnerabilities from dependencies installed by given package

Using the option -m can only ignore vulnerabilities in a specific package. It would be nice if we could ignore a whole package and it's child dependencies (packages installed by it). I believe this could be included in the same -m option.

So for example if I have node-sass installed, and it brings node-forge and trim-newlines with security vulnerabilities, -m node-sass would ignore both. But on the other hand if I also have package-x that also installs node-forge then it doesn't.

Context: in certain cases the split between production and non dev only packages is used for other purposes. Like for example installing less packages in certain pipelines (frontend web targeted only projects do this). So using only --production doesn't cover this case.

Hide excepted vulnerabilities from output

I've had another UX idea which you might like to consider.

Given that the output is often very long and has to be truncated, I think it would be nice to remove the little ASCII art cards/tables for vulnerabilities that are in the exceptions list. That way, the output would just be the list of exceptions and the "All good!" message if all vulnerabilities have been dealt with.

I suppose someone might like to see the (truncated) list of exceptions to give them some reassurance that the exceptions list is still having an effect, but if they use the expiry option then the exceptions should eventually become stale anyway. I will add that as another suggestion to Issue #20.

Report when the .nsprc file is present but not (valid) JSON

While testing the latest version, I made a small mistake when updating the .nsprc file which meant the file was no longer valid JSON. It only took me a moment to realise why none of the exclusions were being applied, but a beginner might be more confused (especially if they are using an editor which doesn't warn them about JSON validity issues in their files).

Hopefully it's a small change to catch the specific case of an invalid JSON file, and output a specific human-readable error message to the user.

Target specific package versions in --module-ignore

It would be very handy for us if we could target specific package versions in the --module-ignore flag so that we don't have to come back and manually update our whitelists once we update problematic package versions. For example:

1. We have included package_A v1.2.3.
2. better-npm-audit audit -l high fails because of an issue with a subpackage of package_A v1.2.3.
3. We exclude it using better-npm-audit audit -l high -m package_A
4. Later, we update package_A to v1.2.4.
5. A new advisory is created for a package_A v1.2.4, but our audits continue to pass because we excluded package_A in our pipeline.

Process keeps hanging on Windows 10

The process keeps hanging in a happy flow (when there are no issues reported). I think this is because the buffer doesn't close properly on Windows due to not properly listing to the kill signal of the child process.

This can be fixed by adding process.exit(0) after https://github.com/jeemok/better-npm-audit/blob/master/src/handlers/handleFinish.ts#L49

Use new GitHub CVE ID

Hi @jeemok

Now that the NPM vulnerabilities advisory have been migrated to GitHub, the vulnerabilities identifier has changed. Vulnerabilities are now identified by a CVE ID that is an alphanumeric code, as you can see in this example Prototype Pollution in set-value.

I'm opening this issue so we can use the CVE ID in the list of ignored vulnerabilities instead of the long numeric value that is being used at the moment (i.e., 1002401) and that it's not identifiable when opening the advisory report on GitHub.

By the way, the recent updates on the package look great! Otsukaresama!

Audit not executing if github url present in package.json

Hi,

If in package.json github url is included then better-npm-audit throwing below error, any way is it possible to handle this scenario.

package.json
{ "name": "my application", "version": "1.0.0", "description": "Application", "main": "app.js", "scripts": { "start": "node app.js" }, "license": "UNLICENSED", "dependencies": { "body-parser": "^1.19.0", "compression": "^1.7.4", "config": "^3.3.7", "express": "^4.16.3", "request": "git+https://github.com/Sujay-shetty/request.git", "request-promise": "^4.2.2", "swagger-ui-express": "^4.4.0", "uuid": "^7.0.0" }, "devDependencies": { "@types/request-promise": "^4.1.46", "ts-node": "^8.9.1", "typescript": "^3.4.5" } }

Error :

Could you please help me how to skip audit for github url or any custom url if it is present in package.json

Thanks,
Sujay

Option to save ignored vulnerabilities.

Right now if we are using a package that has a vulnerability in a method that we don't use, we can choose to ignore the specific vulnerability with -i flag. If we want to make this permanent (to pass CI/CD pipelines for example) then we can add this to the npm script in package.json.

I think it would be better if there is an option to save ignored vulnerabilities to a separate file and read them each time a scan is run. An nice option would also be to have an optional comment saved per ignored vulnerability ie

{
  "1337": "Ignored since we don't use xxx method"
}

Node version 14.17.0 is not supported

The better-npm-audit does not work with the most recent Nodejs version. I am using version 14.17.0 and it throws an exception. I think it is because this version of Node has a breaking change in the way the npm audit command returns the results.

Below is the error message from the exception.

const vulnerabilities = Object.values(advisories)
^

TypeError: Cannot convert undefined or null to object
    at Function.values (<anonymous>)
    at Socket.<anonymous> (/Users/guillermo.pincay/Documents/bamboo-plus-api/node_modules/better-npm-audit/index.js:103:36)
    at Socket.emit (events.js:388:22)
    at Pipe.<anonymous> (net.js:673:12)

DeprecationWarning: Invalid 'main' field in ... node_modules/better-npm-audit/package.json' of 'lib/index.js'

I recently upgraded to [email protected] (and [email protected]) and I'm getting the message:

(node:74559) [DEP0128] DeprecationWarning: Invalid 'main' field in '[REDACTED]/node_modules/better-npm-audit/package.json' of 'lib/index.js'. Please either fix that or report it to the module author

when running npm run audit. Presumably that's because the index.js file is actually at the top level of the package's directory tree, and not in a lib directory. The tool still seems to function, but hopefully this is an easy fix.

Add an option to remove colors

Just a feature request, if it's possible, could you add an option to remove the ANSI colors of the output? I would like to save the output to a file without the need of using sed command with regular expressions that are not so regular for any OS and the command also is not always available on Windows.

Thanks for your work, this library has been very helpful to me as a Security reviewer.

Check for .nsprc files in dependencies

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

Support non-milli Unix timestamps

I've had another idea that I think might make this tool even more convenient. The idea actually occurred to me when I made a mistake in copy-pasting a timestamp from an online converter into the .nsprc config file, so I think other users may encounter the same problem, but I'm happy to report that the list of exceptions table helped me to work out what I did wrong, so this is not a major issue.

Basically, the expiry field in the config file requires a Unix timestamp in milliseconds, and I think the tool should detect dates before 1971 and interpret them as Unix timestamps in seconds. Even better would be to support other formats for the expiry field, such as YYYY-MM-DD date strings, and any other format that isn't ambiguous and doesn't complicate the parsing logic too much.

As a related aesthetic/usability change, you might want to style the expired text as yellow if the expiry date was less than a year ago, and red if it was much longer, as that might suggest the user has made a mistake. Similarly, for expiry dates in the future, it might be worth styling the active text as yellow if the date is more than 5(?) years in the future, as that sort of defeats the point of having an expiry at all and again could be due to a typo.

Show skip reason on output

Hi there,

First of all, I have to say that you guys are doing a good job with this lib!

Then, here's my question:

There's a way to show the ignore reason of each vulnerabilities as we show the advisories id?

Thank you guys!

execution is breaking when stdout returns a string with first character as number

I observed this today while running better-npm-audit, while reading stdout for npm audit command in index.js, if ids are set to something like "0m│http,npmj,1012,http,npmj,1012,http,npmj,1012", then it breaks the execution as following code in index.js returns "[ '0m│\u001b' ]"

const numberIds = ids.map(id => { if (isNaN(parseInt(id, 10))) { return null; } return id; }).filter(Boolean);

Support the --production flag

It would be helpful if this supported some of the other commands such as the production flag that NPM supports.

Recommended "--omit=dev" option not found for NPM 8

Description
When using NPM version >= 8 the --omit=dev option is not passed through.

Running the command better-npm-audit audit -p results in a warning by NPM advising you to use --omit=dev instead.

$ better-npm-audit audit -p
npm
 WARN config production Use `--omit=dev` instead.

However, when running said command better-npm-audit audit --omit=dev an error is spat out:

$ better-npm-audit audit --omit=dev
error: unknown option '--omit=dev'

Adding the option to better-npm-audit might be beneficial as currently it's producing warnings, but keeping the other option in for older NPM versions. Another solution could be to forward the -p option to execute --omit=dev for NPM 8.

Running npm audit --omit=dev works like a charm.

Context
NPM version: 8.13.2
Node version: v16.15.1
Better NPM Audit version (through NPM): 3.7.3
Architecture: Aarch64

[Suggestion] Add path to modules with reported vulnerability in the new UI

Hi!

First of all, the new interface to the tool is great. It's so much more cleaner to go through now.

Would it be possible to show the path to the module with the reported vulnerability in the new UI?

Here's a example output:

(I'm using npm v6 with node 14 right now)

This is from a frontend repo and all the dependencies mentioned here are nested dependencies of react-scripts

The tar module for example is used here react-scripts > terser-webpack-plugin > cacache > tar

Being able to see the module path would make it easier to figure out if we need to prioritize fixing this or ignoring it if it doesn't fit our use-case.

Right now, I have to run npm audit again after looking at the UI.

Also, I understand that a package may have more than one path, particularly when there are vulnerabilities in packages used by a lot of other packages. Maybe it can be present in the following manner:

react-scripts > terser-webpack-plugin > cacache > tar
react-scripts > some_other_path > tar
and 4 others

I'll be happy to contribute to an MR for this as well if it's possible with npm.
Please let me know, thanks!