软件供应链***（依赖关系混淆***）正在破坏你的系统安全

一位安全研究人员设法破坏了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的方法吗？告诉你的仓库管理员！在排除模式中添加您的私有依赖项，并保护本身免受严重供应链***。如此简单，以致于几乎能够忽略不计。

 

同时也能够在本地仓库中排除掉第三方组件的坐标，避免内部私人串改第三方的可信版本