• 持续存在的开源安全问题

• 为什么开发人员需要改进以保持开源组件的更新

• 软件供应链管理需要软件物料清单 (SBOM)

• 如何防范人工智能编码工具带来的安全和 IP 合规风险

近十年来，“开源安全与风险分析”（OSSRA）报告的主要主题一直是“您知道您的代码里有什么吗？”在 2024 年，这个问题比以往任何时候都更加重要。随着开源的普及和 AI 生成代码的兴起，现在越来越多的应用程序是用第三方代码构建的。

如果不能全面了解代码中的内容，您、供应商和最终用户都无法确定软件可能包含哪些风险。保护软件供应链首先要了解代码中包含哪些开源组件，并确定它们各自的许可证、代码质量和潜在漏洞。

2024 年 OSSRA 报告已发布第九版，深入探讨了商业软件中开源安全、合规、许可和代码质量风险的现状。本报告提出研究结果的目的是帮助安全、法律、风险和开发团队更好地了解开源安全和许可风险状况。

本报告使用的数据来自 Black Duck® 审计服务团队对 2023 年 17 个行业 1,067 个商业代码库的匿名调查结果的分析。审计服务团队 20 多年来一直帮助世界各地的安全、开发和法律团队加强其安全和许可合规计划。该团队每年为我们的客户审计数千个代码库，主要目的是在并购 (M&A) 交易期间识别软件风险。

审计还提供了全面、准确的软件物料清单，涵盖了组织应用程序中的开源、第三方代码、Web 服务和应用程序编程接口 (API)。审计服务团队依靠 Black Duck KnowledgeBase™ 中的数据来识别潜在的许可证合规性和安全风险。该 KnowledgeBase 由 Black Duck 网络安全研究中心 (CyRC) 提供和整理，包含来自 31,000 多个锻造厂和存储库的 780 多万个开源组件的数据。

OSSRA 报告强调了开源在软件中的普遍性以及管理不善的潜在危险。开源是当今企业和消费者所依赖的所有应用程序的基础。有效地识别、跟踪和管理开源对于成功的软件安全计划至关重要，也是加强软件供应链安全的关键要素。

jQuery 并非天生就不安全。事实上，它是一个维护良好的开源库，拥有庞大的用户、开发人员和维护者社区。但问题往往伴随着流行。根据审计结果，jQuery 是最有可能存在漏洞的组件，尽管本报告列出的每个 jQuery 漏洞都有可用的补丁。对于 jQuery 用户（事实上是所有开源用户）来说，重要的是要意识到与旧版本软件相关的潜在安全风险，并采取措施减轻这些风险。

CWE 项目将“支柱弱点”定义为最高级别的弱点，代表与其相关的所有类/变体弱点的基础。

国家漏洞数据库 (NVD) 等公共资源是获取有关开源软件中公开披露的漏洞信息的良好开端。但任何给定的 NVD CVE 条目的报告都可能存在滞后。及时性一直是影响 NVD 公布安全漏洞数据能力的一个因素。事实上，漏洞的首次披露与其在 NVD 中发布之间通常存在显著的时间滞后，一些研究报告称，首次公布和 NVD 发布之间平均间隔一个月。

NVD 的另一个问题是它提供的漏洞数据通常不完整。NVD 中发布的许多 CVE 都不包含易受攻击的版本范围，而且通常太短而无法使用。这通常是因为没有资源可用于研究该条目。

显然，仅依赖 NVD 来获取漏洞信息是不明智的。许多商业 SCA 解决方案可以提供比 NVD 更丰富的漏洞数据，此外还可以更准确地发现问题并在必要时帮助您更快地修复问题。例如，如果您使用的是 Black Duck 的 SCA 解决方案 Black Duck，则可以利用 BDSA，这是 Black Duck 安全研究团队发现的开源漏洞的公告。这些公告通常会提前通知影响您代码库的漏洞 - 可能需要几天或几周的时间才能出现在 NVD 中。BDSA 还提供更完整的漏洞数据，提供安全洞察、技术细节和升级/补丁指南，这是当今商业上任何其他产品都无法比拟的。例如，在我们 2023 年的十大漏洞列表中，有三个来自 NVD 的没有相关 CVE 的 BDSA。

与计算机硬件和半导体行业相关的代码库中有 88% 包含被归类为高风险的漏洞（严重程度评分为 7 或更高），紧随其后的是制造业、工业、机器人；以及零售和电子商务，分别为 87% 和 84%。

各个行业都有类似的发现。即使是最低比例的航空航天、航空、汽车、运输、物流行业也令人不安，该行业三分之一的代码库包含高风险漏洞。如图 1 所示，我们检查的每个行业代码库中都有开源；它构成了每个行业部门的大部分代码库。图 3 表明，这些代码库还包含大量已知的开源漏洞，组织未能修补这些漏洞，导致它们容易受到攻击。

