--ignoreLow does not ignore low vulnerabilities with Yarn

[Romain Marquant]

Hi,

First, thank you for making npm-audit-resolver available, it's a great tool that I am now setting up on my project.

I just came across an issue using resolve-audit --yarn --ignoreLow. I encountered several low vulnerabilities and got this output:

--------------------------------------------------
 mem needs your attention.

[ low ] Denial of Service
 vulnerable versions <4.0.0 found in:
 - dependencies: jest-cli>jest-runner>jest-runtime>yargs>os-locale>mem
 - dependencies: jest-cli>jest-runtime>yargs>os-locale>mem
 - dependencies: jest-cli>yargs>os-locale>mem
 - dependencies: webpack-cli>yargs>os-locale>mem
 - dependencies: flow-coverage-report>yargs>os-locale>mem
 ✔ automatically ignore low severity issue

 You can ignore permanently or decide to revisit later
--------------------------------------------------

// Other vulnerabilities ..

Unfortunately, they were not ignored as they still appear when I run check-audit. This is currently a problem for me because it makes the 2 different commands inconsistent with one another.

Now, I quickly checked the code and it seems to me that after the output above, resolve-audit should prompt the "ignore" submenu:

 You can ignore permanently or decide to revisit later
_
 M) ignore for a month
 W) ignore for a week
 !) ignore permanently
 s) Skip this
 q) Quit
What would you like to do?

Do you confirm I am correct and this is a bug?
If so, let me know, I'd be more than happy to help !

[Zbyszek Tenerowicz]

Yes, the rewrite to accommodate for yarn broke ignorelow. I intend to bring it back as a rule in a file maybe

[Romain Marquant]

I've had time to check a bit deeper, and came to those lines:

// src/resolve/prompt.js
        if ((argv.ignoreLow || rules.ignoreLowSeverity) && onlyLow) {
            view.printLowSeverityHint()
            return actions.takeAction('i', { action, advisories });
        }

IMHO, the problem lies in the choice argument of action.takeAction. When I dug into git history, I found that 'i' used to mean ignore, but now it means opening a new prompt.
So I think, the fix could be reduced to changing that 'i' to any of the other ignore commands: 'M', 'W', '!'.

There is an underlying question to make this choice: What happens if a "low" vulnerability becomes high, or critical? I see 3 different options:

• The Advisory entry changes its criticity, in this case I would ignore the vulnerability temporarily (say a week)
• If a vulnerability becomes higher, then it has to be a new CVE (and a new Advisory entry), in that case, it is fine to ignore the vulnerability permanently.
• Whatever the answer to this question, the time it is ignored for should be set as a config, either in the audit-resolve.json, or in the ignoreLow argument: --ignoreLow=W

What do you think?

[Zbyszek Tenerowicz]

Honestly? I postponed fixing it because I'm thinking of a set of new options including a way to work with multiple audits for many apps at once and I'm yet to figure it out.

I'd accept a PR fixing the boolean flag to do '!' or 'M' whichever seems more reasonable.
Prefer to avoid magic values for the flag.

[Joe Bowbeer]

By the way, I tried passing --audit-level moderate in v2.2.0 as a replacement for the removed ignoreLow support, but it is not working as I expected. Even though npm audit succeeded (exit: 0), check-audit failed:

$ check-audit --audit-level moderate
>>>> npm audit --json --audit-level moderate
>>>> exit: 0
Total of 1 actions to process
--------------------------------------------------
[low] Regular Expression Denial of Service
 - dependencies: gulp-watch>anymatch>micromatch>braces
 -  devDependencies (optional): babel-cli>chokidar>anymatch>micromatch>braces
--------------------------------------------------
 😱   Unresolved issues found!
--------------------------------------------------
$ echo $?
1

[Zbyszek Tenerowicz]

Let's close this one and open new then.

I'm surprised it worked that way. It doesn't make sense to me. Flags were passed and exit code is correct. Result should also be empty.

Thanks for finding this! Please share package-lock.json that you used.