不破坏依赖树的情况下修复间接漏洞

​修复间接漏洞是不破一项复杂 、乏味且坦率地说是坏依没有人真正想接触的无聊任务。当然，赖树漏洞有很多方法可以手动完成 ，况下但是修复否可以自动完成而将破坏更改的风险降至最低 ？

布满脆弱树木的森林

那么，你甚至从哪里开始呢？间接

首先，需要有一种方法来修复漏洞，不破对于间接依赖而言 ，坏依这种方法是赖树漏洞行不通的。建站模板其次，况下它需要以安全的修复方式完成，或者没有任何破坏
。间接

你看 ，不破间接依赖关系是坏依在依赖关系树的深处引入的，要得到你想要的赖树漏洞确切版本是非常棘手的
。正如 Debricked 的研发主管曾经说过的那样，高防服务器“你正在通过玩弄你的直接依赖项并祈祷 Torvalds 解决正确的间接包来转动旋钮 。当 Torvalds 对你有利时，你必须牺牲一些云存储给叔叔Bob 确保更新不会破坏您的应用程序。”

换句话说，确实应该有一种更简单 、压力更小的方法来做到这一点。

在本文中 ，我们将引导您了解如何手动解决传递性漏洞，并在最后向您展示 Debriked 解决方案，它允许您自动完成 。如果您真的只是云计算对解决方案感兴趣，我建议您开始滚动。

对依赖树进行精确手术

在图数据库项目的研究阶段，或者说 ，今天 Debricked 如何以光速修复您的开源漏洞，团队偶然发现了一些解释如何修复 NPM 中的间接漏洞的文章 。

如文章所述，`minimist` 软件包受漏洞影响，即CVE-2021-44906和CVE-2020-7598。

这些都是“原型污染”漏洞，这意味着没有正确清理参数
。香港云服务器幸运的是，`minimist` 的维护者在 1.2.6 版本中修复了这些漏洞
。

不幸的是 ，`mocha` 版本 7.1.0 解决了`minimist` 0.0.8 ，这是在这些漏洞的易受攻击范围内。正如本文作者所建议的 ，可以通过几种不同的方式修复这些漏洞。服务器租用

突破性的变化？

第一个建议是简单地触发所有“间接依赖项”的更新 ，这意味着我们实际上不会更改 `mocha` 的版本。要执行此更新 ，只需运行“npm update”，删除你的“npm.lock”文件 ，然后运行“npm install”。这将使用您的间接依赖项的最新可能版本（根据约束）重新生成依赖项树。使用这种方法，破坏更改的源码下载风险非常低
，因为您实际上不会更新任何根依赖项，而只是更新您的间接依赖项 。

当包的功能或接口不向前兼容时
，就会发生重大更改，这意味着包的更新可能会导致您的应用程序中断。常见的重大更改是类/函数删除、函数参数更改或许可证更改（注意那个！） 。

但生活并不总是那么容易，树的这种简单更新并不能解决漏洞。问题是 `mkdirp`实际上已将他们的 `minimist` 版本锁定为 0.0.8。这意味着 `mkdirp` 的贡献者已经得出结论
，他们与较新版本的 `minimist` 不兼容
，并且强制更新 `minimist` 可能会在 `mkdirp` 和 `minimist` 之间引入破坏性更改 。

应该使用什么版本的 `mocha`，进而在不破坏依赖关系树的情况下滴流到安全版本的 `minimist` ？

什么图算法可以解决这个问题？NPM 如何解决依赖关系可能有点复杂，因为它们可以“拆分”依赖关系树。这意味着它们可以拥有一个依赖项的多个版本
，以确保我们始终拥有一棵兼容的树
。为了解决这个漏洞，我们需要通过更新所有可以渗透到 `minimist` 的根来确保 `minimist` 的所有实例都是安全的 。

用于解决此问题的算法称为“所有最大路径安全”。通过遍历依赖图并保持最大版本，同时在每个交叉点修剪该包的所有其他版本，我们可以创建依赖树的近似表示 。如果近似值是安全的，那意味着我们真正的树也是安全的！

通过对“mocha”的所有潜在版本执行此算法，我们找到了修复此漏洞的最小升级。为了获得我们想要的算法速度  ，团队必须构建一个自定义的Neo4j 程序，它可以在约 150 毫秒内处理搜索超过 100 个根版本，搜索深度为 30+
。速度快吧？

在这种情况下
，我们不必搜索很远……因为 `mocha` 的 7.1.1 是安全的！这只是一个补丁更新 ，这表明破坏更改的风险非常低 。对于不太复杂的情况（如本例），“npm audit”可以帮助您使用他们出色的“npm audit fix”命令 。