近十年来，《开源安全和风险分析（OSSRA）报告》的主题一直是“你知道自己的代码中有什么吗？”在2024年，这个问题变得比以往任何时候都更加重要。随着开源的流行和人工智能生成代码的增加，越来越多的应用程序现在使用第三方代码构建。

如果缺乏对代码内容的完整视图，那么无论是企业、供应商还是最终用户都无法确定软件中可能包含哪些风险。而确保软件供应链安全的先决条件是要知道代码中有哪些开源组件，以及确定它们各自的许可证、代码质量和潜在漏洞。

Synopsys最新发布的《2024年开源安全和风险分析（OSSRA）报告》深入研究了商业软件中开源安全、合规性、许可和代码质量风险的当前状态，强调了开源软件的流行以及管理不当的潜在危险，旨在帮助安全、法律、风险和开发团队更好地理解开源安全和许可风险环境。

重点发现

• 96%的代码库涉及开源；
• 53%的代码库包含许可冲突；
• 31%的代码库包含没有许可或自定义许可的开源代码；
• 2023年扫描了1067个代码库，并对936个代码库进行了风险评估，结果显示84%的代码库存在漏洞风险；且在这部分代码库中有高达74%包含高风险漏洞；
• 14%的代码库存在超过10年的漏洞；
• 代码库中漏洞的平均年龄为2.8年；
• 在接受风险评估的代码库中，有49%的组件在过去24个月内没有开发活动；有1%的组件落后于代码维护者更新/补丁至少12个月；有91%的组件比当前版本落后10个或更多版本。

开源漏洞和安全

在Synopsys公司Black Duck 审计服务团队分析的1067个代码库中，96%涉及开源，这些代码库被用作今年OSSRA报告的基础数据。

分析结果显示，在接受风险评估的936个代码库中，有高达84%的代码库至少包含一个已知的开源漏洞。更糟糕的是，在这部分代码库中有74%包含高风险漏洞。这一比例与2022年相比有显著增长，当时只有48%的代码库被发现包含高风险漏洞。这里的“高风险漏洞”指的是那些已被积极利用、已有文档证明的概念验证（PoC）漏洞，或是被归类为远程代码执行的漏洞。

数据显示，2022年至2023年间，高风险漏洞增加了54%，而造成这种情况的原因暂无定论。一个可能的解释是经济衰退和随之而来的裁员，减少了可用于定位和修补漏洞的资源数量。此外，分析还发现91%的代码库所包含的组件比当前可用版本落后10个或更多版本。简单的结论是，绝大多数开源用户根本不更新他们使用的组件。

这一推断也得到了数据证实：49%的代码库组件在过去24个月内没有过开发活动，1%的组件至少落后于代码维护者更新/补丁12个月。

（广义地说，术语“维护者”指的是那些领导开源项目的贡献者。他们可能是构建或发布源代码的最终决策者；可能负责所有的代码审查，并以他们的名义托管较小项目的代码；也可能对项目的方向做出最终决定。他们的日常工作可能有所不同，但都包括审查拉取请求和其他贡献，发布新版本的软件，分类和处理安全修复，以及社区管理和审核。）

大多数维护者都很努力地让他们参与的开源项目保持最新。事实上，许多公司专门雇人来维护公司软件所依赖的开源项目。不过很显然，同样的努力并未体现在开源用户身上。为此，开源用户需要了解他们正在使用的版本，建立一个定期的更新节奏，并落实软件卫生实践。

TOP 10漏洞中有8个与CWE-707有关

【Top 10 CVE大多与CWE-707有关】

如上图所示，CWE-707是CWEs 20、79、80、97、937的支柱。CWE -707关注的是在从上游组件读取数据或发送到下游组件之前未满足的安全要求。如果不能正确中和输入，可能会导致跨站点脚本（XSS）和SQL注入等漏洞利用。XSS是一种常见且危险的漏洞利用，与本报告中突出显示的十大漏洞中的大多数有关。

跨站脚本攻击是指攻击者利用网站的漏洞，发送恶意的、格式错误的代码（通常用JavaScript编写）。由于该输入没有被正确中和或转译，因此攻击者可以操纵原本值得信任的主机执行恶意任务。不过，大多数XSS攻击的最终目标并不是主机本身，而是web应用程序的其他用户。一旦恶意脚本被注入，它就可以用来窃取敏感信息，比如会话cookie。

