monorepo-symlink-test GHSA-2jcg-qqmg-46q6 Vulnerability

[castafab]

Hi , using the grype Scan Vulnerabilities tool was possible to detect a vulnerability in one of the dependencies that are used by you.

That dependency is in a package.json file inside of the rest->resolver->multirepo->package.json in the node_module from the resolve library.

This dependency that contains the vulnerability is the monorepo-symlink-test which was also already removed from the npm library (https://www.npmjs.com/search?q=symlink-test) you can check the readme on that page that was removed because contains malicious code.

Do you have some predictions to remove this dependency from your list of dependencies?

[mferreira3]

I'm having the same issue, would be glad if someone could take a look on this considering the severity of it 😕

[ljharb]

This is not a vulnerability, full stop. This is test code that is never used in production.

In fact, this package isn't even the same package as monorepo-symlink-test, that's just what i named it - it has private: true so it can't even be published.

So, your vulnerability scanner has broken heuristics, and I wouldn't trust its results.

Duplicate of #288. Duplicate of #291.

[saintmalik]

i think this a false positive scan result from the grype scanner

[ljharb]

Yes, it absolutely is, and it should give you serious pause about relying on that scanner.

[mfrye-aisera]

We just were alerted about this as well. I'm not sure which scanner found this, but it was passed around the company until this landed in my inbox.

I reviewed the other issues and understand the background here. If it's just the module name, maybe it would be good to change it to avoid any confusion. Otherwise, this will probably be a non-stop stream of enterprises that discover this and want to know what's going on.

[ljharb]

@mfrye-aisera i could, but then people wouldn't discover that their "security scanner" fails to understand the semantics of the ecosystem it's trying to secure.

[mfrye-aisera]

@ljharb totally agree. I'm not a fan of our security scanner as I've already it found that it missed other more important stuff. I've already flagged this internally as not an issue, so I think we're good here.

My comment was more for you, as I assume you're going to be continually annoyed with requests about this as orgs slowly discover the issue. So the easiest fix is to just change the name of the module, right?

[ljharb]

thanks, i appreciate your concern :-) i'll keep it this way for the time being, but certainly would rename it if it ever exceeds my tolerance for such things.