应用程序的依赖关系有很多种类型，包括：库、数据库、缓存以及应用程序所使用的第三方服务等。一旦应用程序的依赖关系发生了缺失或存在问题，那么该应用程序的功能、用户体验、安全性以及正常运行时间都会受到一系列的影响。

开发人员会因为各种各样的原因来对应用程序依赖项进行升级，例如安全修复、新功能版本的发布、旧版本维护以及性能改进等。但不幸的是，对应用程序依赖项的升级是一件极其耗费时间的事。例如，组织有时可能仅仅想要对某个单独的库进行升级，但最后却需要连同其所依赖的许多其他库一起进行升级。

软件依赖关系：风险和安全措施

有时为了实现新功能或提高生产率，开发人员需要引入一些新库。然而，尽管这些库在引入的初期可以帮助节省一些时间，但到了后面，往往会逐渐成为项目的主要负担。

“依赖地狱”指的是当软件依赖于其他依赖来运行时所出现的问题。例如，当某个第三方软件出现故障并将bug引入到其他应用程序时，就会发生这种情况。理解“依赖地狱”产生的原因对于避免或减少其发送至关重要。“依赖地狱”并不是由某个单一因素造成的，这其中存在着一系列的原因，其中常见的有：

・代码质量：通常来讲最好的办法就是使用被开发人员所广泛信任的泛型库，但是泛型库也仍有可能存在一些问题。并且，即使是在引入了这些库之后，组织大概也无法发现依赖性漏洞，况且还可能存在其他潜在的漏洞。所以，在使用某个库之前，对其进行漏洞检测是十分必要的。

・过时的代码库：在一些场景下，开发人员编写了一段代码，然而随着时间的推移，这些代码失去了使用价值并被完全遗弃，但是代码本身却未被从系统中删除。于是这种类型的代码就成为了一种潜在的风险，使组织面临一些修复成本高昂的漏洞。

・依赖项中的死代码：有些依赖项可能会需要下载或使用不必要的死代码。随着不断发展，项目可能会与这些死代码出现重叠的依赖关系。

・不完整的文档：在某些情况下，组织可能缺少用于向他人介绍程序功能的文档，或者是文档的质量差。但由于缺乏适当的文档，对软件依赖关系的改进和协调过程就会变得更加困难。

以上这些还仅是依赖关系可能导致问题的场景。另一方面，尽管外部的包和库非常有用，代码重用也是软件工程不可分割的重要组成部分，但是在重用的时候，组织必须保持十分的谨慎和责任心。

识别应用程序依赖关系的技术

应用程序识别

在应用程序识别过程中应用程序数据管理（Application Data Management，ADM）工具能够识别和监控软件产品的不同组件。以下是三种主要的传统识别方法：

・Sweep and Poll: 该技术会通过 ping IP 地址并收集响应信息，来识别依赖关系。

・网络监听：网络流量分析可以帮助识别数据包在流经系统时所采取的路径。

・Agent-Based: 这种方法包括在服务器上安装一个小型软件程序，来对出站和入站流量进行实时监控。

相比于这些传统方法，有些应用程序识别技术会使用工具来提升便捷性和有效性。例如，可以使用编排平台、应用程序性能监视（APM）工具以及高级监视功能来识别和跟踪应用程序组件和底层服务器资源。

应用程序映射技术有助于识别和映射整个 IT 生态系统中所使用的全部实例、通信通道以及应用程序（包括端口和服务）。高级解决方案还可以定义子网、虚拟私有云（VPCs）以及云上的安全组，例如 Azure、谷歌云以及 AWS。

这些工具直观映射的特性实现了应用程序依赖关系的可视化表示。组织可以对这些映射进行共享和检查，并将其用于各种用途，包括故障排查和规划。该技术可以帮助告知业务策略，根据业务上下文来组织信息，并实时地确定关键警报和信息的优先级。

部署和运行于云环境中的云原生应用程序在安全方面也可能会受到应用程序依赖关系的影响。应用程序依赖关系主要通过以下几种方式来影响云原生应用程序的安全性：

与传统的应用程序一样，一旦云原生应用程序与具有已知安全漏洞的库或框架具有依赖关系，那么整个应用程序都会陷入风险之中。在向开发环境中引入依赖关系之前，组织需要保持依赖项的实时更新，并对其进行仔细的检查和测试。