XSS不仅存在于此份十大漏洞列表中，它也是OWASP十大漏洞列表中的漏洞之一。在其列表中，OWASP将XSS称为A03：2021 -注入。XSS漏洞流行的原因可以归功于越来越依赖基于Web的应用程序作为组织与客户交互的方式。

同样地，数据清楚地表明，开发团队需要在保持开源组件更新方面有所改进，特别是在涉及流行的开源组件（如jQuery）时。使用旧的、更脆弱的开源版本的后果可能是严峻的。例如，在审计中发现的十大漏洞中排名第二的是CVE-2020-11022，这是jQuery 1.2到3.5.0版本中的XSS漏洞。该漏洞允许将受信任来源的HTML传递给jQuery的DOM操作方法，并且可能会执行不受信任的代码。

这个问题在jQuery 3.5.0中得到了修补，但正如研究数据所示，在评估代码库安全风险时，发现三分之一的代码库使用的仍然是易受攻击的jQuery版本。

jQuery并非天生不安全。事实上，它是一个维护良好的开源库，拥有大量的用户、开发人员和维护人员社区。不过，这种流行度和广泛的用户基础也带来了安全问题。根据审计，jQuery是最有可能存在漏洞的组件，尽管本报告中列出的每个jQuery漏洞都有可用的补丁。对于jQuery用户（实际上是所有开源的用户）来说，重要的是要意识到与旧版本软件相关的潜在安全风险，并采取措施缓解这些风险。

采取行动防止漏洞进入软件供应链

• 创建并维护软件物料清单（SBOM）。在与软件供应链攻击的斗争中，拥有一个准确的、最新的、列出开源组件的SBOM是评估暴露并确保代码保持高质量、兼容和安全的关键。全面的SBOM列出了应用程序中的所有开源组件，以及这些组件的许可证、版本和补丁状态——这是对供应链攻击（包括使用恶意包的攻击）的有力防御。
• 随时了解情况。确保能够及时了解新发现的恶意软件包、恶意软件和公开的开源漏洞。查找新闻提要或定期发布的建议，获悉有关影响SBOM中开源组件的问题的可操作建议和详细信息。
• 执行代码审查。在将下载的软件纳入项目之前，先仔细检查它的代码以获悉任何已知的漏洞。要了解更多信息，请考虑对源代码进行静态分析，以检查未知的安全弱点。
• 使用自动化软件组合分析（SCA）工具。SCA工具自动化了软件安全问题的识别、管理和缓解过程，并允许开发人员将精力集中在编写代码上。这样的工具可以评估开源代码和第三方代码。

行业漏洞风险

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

每个行业都有类似的发现，即使是航天、航空、汽车、运输、物流等占比最低的行业同样令人不安，因为这些行业仍有三分之一的代码库包含高风险漏洞。如下图所示，接受评估的每个行业代码库中都涉及开源；它构成了每个行业部门的大部分代码库。更糟糕的是，这些代码库还包含大量已知的开源漏洞，这些漏洞未得到及时修补，使其非常易被滥用。

【代码库中包含高危漏洞的行业比例】

开源许可

有效的软件供应链管理需要许可以及安全遵从性。企业正在使用开源组件和库来构建软件，并且知道这些组件受开源许可证的管理，但是企业知道这些许可证的详细信息吗？要知道，即使软件中有一个不兼容的许可证也会导致法律问题、知识产权损失、耗时的补救工作以及产品延迟上市等后果。Black Duck审计服务团队发现，在接受审计的代码库中，超过一半（53%）涉及许可冲突问题。

【代码库中发现的TOP10许可比例】

在Black Duck审计服务团队于2023年审计的开源软件中，有92%的开源软件使用了MIT许可证。作为一个允许在专有软件中重用的宽松许可证，MIT许可证与其他软件许可证具有高兼容性和低风险。