2023 年，Black Duck 审计服务审计的 92% 的开源软件都采用了 MIT 许可证。作为允许在专有软件中重复使用的宽松许可证，MIT 许可证与其他软件许可证具有很高的兼容性和较低的风险。您可以相当肯定，如果您在软件中包含第三方组件，您很可能会找到流行的宽松许可证，例如 MIT、Apache、BSD、ISC 和 Unlicense。

需要注意的是，“低风险”等术语只是一种指导原则，不应用来决定是否使用受每个许可证约束的开源软件。例如，尽管 Apache 2 软件（通常被认为使用低风险许可证）可以包含在根据 GNU 通用公共许可证 3.0 (GPLv3) 许可的项目中，但 GPLv3 软件不能包含在 Apache 项目中。由于 Apache 软件基金会的许可理念和 GPLv3 作者对版权法的解释，在这种情况下许可证是不兼容的。最安全的策略是让开发人员咨询其公司政策和法律团队，以获得有关许可证合规性的具体指导。

2023 年的审计发现，知识共享许可是导致许可冲突的最普遍原因。仅知识共享 ShareAlike 3.0 (CC-SA 3.0) 就占到已发现许可冲突的 17%。

Black Duck 审计经常会发现“代码片段”——被复制并粘贴到源代码中的代码行。它们通常取自流行的博客网站 Stack Overflow，该网站自动根据知识共享 ShareAlike 为所有可公开访问的用户贡献内容提供许可。不幸的是，综合许可还涵盖了网站上发布的代码片段。我们说“不幸的是”，因为这些许可不适用于软件，知识共享在其常见问题解答中明确指出了这一点：“我们建议不要将知识共享许可用于软件。”在某些情况下，CC-SA 许可可以理解为具有与 GNU 公共许可类似的“病毒式”效应（即，任何从版权左派许可作品衍生的作品也必须根据相同的版权左派条款获得许可），并且可能从法律角度引起担忧。

了解许可证风险

在美国和许多其他司法管辖区，创意作品（包括软件）默认受专有版权保护。未经创作者/作者以许可证形式明确许可，任何人都不得合法使用、复制、分发或修改该软件。

即使是最友好的开源许可证也包括用户使用该软件所承担的义务。当代码库包含的开源许可证似乎与代码库的整体许可证相冲突时，就会出现潜在的许可证风险。GNU 通用公共许可证 (GPL) 是应用于开源项目的最常见的版权左派许可证。当根据 GPL 许可的代码包含在商业闭源软件中时，可能会出现冲突。

标准开源许可证的变体或定制版本可能会对被许可人提出不受欢迎的要求，并要求对可能的知识产权问题或其他影响进行法律评估。JSON 许可证是定制许可证的一个典型例子。基于宽松的 MIT 许可证，JSON 许可证增加了“软件应用于善，而非恶”的限制。这句话的模糊性使其含义有待解释，许多律师建议不要使用这种许可的软件，尤其是在并购场景中。

2023 年审计的代码库中有 31% 使用的代码要么没有可辨别的许可证，要么有自定义许可证，与去年的调查结果几乎相同。开源审计发现来自网站的代码片段并不罕见，这些网站与 Stack Overflow 不同，没有可辨别的服务条款或提及软件条款。开源代码没有许可条款的另一个常见原因是开发人员使用代码片段但未能随附代码片段的相关许可证。没有相关许可证的代码的另一个问题是人工智能辅助编码工具的使用越来越多（请参阅下一节）。

在 Black Duck 审计服务团队于 2023 年检查的 936 个包含风险评估的代码库中，91% 的代码库所含组件的最新版本落后 10 个或更多版本。

开源用户不更新开源组件是有充分理由的。如果他们意识到这种情况（不幸的是，很多人没有意识到），开发团队可能会认为意外后果的风险大于应用新版本带来的好处。例如，嵌入式软件可能面临最小的漏洞风险，而这些漏洞只能从外部来源引入。

或者可能是时间/资源问题。由于许多团队已经竭尽全力构建和测试新代码，除了最关键的问题外，对现有软件的更新可能会成为较低的优先级。Black Duck“2023 年全球 DevSecOps 状况”报告发现，在对 1,000 名 IT 安全专业人士的调查中，28% 的人表示他们的组织需要长达三周的时间来修补已部署应用程序中的关键安全风险/漏洞，另有 20% 的人表示可能需要长达一个月的时间。这些数字适用于所有漏洞——专有、商业和第三方软件以及开源软件。