云原生应用程序的依赖关系越多，攻击者就有越多的机会来尝试利用漏洞。组织应尽可能地保持应用程序所拥有的依赖关系数量处于最小值，特别是那些不是特别必要的依赖关系。

若云原生应用程序所依赖的库或框架遭到了攻击破坏，那么该应用程序中的数据就有可能遭到更改或损坏，从而导致数据丢失或机密性的破坏。

以 PCI DSS 为例，作为一种标准，PCI DSS 要求组织确保所有软件依赖关系都是安全的，并且还需要进行定期的更新。未能正确管理依赖关系就可能会导致组织违规。

应用程序依赖关系是云迁移项目中的关键部分，通常是迁移过程中出现安全问题和停机的关键原因。

将应用程序视为一个分层结构是非常有用的。它包括一系列的依赖工具和 API，从应用程序自己的接口开始，一直延伸到它所依赖的平台。依赖管理的目标是确定可以协同工作的版本组合，以便开发团队能够更好地了解新的和不断变化的应用程序依赖关系。通过将应用程序表示为分层结构，可以对依赖关系有一个更加清晰地了解，从而更好地管理和控制它们，确保应用程序能够稳定、可靠地运行。

组织可以控制自己应用程序组件的版本，来启动这个依赖链处理过程。如果组织有需要分别分发的软件组件，则需要为每个组件分配一个版本号，并跟踪该版本的基础依赖链。这样组织就可以获得与每个应用程序版本相关联的特定平台工具的版本。如果出于任何原因需要回滚，那么组织则可以决定哪些其他组件也需要回滚以维护版本兼容性。。

因为这种方法需要更改某些平台组件（包括中间件），所以每个应用程序的平台版本都必须得到同步。要做到这一点，组织就需要始终从依赖链的顶部开始，直到达到链的末端。开发人员设计他们的应用软件时，会使用特定的操作系统和中间件功能，并期望使用常用工具的 “某个版本版或更高版本”。对于任何给定工具的任何给定版本，开发人员都必须检查所有的依赖项，而不仅限于自己内部的依赖项。

并非所有的应用程序依赖关系都是明确的。例如，许多开发人员都面临着这样一个问题，即管理程序平台版本必须与物理主机上的客户操作系统兼容。另一个常见的问题是，当一个编排器的特定版本，如 Kubernetes，需要一个操作系统组件的特定版本时。重要的是要通过对每个依赖链与标准操作系统和中间件组合进行测试来确定所有依赖关系。

当组织准备迁移到云端时，需要搞清楚每个应用程序的依赖树，包括对云提供商功能和 api 的所有引用。确保组织能够了解云供应商是如何对其 API 和工具进行通信更改的。同时，组织还需对这些更改可能创建的任何新的依赖关系进行验证。

如果组织计划进行混合或多云部署，那么建议对这些云依赖树进行差异比较，以识别跨云平台边界迁移的所有应用程序和组件。若有两个不同的供应商的依赖树存在不一致，那么组织就有可能在这些供应商平台之间面临扩展或故障转移的问题。为了避免这种情况的发生，组织就需要提前对组件进行同步。

应用程序依赖关系对于云安全来说至关重要。因为如果管理不当，那么它们可能就会引入漏洞并暴露敏感数据。通过理解和跟踪依赖关系，组织可以确保自己的应用程序是安全的，并且符合行业标准和法规。

同时，适当的依赖关系管理还可以帮助提高应用程序的性能和可靠性。因为过时的或不合理的依赖关系可能会导致 bug 和系统崩溃等问题的出现。

应用程序依赖关系涉及到应用程序所依赖的所有组件、工具和接口。在云计算环境中，这些依赖关系往往比传统的本地应用程序更为复杂和深层次。应用程序的漏洞和安全弱点均可能会通过它们的依赖关系而扩散到整个系统中，从而加重威胁与风险的程度和范围。若一个组织对自己的应用程序依赖关系没有一个清晰的了解，那么该组织就无法有效地评估系统中的所存在的风险与隐患，更无法采取适当的安全措施来保护组织内的系统和数据。除了要对应用程序的依赖关系进行全面的识别梳理和定期的更新同步以外，组织还可以通过使用容器化技术或限制组件访问权限来降低依赖关系所带来的风险。