应该注意的是，诸如“低风险”这样的术语只是一个指导原则，不应该用来决定是否使用每个许可证管理的开源软件。例如，虽然Apache 2软件（通常被认为使用低风险许可证）可以包含在GNU通用公共许可证3.0（GPLv3）下的项目中，但GPLv3软件不能包含在Apache项目中。在这种情况下，由于Apache软件基金会的许可哲学和GPLv3作者对版权法的解释，许可证是不兼容的。对于开发人员来说，最安全的策略是咨询他们的公司政策和法律团队，以获得有关许可证遵从性的具体指导。

调查发现，知识共享许可是导致许可冲突最普遍的原因。仅CC-SA 3.0就导致了17%的已确定的许可冲突。

“代码片段”（Snippets）——被复制粘贴到源代码中的代码行到处可见。它们通常来自流行的博客网站Stack Overflow，该网站自动将所有可公开访问的用户贡献以知识共享方式分享。不幸的是，“一揽子许可”（blanket license）还包括发布在网站上的代码片段。我们说“很遗憾”，因为这些许可协议不是针对软件的，这一点在其常见问题中有明确的说明：“我们建议不要对软件使用知识共享许可协议。”在某些情况下，CC-SA许可证可以被理解为具有与GNU公共许可证类似的“病毒”效应（即，从copyleft许可的作品派生的任何作品也必须在相同的copyleft条款下进行许可），而且从法律角度来看，这可能会成为一个问题。

了解许可证风险

在美国和许多其他司法管辖区，创造性作品（包括软件）默认受独家版权保护。没有创作者/作者的明确许可，任何人都不能合法地使用、复制、分发或修改该软件。

即使是最友好的开源许可证也包括用户在使用该软件时所承担的义务。当代码库所涉开源代码的许可与代码库的整体许可发生冲突时，潜在的许可风险就会出现。GNU通用公共许可证（GPL）是应用于开源项目的最常见的copyleft许可证。当以GPL许可的代码包含在商业闭源软件中时，可能会出现冲突。

标准开源许可证的变体或定制版本可能对被许可方提出要求，并且需要对可能的知识产权问题或其他影响进行法律评估。JSON许可证是自定义许可证的一个主要示例。基于宽松的MIT许可证，JSON许可证增加了“软件应用于善，而非恶”的限制。这一声明的模糊性使其含义有待解释，许多律师会建议不要使用如此许可的软件，特别是在并购场景的背景下。

在接受审计的代码库中，有31%使用的代码要么没有可识别的许可，要么使用定制的许可，这与去年的调查结果几乎相同。造成这种情况的一个常见原因是开发人员使用代码片段，但却没有带来代码片段的相关许可。另一个原因是越来越多地使用AI辅助编码工具。

【包含许可冲突的代码库比例（按行业划分）】

如上所示，多个行业部门具有非常高比例的开源许可风险。造成这种情况的原因可能包括以下几点：

• 许多存在大量冲突的行业倾向于将其软件作为本地产品进行许可和分发。许多限制性许可证专门适用于以这种方式分发的软件。其他数量较少的行业可能会进行基于订阅或SaaS类型的部署，这些部署传统上不被认为是“分发”，也不受相同许可条款的约束。
• 半导体和硬件公司严重依赖软件和固件，其中大部分包含开源代码。复杂的片上系统（system-on-a-chip）设计可能有来自不同来源的数百万行代码。在这种规模上跟踪许可和义务可能是一项挑战。
• 开源在底层系统软件、固件、驱动程序中非常普遍，这些都是硬件产品不可或缺的一部分。其中大部分都是在GPL类型的“copyleft”许可下进行的，如果发布，则有很强的共享要求。
• 固件、驱动程序和工具在公司之间以及硬件设计师和制造商之间的软件供应链共享导致了开源传播，无需通过SBOM清单跟踪来源或许可。

软件供应链治理中开源许可证管理的最佳实践

• 对软件中的所有第三方软件组件（包括开源软件和商业软件）进行彻底的盘点。
• 人工智能辅助编码工具可能会产生违反许可和侵犯知识产权的代码。
• 评估每个组件的许可条款和条件，并评估它们是否与产品的预期用途兼容。
• 检查不同组件的许可之间的兼容性，因为有些组件的许可可能不兼容。
• 使用自动扫描工具来识别和跟踪每个组件的许可义务和限制。
• 实施一个流程，以确保持续的许可合规性，包括定期的许可证扫描和许可证合规程序的定期审查。
• 为新的或不熟悉的许可证建立审查流程和工作流程。
• 确保法律、技术和业务利益相关者之间的有效沟通，以适当地优先考虑和执行许可清除。
• 记录所有许可证审批活动，包括许可证评估和合规程序，以确保合规工作的记录，并为未来的审核提供便利。