正如近十年的 OSSRA 报告所指出的那样，开源软件不同于商业软件——不是更差，也不是更好，而是不同——并且需要不同的技术来管理。例如，商业软件和开源软件的补丁处理方式截然不同。购买商业软件通常需要一些审核，作为供应商管理计划的一部分。另一方面，开源软件可能只是由开发人员自行决定下载。可能有一些组织护栏——例如，只使用具有宽松许可证的代码——但在许多组织中，甚至连这种指导都不存在。

所有使用商业软件的组织都熟悉“推送”到其软件中的补丁和更新，或者至少会收到供应商的通知，告知有更新（通常是紧急更新）可供下载。开源软件很少出现这种情况，因为开源软件消费者需要随时了解组件的状态，并在新版本可用时下载。

只有一个可行的解决方案可以了解您使用的开源版本。您需要一份准确、全面的开源清单，以及自动化流程来监控软件中的漏洞、升级和开源的整体健康状况。

无论是单个开发人员还是大型公司，每个人都有责任维护软件供应链安全实践，以降低风险。随着软件供应链攻击数量的增加，有效管理开源使用、组件和依赖关系对于管理风险变得更加重要。将开源纳入其产品的组织（正如本报告所示，实际上是所有组织）应主动管理开源风险，作为其安全软件开发实践的一部分。

美国网络安全和基础设施安全局于 2023 年底发布的《保护软件供应链：管理开源软件和软件物料清单的推荐做法》为软件供应链中使用开源提供了详细指南，包括

• 使用与内部开发组件相同的策略和流程将开源集成到产品的安全构建过程中。
  安全团队通常定义有关开源的安全策略、流程和工具。理想情况下，开发人员将从预先审查的内部存储库中选择具有所需功能的组件，该存储库已通过 SCA 安全分析工具进行了初步漏洞评估，然后在开发和/或构建阶段运行进一步扫描，以尽早发现问题。

• 跟踪开源更新并监控问题和漏洞。
  当发现漏洞时，应评估受影响的软件以确定组件的普遍性及其在产品中的使用情况。应更新该组件，或者，如果不再维护该组件，则应认真考虑寻找替代解决方案。

• 使用 SBOM。
  了解软件中包含哪些组件对于准确、完整地管理代码至关重要。SBOM 是一种正式记录，其中包含软件中组件的详细信息和供应链关系。SBOM 可提高软件透明度并记录组件来源。在漏洞管理的背景下，SBOM 支持漏洞的识别和修复。从代码质量的角度来看，SBOM 的存在可能表明供应商在整个软件开发生命周期中都使用了安全的软件开发实践。

行政命令 (EO) 14028“改善国家网络安全”规定，可以要求组织直接向购买者提供 SBOM 或将其发布在公共网站上，并且可能要求政府和非政府方审查 SBOM，以确保软件产品符合 SBOM 的最低要素。行政命令还指示商务部和国家电信和信息管理局 (NTIA) 发布“软件物料清单 (SBOM) 的最低要素”，其中概述了 SBOM 所需的活动和数据以及满足 SBOM 要求的示例格式。SPDX 和 CycloneDX 被确定为两种最广泛使用的机器可读 SBOM 格式。2023 年中，管理和预算办公室 (OMB) 发布了备忘录 OMB-23-16，更新了早期的 OMB 备忘录，该备忘录允许联邦机构要求

• 根据软件关键性或其他标准制定 SBOM，具体标准由各机构确定

• 采用 NTIA 定义的格式之一的 SBOM

软件生产商在确保软件供应链安全以造福客户和用户方面发挥着关键作用。美国国家标准与技术研究院 (NIST) 的安全软件开发框架 (SSDF) 提出了一系列实践，作为以标准化方式安全开发软件的基准。美国政府已表示，所有直接或间接采购的软件都必须符合 NIST SSDF 认证，软件供应商很可能需要在不久的将来自我证明其遵守了 SSDF。

诸如 Black Duck SSDF 准备情况评估之类的评估工具可以确定贵组织的软件开发实践是否符合 SSDF 的实践和任务，以便您可以自信地证明您的软件开发流程符合 SSDF 标准。同样，Black Duck SBOM 服务以 Black Duck 审计服务流程为基础，对您的软件进行全面的安全审计并生成 SBOM — 对于尚不具备 SBOM 生成能力且需要基准 SBOM 的组织来说，这是一项有价值的服务。

承担监管或合同义务的软件生产商可能会收到审核 SBOM 的请求。软件消费者可能希望审核其供应商之一制作的 SBOM。在每种情况下，都需要一个在软件审核方面享有盛誉的可信赖第三方。Black Duck SBOM 审核和验证服务基于这些经过验证的流程来审核软件并确认客户制作的 SBOM 是否准确反映了供应链。

回顾报告结果

• 在 1,000 多个已扫描的代码库中，96% 包含开源代码

• 77% 的源代码和文件源自开源

• 53% 的代码库存在开源许可证冲突

