tl;dr - if Dependabot isn’t opening a PR to fix a vulnerable package, especially with npm + yarn, try it manually every so often. Use commands like:

  • npm ls vulnpackage to see where the vulnerable package is in the npm dep tree
  • yarn why --recursive vulnpackage for Yarn’s explanation of all dep trees including the vulnerable package
  • yarn up --recursive vulnpackage to upgrade everything in the dep tree from the vulnerable package, but keeping the version constraints specified in your package.json (only available in Yarn 3.0+)

This was an issue we encountered at my last job. We used Github’s Dependabot to track CVE’s in our supply chain. There are similar tools from Snyk and others, but Dependabot comes included with Github, and it’s compatible with a pretty broad array of languages.

There was a frustrating vulnerability that was open for some time - vm2 had a sandbox escape vulnerability, and it was required about 7 levels deep by Microsoft AppCenter’s react-native-code-push library. Rather than attempt to mitigate the issue, the vm2 maintainer decided to discontinue the project.

Eventually a mitigation was found, since the code path using vm2 in code-push is a very rare use case, and could be removed by using a newer version of superagent . code-push was updated, then react-native-code-push was updated to fix the dependency tree and allay Snyk and Dependabot alerts for AppCenter users.

Dependabot should have opened a pull request to update our app. Although react-native-code-push was pinned to version v.8.0.0 , the dependency specification for code-push was at "code-push@npm:^4.1.0": in the yarn.lock file. When we ran yarn up --recursive code-push , it successfully updated code-push in the yarn.lock file, removed the vm2 dependency, and looked ready to go. But Dependabot was throwing an error and saying that the dependency “could not be upgraded.”

I’ve managed to nearly reproduce this situation in a public repo - check out yarn-dependabot-example on my Github. The only difference here is that Dependbot doesn’t seem to be trying to open a pull request to fix the issue. Running yarn up --recursive code-build fixes it immediately, affecting only the lockfile.

I wasn’t able to clearly determine why Dependbot considered this issue unfixable, but it seems clear that the dep tree shaker written for Dependabot and the one Yarn uses are slightly different. For any “stubborn” vulnerabilities that aren’t getting fixes auto-generated, it’s worth trying the simply stuff manually now & then to see if a fix is available.