Avoiding vulnerable indirect dependency with yarn

Question

I am a Rails dev, and somewhat new to JS dependency management. I manage JS dependencies with yarn/webpacker, although I don't think there's anything webpack/webpacker-specific about this question.

Recently Github alerted me to a vulnerability it found in my yarn dependencies for a GH repo.

Upgrade lodash to version 4.17.13 or later. For example:
   lodash@^4.17.13:
      version "4.17.13"

(CVE-2019-10744)

I don't have lodash as a direct dependency, it's not mentioned in my package.json.

Rather it is an indirect/transitive dependency -- some of my dependencies (or their dependencies) depend on lodash. Actually several of them.

My yarn.lock contains this:

"lodash@>=3.5 <5", lodash@^4.0.0, lodash@^4.17.11, lodash@^4.17.4, lodash@~4.17.10:
  version "4.17.11"
  resolved "https://registry.yarnpkg.com/lodash/-/lodash-4.17.11.tgz#b39ea6229ef607ecd89e2c8df12536891cac9b8d"
  integrity sha512-cQKh8igo5QUhZ7lg38DYWAxMvjSAKG0A8wGSVimP07SIUEK2UO+arSRKbRZWtelMtN5V0Hkwh5ryOto/SshYIg==

Which I think means there are 5 things in my dependency tree that want lodash. One of them allows lodash 3.5 and 4.x, the other four allow various ranges of 4.x.

I think they all would allow 4.17.13 without a conflict, but none require it.

And indeed the currently used lodash is 4.17.11, which is less than 4.17.13, and thus according to github (and the CVE), a vulnerable version.

I'm confused about the correct way to deal with this, and upgrade my lodash.

Manually adding lodash to my package.json just seems wrong to me -- it's not actually a dependency I care about, it's just an indirect/transitive dependency. If I add it explicitly to my package.json, I might add a version that works fine now, but conflicts with some future parts of a dependency tree. It seems like unnecessary restriction.

But is that the best practice, what I'm "supposed" to do?

I sort of thought that yarn upgrade lodash should update the yarn.lock without touching the package.json. But yarn upgrade lodash doesn't change any files at all, it leaves yarn.lock the same.

I'm not sure if that is because yarn upgrade doesn't do what I expect, or there is something else in my dependency tree preventing bumping lodash to 4.17.13 -- but if there is, how would I discover what that is? Why wouldn't it be represented in the yarn.lock excerpt above? (Or is it, and I'm reading yarn.lock wrong?)

I could maybe go into yarn.lock manually, and edit the lodash line to say version "4.17.13" -- it's unclear to me if that's what yarn expects me to do. (And seems dangerous, what if I edit it to something that can't resolve with the overall dependency tree?)

I have a pretty simple package.json, but I'm still stumped as to what I'm supposed to do here to ensure I'm using a non-vulnerable lodash. I don't understand how yarn/npm works sufficiently to know what hole to climb down.

I'd appreciate advice from anyone who is very familiar with yarn, on the standard/best/correct/"right" way to deal with this situation.

update it appears there may indeed be no way to do this in yarn?? https://github.com/yarnpkg/yarn/issues/4986 This is baffling to me, I don't understand how yarn users do without it.

Answer 1

Look at Selective version resolution, one of the cases is exactly your:

A sub-dependency of your project got an important security update and you don’t want to wait for your direct-dependency to issue a minimum version update.

{
  "resolutions": { "**/**/lodash": "4.17.13" }
}

Actually, I think you even can not push this into a VCS, just put it into package.json then yarn install it should generate new yarn.lock, then you can remove resolutions from package.json (i didn't test it, just my thought)

Answer 2

Identifying how a vulnerable dependency is introduced can easily be a nightmare. You want to have a look at your dependency tree to identify how lodash was introduced using yarn list (https://yarnpkg.com/lang/en/docs/cli/list/).

This will help you understand how you got this in the first place.

Now the second part to the problem is fixing the vulnerability. this can be achieved by using a tool like Snyk.io that will scan for your dependencies and suggest which of your direct dependencies to upgrade to inject a version of lodash that is not vulnerable.