• 经安全风险评估的代码库中，84% 存在漏洞；74% 存在高风险漏洞

• 91% 的代码库中的组件比最新版本落后 10 多个版本

无论您的组织是开发还是使用软件，几乎可以肯定它拥有开源组件。您确切知道这些组件是什么，以及它们是否会带来安全或许可风险吗？在 2024 年的世界里，96% 的代码被发现包含开源，代码的可见性需要成为优先事项。当 91% 的风险评估代码库使用的开源远远落后于当前版本时，消费者需要更好地保持其代码的更新，尤其是在流行的开源组件方面。

保持开源更新应与团队开发的代码具有同等的优先级。创建并维护 SBOM，详细说明代码中包含的内容，包括版本、许可证和出处的详细信息。设置定期升级的节奏，尤其是当您使用来自维护者频繁的热门项目的开源库时。

如果无法全面了解代码并保持主动的软件卫生实践，您的软件就会面临开源漏洞和 IP 合规性问题的潜在攻击。首先使用自动化 SCA 工具在 SDLC 早期发现安全性、代码质量和许可问题 — 因为您需要毫无疑问地了解代码中的内容。

关于黑鸭子

Black Duck® 提供业界最全面、最强大、最值得信赖的应用程序安全解决方案组合。我们在帮助世界各地的组织快速保护其软件、在其开发环境中高效集成安全性以及安全地利用新技术进行创新方面拥有无与伦比的业绩记录。作为软件安全领域公认的领导者、专家和创新者，Black Duck 拥有您建立对软件的信任所需的一切。
了解更多信息，请访问 www.blackduck.com。

©2024 Black Duck Software, Inc. 保留所有权利。Black Duck 是 Black Duck Software, Inc. 在美国和其他国家/地区的商标。Black Duck 商标列表可在www.blackduck.com/company/legal.html上找到。本文提及的所有其他名称均为其各自所有者的商标或注册商标。2024 年 2 月

代码库组成应用程序或服务的代码和相关库。

二进制分析一种静态分析，用于在无法访问源代码时识别应用程序的内容。

连续水气管道常见弱点枚举 (CWE) 是社区开发的软件和硬件弱点类型列表，分为三个层级。CWE 有 600 多个类别，包括缓冲区溢出、路径/目录树遍历错误、竞争条件、跨站点脚本、硬编码密码和不安全随机数等类别。

漏洞漏洞常见漏洞和暴露 (CVE) 是公开披露的信息安全漏洞的列表。

黑鸭安全警告（BDSA）BDSA 提供有关开源漏洞的详细、及时、一致的信息，为 Black Duck 客户提供开源漏洞的早期和补充通知以及升级/补丁指南。BDSA 提供当日漏洞通知、可操作的缓解指南和解决方法信息、严重性评分、参考资料等。

软件组件开发人员可以添加到其软件中的预编写代码。软件组件可能是一种实用程序（例如日历功能）或支持整个应用程序的综合软件框架。

依赖当其他软件使用某个软件组件时（即当软件依赖于该组件时），该软件组件将成为依赖项。任何给定的应用程序或服务都可能有许多依赖项，而这些依赖项本身可能依赖于其他组件。

片段代码片段是开发人员剪切并粘贴到自己的代码中的小段可重复使用的代码。尽管软件可能只包含一段开源代码，但软件用户仍必须遵守与该代码片段相关的任何许可证。

开源许可证一组条款和条件，规定最终用户义务，包括在软件中使用开源组件（或组件代码片段）时如何使用和重新分发组件。大多数开源许可证分为两类。

许可证宽松许可证允许使用时几乎没有限制。通常，这种许可证的主要要求是将原始代码归属于原始开发者。

版权许可版权左派许可证通常包含互惠义务，规定修改版和扩展版的发布条款和条件与原始代码相同，并且必须根据请求提供包含更改的源代码。商业实体对在其软件中包含版权左派许可证的开源软件持谨慎态度，因为其使用可能会引起整个代码库的知识产权问题。

软件组成分析（SCA）一种应用程序安全工具，用于自动化开源软件管理流程。SCA 工具集成在软件开发生命周期中，用于识别代码库中的开源、提供风险管理和缓解建议以及执行许可证合规性验证。

软件物料清单 (SBOM)代码库中软件组件和依赖项的综合清单，通常由软件组成分析工具生成。正如美国国家电信和信息管理局 (National Telecommunications and Information Administration) 所言，“SBOM 应包括软件组件和依赖项的机器可读清单、有关这些组件的信息及其层次关系。”由于 SBOM 旨在跨公司和社区共享，因此拥有一致的格式（即人机可读）和一致的内容至关重要。美国政府指南目前指定两种标准作为批准格式，即软件包数据交换 (SPDX) 和 CycloneDX。