7

I have a package.json that gives a load of security warnings. Looking at the first critical item I see its open@0.0.5 which hasn't been updated for five years. Looking at npm ll it is included by npm@6.5.0 where I am using the latest that was updated about two weeks ago.

I would like to remove the insecure dependencies. In the Java world the maven package manager lets you put exclude certain transitive dependencies. Ideally, with npm or another node package manager, I should be able to exclude dependencies with vulnerabilities. Then I can retest that my app works and not see any security errors. Is there a way to quickly exclude anything that has a security vulnerability from my package.json? If there isn't a way to do this what approaches can a take to ensure that no insecure packages are used by my application?

Update: Although "npm": "^6.5.0" is specified in the package.json I was building it with an older npm which was picking up the critical issue mentioned above. I fixed all the issues with ./node_modules/.bin/npm audit fix --force

simbo1905
  • 6,321
  • 5
  • 58
  • 86

3 Answers3

2

By definition, you can't exclude a package that a dependency you are using relies on. In other words, if you require package A, and package A claims it is dependent on package B, then removing package B will cause A to either stop working altogether or begin behaving erratically.

Unfortunately this does happen, and your options include:

  1. Ignoring the security warning.
  2. Replacing package A with something else (applies in some cases and not others).
  3. Asking the maintainer of package A to upgrade the version of package B they rely on, possibly opening a pull request yourself.

In your case, though, I'm not sure if your investigation is complete yet - I don't see open in npm's dependency list. Might be worth scrapping your node_modules and re-running npm install, then check again to see who is using open.

Elliot Nelson
  • 11,371
  • 3
  • 30
  • 44
  • I have updated the question about that dependency being picked up from the older globally installed npm – simbo1905 Dec 26 '18 at 17:52
  • if your doing TDD then excluding a transitive dependency seems a valid thing to do as you won't release of the code if it doesn't work without the dependency. letting folks choose to exclude what they can confirm they don't use seems like an important feature to avoid bloat and security issues. which is probably why it exists in other ecosystems. – simbo1905 Dec 26 '18 at 18:02
  • I guess it boils down to philosophy more than anything. If package A depends on a lot of packages it doesn't actually need, that's a poorly designed package (it could use peer dependencies instead, and make optional features available based on their presence). Excluding a dependency of a package you use is making unenforceable claims about the internal implementation of the package, because clearly the author believes it should exist, and might release minor version updates that rely on it. – Elliot Nelson Dec 26 '18 at 20:43
  • the codebase which is a fork of gothinkster/react-redux-realworld-example-app looks to include 2126 dependencies. it seems a little implausible that all of them are used by the application logic. perhaps poorly designed packages are the norm. – simbo1905 Dec 26 '18 at 21:34
  • I hate to say it's the norm, but the current paradigm in the npm js is to tend toward small focused packages, and a "framework" (packages like babel, eslint, express, react) can easily have a tree of 300+ packages. – Elliot Nelson Dec 26 '18 at 21:53
  • If you are using a Framework that has 300+ dependencies it's very likely that you are only using a small subset of the functionality of the Framework. For example, many Web/API Frameworks have support for XML & JSON. Most likely you will never use XML and therefor you could exclude the transitive dependency which is responsible for parsing XML. In the Java world, the Maven package manager allows excluding transitive dependencies. It would be great if NPM would support that, too! – Robert Reiz Feb 24 '20 at 10:22
  • Actually I just found a solution. With Yarn it is possible to overwrite the resolution of transitive dependencies. See here: https://classic.yarnpkg.com/en/docs/selective-version-resolutions/. That doesn't allow to exclude a transitive dependency, but at least it allows you to overwrite the version of transitive dependencies. That is super helpfull! – Robert Reiz Feb 24 '20 at 13:05
0

This specific warning is targeting at your lockfile, and can be easily fixed by removing the yarn.lock or package-lock.json and reinstall dependencies.

QuincyChen
  • 1
0

Tarn package manager has feature resulution by which you can set fixed libraries to insecure thirdparties.

See How do I override nested dependencies with `yarn`?

NPM has something similar.

Tomas Kubes
  • 23,880
  • 18
  • 111
  • 148