当我运行npm install时，它显示found 33 vulnerabilities (2 low, 31 moderate) runnpm audit fixto fix them, ornpm auditfor details。
但是，npm audit fix输出up to date in 11s fixed 0 of 33 vulnerabilities in 24653 scanned packages 33 vulnerabilities required manual review and could not be updatedreview是否意味着它不应该由用户修复？
当我运行npm audit时，它会给我一个表列表，类似于这样：
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Low │ Prototype Pollution │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package │ lodash │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Patched in │ >=4.17.5 │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ browser-sync [dev] │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path │ browser-sync > easy-extender > lodash │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info │ https://nodesecurity.io/advisories/577 │
└───────────────┴──────────────────────────────────────────────────────────────┘在这个例子中，链接页面的补救部分显示为Update to version 4.17.5 or later.。然而，在/node_modules/browser-sync/package.json中有几行：
"devDependencies": {
"lodash-cli": "4.17.5",
}不再依赖lodash。所以应该已经是v4.17.5了。我还检查了/node_modules/lodash/lodash.json，它有var VERSION = '4.17.10';线。在/node_modules/lodash/package.json中，有以下几行：
"_from": "lodash@^4.17.4",
"_id": "[email protected]",我相信版本显示在“_id”，而不是“_from”，所以版本是正确的，但漏洞仍然出现在审计列表中。
我还是node.js的新手，这些消息让我很困惑。有没有办法手动修复它或摆脱这些消息，我不能做任何事情？
7条答案
按热度按时间btqmn9zl1#
devDependencies中的lodash-cli不会影响browser-sync在项目中的工作方式，当软件包作为依赖项安装时，devDependencies将被忽略。audit报告说的是easy-extender具有lodash依赖性：这取决于Lodash 3，而这个问题在Lodash 4中得到了解决。这个问题可以通过分叉
easy-extender，更新它并安装它而不是NPM公共注册表中的软件包来解决。但这种依赖性并没有真实的问题。audit报告重要性应该手动评估。即使嵌套依赖项具有安全风险，这也不意味着使用了引入此风险的功能。这也并不意味着即使使用它，它也会因使用方式而引入真实的风险。browser-sync是一个开发工具，它没有在生产中使用，因此没有太多的场景可以利用它的漏洞。而且 Prototype Pollution 根本不是一个漏洞，只是一个软件包没有遵循良好实践的通知，它可以被忽略。通常，这是修复报告的漏洞的方法：
大多数情况下，我们预计您不会超越健全性检查，唯一的问题是“漏洞”会扰乱审计报告并隐藏真实的漏洞。
patch-package可以帮助修补嵌套的依赖关系，但这不会影响报告。可以使用
resolutionsfield在Yarn 1和2中的嵌套依赖中强制特定依赖版本，这将影响审计报告。将来可能会有这样的natively in NPM。目前NPM中的替代方案是第三方npm-force-resolutions实用程序，它提供较少的控制，目前它强制all dependencies, not a specific one解决方案。**请注意，通过强制依赖项使用其未设计的嵌套依赖项，它随时可能被破坏。这尤其适用于
npm-force-resolutions，它是一个生硬的工具，可以同时影响许多嵌套的依赖关系。nle07wnf2#
如果您非常确定要跳过审计，可以通过附加--no-audit来实现
来源：文件
案件可
False positives further reading
Wrong contexts further reading
2022年更新
或者，您可以使用Better NPM audit来微观管理审计
irtuqstp3#
'npm audit fix'将增加package.json中依赖项的版本，这可能会导致代码中断。因此，更好的方法是打开package-lock.json并将依赖项/子依赖项版本更新为所需版本。在仓库中维护package-lock.json。
有时漏洞来自开发包，在这种情况下，忽略这些漏洞，因为这些漏洞在生产中不会被发现。
pepwfjgg4#
使用此
npm审计fix --force --production
也许能解决你的问题
0s0u357o5#
你也可以像
npm audit fix --force一样使用力。lvmkulzt6#
安全意义上的真正漏洞（和暴露）具有分配的唯一CVE和/或GHSA ID。JavaScript软件包现在可以通过几种覆盖范围广泛的安全扫描工具（如Trivy或Snyk）来扫描此类漏洞，这些工具可以指向有问题的
package.json文件的路径，并显示已安装软件包的版本以及CVE/GHSA ID。这些扫描器还可以应用于在允许部署之前对整个Docker容器执行自动扫描（例如，Jenkins管道）。手动修复JS包中的CVE（如果
npm audit fix不能自动修复）包括升级，例如：如果安全补丁已经存在（可以使用npm outdated <package>进行验证），则可以使用npm i <package>@<patch_version>进行验证，也可以使用npm outdated <package>进行多次验证（在所有嵌套级别上），或者在该补丁可用之前将CVE编号和软件包组合列入白名单（如果属于“无法修复”类别）。如果node二进制文件是受影响的文件，那么node本身偶尔也需要升级-您可以使用nvm install <major_ver> && nvm alias default <major_ver>来完成。qacovj5a7#
我试过了，它对我很有效，运行以下命令：