影响开源风险的操作因素

理想情况下，开源消费者只使用安全的社区支持的组件。例如，来自数百个组织的数千名开发人员每天都在改进Linux。然而，在Black Duck审计服务团队检查的936个代码库中，49%的开源代码在过去两年中没有过开发活动。如果一个项目不再被维护——特别是在较小的项目中——就没有功能升级，没有代码改进，也无法修复发现的安全问题。

这在开源项目中并不少见。根据一些报告，在2022年维护的近20%的Java和javascript开源项目将在2023年不再维护，这使得这些项目易受漏洞影响。开源很大程度上是志愿者、贡献者和维护者的产物。虽然像微软、红帽和谷歌这样的一些组织有激励计划来激励开源项目的维护和参与，但绝大多数公司都没有。当维护人员停止维护项目时，一个显而易见的后果就是安全风险会随之升高。

开源用户需要改进维护实践

在Black Duck审计服务团队检查的936个代码库中，91%的组件比最新版本落后10个或更多版本。

造成这种情况的原因可能是时间/资源的问题。由于许多团队都在把主要精力用于构建和测试新代码，因此更新现有软件的优先级可能会降低。Synopsys《2023年全球开发安全运营状况》报告发现，在对1000名IT安全专业人士的调查中，28%的人表示他们的组织需要长达三周的时间来修补已部署应用程序中的关键安全风险/漏洞，另有20%的人表示可能需要长达一个月的时间。这些数字适用于所有的漏洞，包括专有的、商业的、第三方的软件以及开源软件。

正如OSSRA在近十年的报告中所指出的那样，开源不同于商业软件——不是更差，也不是更好，而是不同——而且它需要不同的技术来管理。例如，商业软件和开源软件的补丁处理方式就大不相同。作为供应商管理计划的一部分，购买商业软件通常需要进行一些审查。另一方面，开源代码可能只是根据开发人员的判断下载的，在此过程中可能会有一些组织防护措施——例如，只使用具有许可许可的代码——但是在许多组织中，甚至不存在这样的指导。

商业软件会定期将补丁和更新“推送”到组织的软件中，或者至少供应商会发布更新（通常是紧急更新）可供下载的通知。但对开源代码来说，这种情况很少发生。为此，企业需要一个准确、全面的开源清单，以及自动化的过程来监控软件中的漏洞、升级和开源的整体健康状况。

结语与建议

无论是独立开发人员还是大公司，为了降低风险，每个人都有责任维护软件供应链安全实践。随着软件供应链攻击数量的增长，有效地管理开源代码的使用、组件和依赖关系对于管理风险变得更加关键。所有组织都应该主动管理开源风险，并将其作为安全软件开发实践的一部分。

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

• 使用与内部开发组件相同的策略和流程，将开源集成到产品的安全构建过程中。安全团队通常定义有关开源代码的安全策略、流程和工具。理想情况下，开发人员会从一个受保护的内部存储库中选择一个具有所需功能的组件，该存储库通过SCA安全分析工具进行了初步的漏洞评估，然后在开发和/或构建阶段运行进一步的扫描，以尽早捕获问题。
• 跟踪更新的开源和监控的问题和漏洞。当识别出漏洞时，应评估受影响的软件，以确定组件的流行程度及其在产品中的使用情况。组件应该及时得到更新，或者，如果它不再被维护，应该考虑寻找一个替代的解决方案。
• 使用SBOM。了解软件中包含哪些组件对于准确和完整地管理代码至关重要。SBOM是包含软件中组件的细节和供应链关系的正式记录。在漏洞管理上下文中，SBOM支持漏洞的识别和修复。从代码质量的角度来看，SBOM的存在可能表明供应商在整个软件开发生命周期中使用了安全的软件开发实践。

原文链接：

https://www.synopsys.com/software-integrity/engage/ossra/ossra-report