几步简单的操作解决 `npm audit` vulnerabilities

NPM 是 JavaScript 生态最重要的组成部分,我们的项目中会大量使用 NPM 安装第三方包(安装后就称为“项目依赖”)解决问题。这些第三方包也会带来他们的依赖,最终一个项目里可能安装成百上千个依赖。

有道是:没有完美的代码,代码里一定藏有隐患。所以用的依赖多了,其中有问题的概率也提升了,三五不时的,npm 就会提示我们:found N low/medium/high severity vulnerabilities

npm 提供命令 npm audit fix,理论上可以修复这些隐患,但在实际操作中,以我的经验来看,并不容易生效。我猜测可能是因为依赖间的复杂关系,想彻底解决并升级不太容易。所以我一般是这样做的:

  1. GitHub 或者 NPM 告诉我有 “(potential security) vulnerabilities”
  2. 因为我的项目以前端为主,所以基本上问题不大,所以我会等两天,等仓库主人修复仓库
  3. 大约 1~2 周后,打开项目,先试一下 npm audit fix
  4. 能修好当然最好,不能修好就只好升级:npm update
  5. 升级完可能还会有 vulnerabilities,没关系,因为前面说过,依赖间的关系很复杂,npm 可能没有办法很好的解决。所以这个时候,删掉 node_modulespackage-lock.json,然后重新安装依赖 npm i
  6. 大部分情况下,这个时候就 OK 了。有时候还不行,那就 npm outdated 看一眼有没有可以升级的大版本
  7. JavaScript 生态里,因为 ES 版本的关系、TS 的关系,大版本升级往往没有非常剧烈的 API 变动,很多时候,比如从 3.0 => 4.0,也可以平滑升级(webpack 除外)。默认情况下,安装后的依赖都用 ^a.b.c 指定版本,即不低于 a.b.c,且大版本不能超过 a。所以 npm update 的时候,不会升级大版本。但是我们可以研究一下,比如看一下 release note,然后升级大版本:npm i some-repo@4(仍以 3 => 4 为例)
  8. 提醒一下,虽然以我的经验,大版本升级 80% 是安全的,但也有不小的可能导致项目出问题,如果你的项目没有很好的测试覆盖,或者你没有很好的测试用例积累,那么不要轻易升级。建议单独立项稳妥升级。
  9. 大部分情况下应该问题解决,如果还不行,重复(5)
  10. 如果大版本升级也解决不了,那么可以再等等。
  11. 如果是 node.js 项目,最好尽快解决,不要等,可以直接手动升级隐患依赖的版本好。

总结

这套方案的好处在于简单,基本敲几个命令等一会儿就行,依赖本身就应该经常升级,但应该有测试覆盖。

如果您觉得文章内容对您有用,不妨支持我创作更多有价值的分享:


已发布

分类

来自

评论

欢迎吐槽,共同进步

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据