一位安全研究人员设法破坏了35家以上高科技公司的系统，这被称为一种新颖的软件供应链***（依赖关系混淆***）。通过利用这种称为依赖性混淆或命名空间混淆的***方式，尤其是npm Registry更容易受到供应链命名空间混淆的影响。
什么是依赖关系混淆
我们先来列举一个例子：
想象一下，我说过，您正在从事一个非常秘密的项目，名为Secret Almo。组件坐标为org.acme：secret-almo：1.0，并且您不希望竞争对手知道它。但是，如果您的一位同事不小心将org.acme：secret-almo：1.1或任何不存在的版本添加为该库的依赖项，并运行了构建该怎么办？这是将要发生的事情：
l 请求到达私服的组仓库（group），首先检查本地资源库。如果您的同事没有犯错并且使用1.0作为版本，则解决方案将在那里停止，并且将检索到正确的工件。但是找不到1.1，因此公司的依赖私服会继续寻找。
l 私服会一对一地查看作为组仓库（group）一部分的远程存储库（proxy），将包含您的秘密项目名称的URL请求发送到外部第三方存储库！
在这种情况下，依赖性混淆指的是您的开发环境无法区分软件构建中依赖的组件是内部私有创建的程序包，还是公用软件存储库中同名的程序包。
如何利用依赖关系混淆进行***呢
我们继续举个例子：
让我们回到上一个场景，有关Secret Almo的工作仍在进行中。让我们看一下项目的另一个组件， almo-common-utils，它是用Node编写的，是web应用程序的所有依赖组件中一部分。而私服组仓库（group），包括代理一组远程仓库（代理npm官方注册表），本地（用于内部共享模块）。
考虑以下：
1. npm Registry是一个集市。任何人都可以在上面发布一个未知范围NPM组件，并为所欲为的调用，即“almo-common-utils”。
2. npm注册表中没有名为“ almo-common-utils ”的软件包（好吧，因为它是一个内部公司库），因此没有名称冲突。
3. 大多数npm依赖项都使用版本范围声明来请求最新的兼容版本。
***者想要***不受保护的组织的唯一信息是almo-common-utils的存在，使用中的该库的主要版本（假设他们知道版本3在组织中被广泛使用），并且知道其中的源代码。
他们可以克隆和修改源代码，将任何恶意软件嵌入其中，但仍保持与原始代码的兼容性，并将其作为secret-almo：3.99.99 上载到npm Registry，没有人能阻止它们这么做。
现在让我们看看当请求secret-almo：^ 3.0.0时私服的工作模式：
1. 在本地存储库中寻找最新的兼容机密Almo。发现3.2.4。
2. 在npm-registry代理远程存储库中查找最新的兼容secret-almo。发现3.99.99。
3. 来自npm注册表的虚假secret-almo获胜，供应链被劫持。
如何解决依赖混淆***呢
使用Artifactory，在您的远程存储库上使用排除模式！
您知道在npm Registry中永远找不到almo-common-utils的方法吗？告诉你的仓库管理员！在排除模式中添加您的私有依赖项，并保护自己免受严重供应链***。如此简单，以至于几乎可以忽略不计。
同时也可以在本地仓库中排除掉第三方组件的坐标，避免内部私人串改第三方的可信版本