近日，Sonatype 发布《2021 年软件供应链状况报告》，报告混合了大量的公共数据和专有数据，揭示了几个重要的发现：开源供应正在加速，全球开源供应的年环比增长20%、组件下载量同比增长73%、开源需求呈爆炸式增长；供应链攻击呈指数级增长；2021世界上软件供应链攻击增加了650%；开源漏洞在流行项目中最为普遍，29%的流行项目至少包含一个已知的安全漏洞。各团队之间的依赖关系管理实践差异极大。
开源供应、需求和安全
对更快创新的普遍渴望从根本上要求软件开发人员频繁有效地重用代码。这反过来又导致严重依赖从第三方生态系统借用的 OSS 库。图 1.1 总结了 Java、JavaScript、Python 和 .NET 生态系统的供应、需求、使用和安全性统计数据。
1、开源代码供应
供应全球开放源代码库的供应量继续呈指数级增长，目前，排名前四的开源生态系统总共包含 37,451,682 个组件和包。去年总共发布了 6,302,733 个新版本的组件/包，并推出了 723,570 个全新项目，以支持全球 2700 万开发人员。
图1.1 2021年软件供应链现状
图1.2 2021开源可用资源
图1.3 2020 年至 2021 年下载量逐年增加
图1.4 2021 年年度下载量
2、开源需求
2021 年，各地开发者将从第三方生态系统中借用超过 2.2 万亿个开源包或组件，原因有两个：开源软件开发者的生活更轻松，并加快了创新的步伐。
Java 2021 年前七个月，从 Maven 中央存储库下载了 2670 亿个 Java 组件。按照这个速度，2021 年 pypistats.org 的第 3 季度预计将超过 4570 亿，同比增长 71%。
JavaScript：2021年的交易量预计将达到1.5万亿，同比增长50%。
Python：2021年全年，PyPi 下载量预计为 1270 亿包，同比增长估计为 92%
.NET ：2021 年，开发者将下载超过 780 亿个软件包，同比增长 78%。
图1.5 漏洞释放密度 VS. 流行程度
3、开源安全
流经软件供应链的第三方代码数量巨大。在检查最流行的 Java、JavaScript、Python 和 .NET 项目的前 10% 时，其中 29% 至少包含一个已知的安全漏洞。相反，在其余 90% 不太流行的项目中，只有 6.5% 包含已知漏洞。这表明大多数安全研究者都专注于发现和报告最常用的项目中的漏洞。
除了研究流行和非流行开源项目之间的漏洞密度差异之外，下面还展示了四个生态系统中每个生态系统的综合脆弱性密度。
Java (Maven) ：截至 2021 年 7 月 31 日，Maven Central 中的所有组件版本中有 612,988 (8.4%) 个至少包含一个已知的安全漏洞。
JavaScript (npm) ：截至 2021 年 7 月 31 日，npm 中的 459,576 (2.2%) 个项目版本至少包含一个已知的安全漏洞。
Python (pypi) ：截至 2021 年 7 月 31 日，PyPI 存储库中的 147,994 (0.5%) 个软件包版本至少包含一个已知的安全漏洞。
.NET（ Nuget）：截至 2021 年 7 月 31 日，NuGet 库中的 112,031 (2%) 个软件包版本至少包含一个已知的安全漏洞。
4、软件供应链攻击增加
随着开源需求的增加，开源攻击增加了650%，攻击者不再等待公开的漏洞披露来进行漏洞利用，而是主动将新漏洞注入为全球供应链提供支持的开源项目中，通过将攻击转移到“上游”，可以获得影响力和关键的时间优势，使恶意软件能够在整个供应链中传播，从而对“下游”用户进行更具扩展性的攻击。到目前为止，Node.js (npm) 和 Python (PyPI) 存储库一直是恶意软件包的主要目标，推测是因为在软件包安装过程中很容易触发恶意代码。”但在过去一年中，此类攻击同比增长650%（见图1.6）。
图 1.6 2015-2021 年下一代软件供应链攻击（依赖混淆、域名抢注和恶意代码注入）
依赖混淆 ：2021 年最常见的攻击类型是依赖混淆。这种新颖的、高度针对性的攻击媒介允许将不需要的或恶意的代码自动引入下游，而无需依赖域名抢注或品牌劫持技术。技术涉及一个坏人确定公司生产应用程序使用的专有（内部源）包的名称。
域名抢注：域名抢注过去一年中第二个最常见的技术。这种间接攻击媒介会利用开发人员在搜索流行组件时犯下其他无害的拼写错误。
恶意源代码注入 ：恶意源代码注入是另一种类型的攻击，与前几年相比，过去一年不太流行。此类攻击涉及将恶意源代码直接注入开源项目的存储库，并以多种方式进行。
示例性和非示例性开源项目
衡量项目依赖更新速度的 MTTU 与提高项目安全性密切相关。为了最大限度地降低与第三方开源库中的漏洞相关的风险，建议软件开发团队采用定义的标准来选择开源项目。此外，建议团队选择 MTTU 较低的项目。
1、开源项目质量指标
平均更新时间 (MTTU)
MTTU 是项目响应其依赖项的新版本所需的平均时间。MTTU 提供对开源项目依赖管理实践的可见越低越好。持续对其下游依赖链中的依赖升级做出快速反应的项目将具有较低的 MTTU。始终反应缓慢或反应时间差异较大的项目将具有更高的 MTTU。
图 2.1 2020 年 MTTU 性能
图 2.1 显示了根据 2020 年的更新数据，实现各种 MTTU 性能的组件百分比。尽管百分比攀升很快，但存在长尾 升级缓慢的组件，其中 9% 的组件升级时间超过 180 天。
图 2.2 Maven Central 2011 – 2021 年项目的 MTTU 分布
随着依赖链的增长，这种缓慢的更新行为会产生更大的影响。MTTU 提供了一种项目质量的度量，该度量基于项目更新依赖项的速度。通过这种衡量，质量多年来一直在提高。在图 2.2中，我们提供了自 2011 年以来每年项目 MTTU 值的分布图。
MTTU 和安全性
虽然 MTTU 不直接衡量对安全问题的响应能力，但分析发现，MTTU 与平均修复时间 (MTTR) 相关，MTTR 是更新已发布漏洞的依赖项所需的时间，如图2.3所示。MTTR 的定义与 MTTU 类似，不同之处在于取更新时已知易受攻击的依赖项的平均值。图 2.2 按年份划分的 MTTU 分布 Maven Central 2011-2021 年项目执行漏洞研究并发现代码库中的潜在问题。另一方面，MTTU 可用于所有项目，为评估项目质量提供通用数据来源。因此，MTTU 可被认为是可用于确定组件对包含它的项目的安全性的影响的最佳指标。
图 2.3 计算 MTTR
Libraries.io Sourcerank 指标：旨在衡量软件的质量，主要关注项目文档、成熟度和社区。
OpenSSF 关键性分数：OpenSSF 有一组分析，这些分析组合成一个称为“关键性”的指标。关键性衡量项目的社区、使用情况和活动。这被提炼成一个分数，旨在衡量项目在开源中的重要性生态系统。
OpenSSF Scorecard：OpenSSF 还有一个更广泛的项目质量评估，称为“Scorecard”项目。该项目支持自动监控开发实践、工具使用和其他项目质量和成熟度属性，然后报告哪些检查成功，哪些失败。
质量度量比较
图 2.4 2021 年的开源质量指标比较
图 2.4 总结了四个提议的项目质量框架，显示了它们在多大程度上包含了五个质量维度的信息：成熟度、流行度、活动、依赖管理和开发实践。
流行度 ：Libraries.IO 将项目流行度指标（星级、订阅者和使用情况）作为其 Sourcerank 指标的一部分。OpenSSF 的关键性指标包括使用情况（使用该库的项目数量），但不包括星级或订阅者。 OpenSSF 的 Scorecard 系统和 MTTU 不包含任何与流行度相关的因素。
活动：所有质量框架都包括活动分析的某些方面。Sonatype 的 MTTU 指标与活动轻微相关，因快速 MTTU 需要频繁发布。Libraries.IO Sourcerank 跟踪项目在过去六个月内是否已更新，这是与活动的另一个弱相关性。
依赖管理：Sonatype 的 MTTU 提供了最强大的依赖更新实践衡量标准，因为可以衡量一个项目在新版本发布后更新其依赖的速度。Libraries.IO Sourcerank 在评分时检查是否存在过时的依赖项。OpenSSF 记分卡检查是否使用了自动依赖更新工具。
OpenSSF Criticality 不考虑依赖管理实践
2、研究结果
在使用开源组件时，组件可能包含漏洞，它们的应用程序会继承漏洞。如果有可用的修复路径，组件可能容易受到攻击，需要付出大量努力来重构或弃用组件。组件升级也会破坏应用程序构建，需要更多的开发工作。获取39,164 个开源组件的集合，这些组件在这 100,000 个应用程序中使用，获得了 52% 组件的 MTTU 数据、91% 组件的 Sourcerank 分数以及 40% 这些组件的关键性分数。
图 2.5 总结了对于每种类型的样本和每种结果类型，当影响为负时，条目为红色，例如，如果高质量组件更可能包含漏洞。总之，Sonatype MTTU 是识别不太可能包含漏洞的开源项目的最佳指标。
图 2.5 用于评估 OSS 项目相对质量的指标
安全性：与25% 的底部组件相比，具有更快 MTTU 的组件出现漏洞的可能性要低 1.8 倍，并且由于没有前进的道路而陷入脆弱状态的可能性要小得多。
MTTU 和传递依赖：升级响应在解决传递依赖的安全问题时尤为重要。将开源组件合并到应用程序中时，该程序不仅继承了组件的直接代码质量和安全实践，还继承了其依赖项管理方法。新版本的依赖项通常会带来错误修复、安全补丁、新功能和性能改进。
流行度：流行度并不是安全性的良好预测指标。 Libraries.IO Sourcerank 与漏洞有类似的关联，这并不奇怪，因为 Sourcerank 包含多个关注项目受欢迎程度的属性。
微宏观依赖管理相关实践
软件开发人员在 69% 的时间里会在更新第三方依赖项方面做出次优选择。两种类型的决策对于维护健康的软件供应链变得越来越重要：
微依赖决策：开发人员必须频繁作出战术决策，以确定在更新版本时是否更新现有依赖项。
宏观架构决策：软件架构师和工程领导者在决定哪些开源项目最适合自身产品及其原因时必须做出的战略决策。
现代应用程序平均包含 128 个开源依赖项，开源项目平均每年发布 10 次。这一现实，再加上少数超活跃项目每年发布超过 8,000 次的事实，造成了开发人员必须不断确定何时更新其应用程序内的第三方依赖项。
图 3.1 宏架构 VS 微观依赖决策
开发人员知道这很重要，但经常没有时间将其作为优先事项，并且缺乏最佳工具。结果是，尽管更新的版本很容易获得，但应用程序中的依赖项极易变得陈旧易受攻击。
图 3.2 数据分析
Sonatype 研究人员在过去一年中研究了 100,000 个 Java 应用程序并分析了超过 400 万个组件迁移，并开发了一种评分算法（图 3.3），旨在衡量组件迁移决策的相对质量。“组件选择”算法源自从前一章中提炼出的八个常识性规则。
图 3.3 8 个升级到最佳版本的规则
研究结果：
1. Maven Central 生态系统中 10% 的项目正在用于生产应用程序，其中只有 25% 正在积极更新。
2. 升级决策高度可变且经常是次优的
3. 较新的版本通常更好，但并不总是最好的。
发现1：依赖管理是一项大规模的努力，仅在生产应用程序中的 25% 的库上实施。
图 3.4 Maven 中央存储库中的活动项目
发现2：升级是可变的和次优的。研究表明，组织平均每年执行 6,200 次组件迁移，并且 69% 的目标迁移选择是次优的，因其未能确定要升级的最佳版本。迁移决策分为五组，如图 3.5 所示。
图 3.5 5 组迁移
对 100,000 个应用程序和 400 万个更新决策的抽样中，发现 69% 的此类决策是次优的。配备智能自动化，拥有 20 个应用程序开发团队的中型企业将总共节省 160 个开发人员日（1,280 小时）和每年 192,000 美元，满载成本为每小时 150 美元。
图 3.6 智能自动化节省的时间
发现3：新版本并非最优。
为了帮助自动化依赖管理决策，一些包管理器提供了开放式版本范围，一旦最新版本可用，就会立即拉取最新版本。此类更新自动发生，可能会引入不必要的风险。为了实现依赖管理的自动化，出现了更多智能工具来最小化升级风险和升级事件，从而最大限度地提高整体效率。使用图 3.3 中定义的升级规则，最佳选择和最新版本之间存在相关性。
发现 4：依赖管理行为的三种不同模式。
混乱中的团队 ：开发人员缺乏自动化指导，很少更新依赖项，会利用直觉，通常会做出次优的决定。
边缘团队 ：团队开发人员受益于简单但非上下文的自动化。无论最优与否，依赖项会自动更新，但可能会无意中导致安全风险增加。
靠近边缘的团队：开发人员具有智能和上下文自动化的优势。系统会自动推荐依赖项进行更新，但仅在优化时推荐。
结论和实际建议
根据研究，很明显存在重大缺陷和可避免的重大风险。软件工程团队在依赖管理实践方面有相当大的改进空间。
为了提高效率、节省资金并大规模优化依赖项管理，工程领导者应该接受智能自动化。选择的工具应该从日常开发人员工作流程中消除当前容易出错的微决策。
工程领导者还应该使用工具来指导架构师和开发人员在初始技术选择方面做出的宏观决策。
软件供应链法规及标准的出现
1、美国
在 2020 年针对软件供应链的大量攻击之后，美国联邦政府注意到并开始采取行动。
2021年2月
2月开始拜登总统发布了一项行政命令 (EO)，其中列出了保护包括软件在内的所有供应链的变化。同月，国防部 (DoD) 推出了一种新的参考架构，零信任参考架构 (ZTA)。在 ZTA 中，国防部 CIO 概述了各种零信任支柱和能力
2021年4月
当 CISA 和美国国家标准与技术研究院 (NIST) 发布他们的论文“防御软件供应链攻击”时，美国看到软件供应链标准的正式化开始形成，其中两个机构强调在供应链攻击中受损的软件可能“对政府、关键基础设施和私营部门软件客户产生广泛的影响”。他们还指出，这些类型的攻击很容易让不良行为者绕过其他网络防御系统进行网络间谍活动。
2021年5月
2021 年 5 月 拜登这次签署了第二份软件供应链行政命令，作为对国家网络安全态势进行批判性审视的一部分。
2021月6月
根据 EO 的指示，NIST 发布了《关键软件定义》
2021年7月
NIST 发布了概述关键软件使用的安全措施和供应商测试其软件源代码的最低标准的指南。7 月，国家电信和信息管理局 (NTIA) 发布了 SBOM 的最低定义。此外，众议院和参议院都开始在两个独立的委员会中起草立法。
2、英国
2021 年 5 月，英国政府宣布它正在寻求有关防御来自消费 IT 服务的组织或提供软件和服务的 MSP 的数字供应链攻击的建议。同样在 5 月，数字、文化、媒体和体育部 (DCMS) 启动了一项于 7 月初结束的调查，并邀请行业专家和技术组织就加强全英国的供应链安全发表评论。该计划是英国在其国家网络安全战略中制定的全国性“网络弹性”努力的一部分，旨在保护越来越依赖技术的企业和组织免受网络攻击，并加强整体数字供应链安全。
3、德国
2021 年 5 月，德国通过了信息技术安全法案 2.0，作为对第一法案的更新，以“在日益频繁和复杂的网络攻击以及日常生活持续数字化的背景下提高网络和信息安全。”
4、欧盟
2021 年 7 月，ENISA 发布了一份题为《了解供应链安全攻击的增加》的报告，其中审查了 24 种不同的软件供应链攻击以及它们是如何实现的。同时分享了组织应实施的建议。
5、全球正在发生什么
2021 年 5 月，联合国发布了一份由“在国际安全背景下促进网络空间负责任的国家行为政府专家组”历时两年的报告。与国家和地区层面的行动类似，该报告涉及网络安全的几个领域，并就“各国应采取的合理步骤确保供应链的完整性，以便最终用户对信息安全有信心”提供指导 和通信技术 (ICT) 产品。”
2021年6月，美国和欧盟成立了贸易和技术委员会（TTC），为了确保关键技术和软件供应链的安全。据白宫称，TTC“将由工作组组成，重点推进人工智能、物联网和其他新兴技术、信息通信技术安全、数据治理、投资筛选和半导体技术标准方面的合作。”
声明：本文来自天极智库，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
