It’s not a false positive, as described. It’s “mitigated by environment”. The vulnerability is real. The severity is arguably too high.

People throw around “false positive” as a catch-all for “I don’t care about this”. But there are a number of distinct reasons one might not care:

- the scanner is wrong (e.g. there’s a code bug in the scanner like detecting “printed” instead of “sprintf”.

- the output is wrong because the vulnerability isn’t a vulnerability anytime, anywhere under any circumstances

- the scanner is correct, but environment or mitigation’s mean it doesn’t apply to me or the severity is wrong in my environment (this is the case here)

- the scanner is correct, but is giving me output I don’t care about (eg I want to filter for only high/critical but I can’t)

- there is so much output that I can’t pay attention to all of it; it’s so overwhelming that I can’t stand to look at it

Many security products have problems with output that is too verbose. This seems like a trivial problem to work around here; after you’ve triaged that a particular vulnerability doesn’t apply to a particular project, then filter it out with grep -v (our put a bunch of such lines in a bash script and always pipe npm audit output to the script.

Also, I sympathize with concerns that the vulnerability reporter perhaps scored the vulnerability too high. But there’s no perfect solution for that, and I’d rather be aware of a vuln and choose to ignore it, than not be aware at all.