# 从一个安全漏洞说起
Lodash 是一款非常流行的 npm 库，每月的下载量超过 8000 万次，GitHub 上使用它的项目有超过 400 万。前段时间 Lodash 的一个安全漏洞刷爆了朋友圈，我们先来回忆下这个安全漏洞：
攻击者可以通过 Lodash 的一些函数覆盖或污染应用程序。例如：通过 Lodash 库中的函数 defaultsDeep 可以修改 Object.prototype 的属性。
我们都知道，JavaScript 在读取对象中的某个属性时，如果查找不到就会去其原型链上查找。试想一下，如果被修改的属性是 toString 方法：
const payload = '{"constructor": {"prototype": {"toString": true}}}'
_.defaultsDeep({}, JSON.parse(payload))
每个对象都有一个 toString() 方法，当该对象被表示为一个文本值时，或者一个对象以预期的字符串方式引用时自动调用。默认情况下，toString() 方法被每个 Object 对象继承。如果此方法在自定义对象中未被覆盖，toString() 返回 [object type]，其中 type 是对象的类型。如果覆盖了 toString() 方法，那么给应用带来的影响就是非常大的。
其实上述的问题就属于一个很常见的安全漏洞 —— 原型污染
原型污染：攻击者通过某种手段修改 JavaScript 对象的原型（prototype）
然而这并不是 Lodash 第一次爆出安全漏洞了。事实上，像这样的安全漏洞还可能存在于我们使用的千千万万个不同的开源依赖中，如果我们平时不重视他们，一旦出现问题对我们的项目造成的损失是不可估计的。这相当于你的项目中埋着很多不知道什么时候就会爆炸的炸弹。
# 安全调查
其实开发人员对开源代码的安全性的信任程度要大于对自己编写的代码的安全性的信任程度，但是在确保代码安全性和质量的工具还有很多不足之处。在 npm 还没有一个完善的安全检测机制之前，npm 和 NodeJs 团队曾经对数万名 JavaScript 开发者发起过一个调查，第一个问题就是安全问题，具体就是开发人员如何看待他们编写的代码和所使用的开源项目的安全性。
调查结果显示：全球 97％ 的 JavaScript 开发人员在自己开发的项目中都依赖开源代码，77％ 的开发人员对他们使用的开源代码是否安全表示担忧。更有趣的是，有 87％ 的人表示担心自己的代码的安全性。
另外，超过一半的 JavaScript 开发人员认为，他们用来评估开源代码的安全性和质量的工具还不够好。
# npm audit
基于上面的不太乐观的调查结果，npm@6 增加了一项重大更新：npm audit 命令。从上面的 logo 就可以看出，这个版本是主打安全性。 npm audit 命令会递归地分析依赖关系树以识别不安全的依赖，如果你在项目中使用了具有已知安全问题的依赖，就收到警告通知。该命令会在你更新或者安装了新的依赖包后自动运行。
npm 官方专门维护了一个漏洞列表，当开发者或者专业的安全团队发现某个依赖包存在安全问题后就会上报给 npm 官方，然后官方会通知该项目开发者进行修复，修复完成后 npm 会把漏洞详细的描述信息、解决方案发布出来：
npm aduit 主要做的就是把需要检查的依赖信息发送给一个官方检查接口, 该结构会在历史上报的漏洞数据库中判断当前依赖信息是否含有漏洞，然后生成一个包含包名称、漏洞严重性、简介、路径等的漏洞报告反馈给开发者。
我们现在直接安装一个具有安全漏洞的 lodash@4.17.4 版本，可见安装完成后会提醒你你刚刚增加的依赖中含有3个漏洞。
执行 npm audit 我们可以看到漏洞详情，这个版本的 lodash 存在3个安全漏洞，我们来具体看一个：
High: 表安全漏洞等级Package: 存在漏洞的包名称Dependency of: 当前工程直接依赖的包名称Path: 漏洞完整依赖路径More info: 漏洞详情
这里注意，并不只是直接依赖的包具有漏洞才会收到提醒，而是只要是你的依赖树中某一个节点依赖依赖了具有漏洞的包你就会收到提醒，来看看下面的例子：
项目中并非直接依赖了 lodash ，而是 @commitlint/cli 依赖的 @commitlint/load 中依赖了 lodash 就会算作一个漏洞，所以一些庞大的迭代周期很长的项目含有几万个安全漏洞也是很正常的。
点开漏洞详情的链接：https://www.npmjs.com/advisories/1065
