赛迪译丛2025年第4期（总第679期）：给CISA主任的报告：开源安全加水印

2025年2月10日第4期总第679期 给CISA主任的报告：开源安全 【译者按】2024年10月，美国网络安全和基础设施安全局（CISA）网络安全咨询委员会（CSAC）下设的技术咨询委员会（TAC）小组委员会发布《给CISA主任的报告：开源安全》。报告认为，开源软件已在政府部门、关键基础设施和公共生活中得到广泛应用，其漏洞将对下游的行 业领域产生广泛影响，各国政府均已高度重视开源安全。报告围绕开源软件安全消费规范、安全消费规范鼓励措施、引导商业公司承担开源安全责任以及维护人工智能开源安全四个问题，分别开展研究并提出建议。赛迪智库信息化与软件产业研究所对报告进行了编译，期望对我国有关部门有所帮助。 【关键词】开源软件开源安全安全消费规范商业公司人工智能 一、前言 美国网络安全和基础设施安全局（CISA）网络安全咨询委员会（CSAC）于2021年6月正式成立。该委员会是一个独立的咨询机构，围绕CISA网络安全使命相关的政策、计划、规划和培训的制定、完善和实施，定期向CISA提供独立的、战略性的、可操作的建议、咨询及报告。CISA网络安全咨询委员会下设5个小组委员会，其中技术咨询委员会（TAC）小组委员会主要提供技术相关的咨询，如内存安全、漏洞挖掘和披露等。 报告是TAC小组委员会围绕“开源安全”主题的最新报告。近年来，与软件漏洞相关的安全事件持续出现，既涉及商业软件也涉及开源软件，其中不乏高影响和高知名度的漏洞。日益复杂的软件供应链和软件依赖关系已成为犯罪组织和一些国家的常见攻击目标，软件安全问题已经引起全世界的关注。随着大国竞争升级，以开源软件生态系统为目标的情况预计仍会增加。在这种环境下，倘若忽视软件依赖性安全性的现状，将难以提供抵御这些威胁因素以及让公众从开源软件获益所必需的弹性、保障或稳定性。 CISA于2023年启动“设计安全”计划，以提高商业软件的安全性。“设计安全”计划旨在提高认识、提供指导并建立自愿标准，将软件缺陷视为不遵循安全设计原则的可预测结果，而非 现代软件开发生命周期的不可避免的结果。小组委员会认为这是一个可喜的转变。 相比而言，提高商业软件安全性的途径较为简单，因为它对所有“正常的”市场和法规激励，如市场份额和责任做出了反应。而针对开源软件安全性的保障更为复杂。开源软件处于一个由社区项目、个人贡献者和商业开发者共同驱动的环境中，通常支持他们的产品所依赖的开源软件组件。开源软件的许可证协议中普遍包括保证免责声明条款，规定开源软件“按原样”提供，即贡献者和许可方不对软件的质量、性能或适用性作任何保证。资金不足的开源软件非营利基金会可能难以支付开发费用，“免费增值”商业模式不足以满足需求。例如，F5公司旗下广受欢迎的网络服务器Nginx不仅作为企业产品出售，同时还提供免费的社区版。许多创新来自社区，但有在企业版中才能得到整合和支持。“免费版企业版”的分层结构是增加市场份额和产品曝光度的常用方法。但是，如果安全改进仅在高级版或企业版中可用，人们可能会出于节省成考虑而使用安全性较低的版 ，从而损害生态的整体安全性。 报告围绕CISA关心的四个问题分别开展研究并提出相应建议。一是开源软件的安全消费应遵守的规范，包括与上游社区最新版保持一致、用户对软件的修改反馈给上游社区等。二是 从政府角度，鼓励安全消费规范的具体措施，如采购、感知、信息交换所、集中管理等。三是引导商业公司承担更多开源软件安全责任，包括采用管理员模式、推行标准化自动化模板等。四是人工智能系统的开源安全和风险防范，政府使用人工智能大模型应格外谨慎，并应从透明度、可审计性、可重现性等层面衡量并维护人工智能安全。 二、研究背景：开源软件 在过去的几十年里，开源软件得到广泛使用，重要性持续增加，现在已经融入到社会各个方面，创造了大约8万亿美元的总价值。开源软件不仅在计算和在线服务中发挥重要作用，而且在电信、科学、工业控制系统（ICS）、操作技术（OT）和各级政府中发挥着关键作用。根据软件供应链状况报告，大约8090的软件是开源的，或者包含开源组件。但在开源软件应用日益广泛的趋势下，软件缺陷和漏洞的后果比过去严重得多，供应链攻击的频率和范围也在不断扩大。共享的软件、工具、供应链和制造商意味着一小段代码中的缺陷会产生广泛的、不可预见的影响。软件开发通过将成千上万个小的、刚性的部分连接起来形成复杂系统，因此任何一个部分的缺陷和问题都会导致整个系统的崩溃。 美国政府、非政府组织和商业公司一直致力于开源安全的维护。政府层面，美各部门为应对关键基础设施对开源软件日益增 长的依赖，已实施多项举措。联邦政府在白宫内设立了国家网络主任办公室（ONCD），出台了开源软件国家战略。美国国土安全部（DHS）组建了网络安全和基础设施安全局以及网络安全审查委员会以研究开源软件。2023年12月，美国网络安全和基础设施安全局、国家安全局等多个政府部门联合发布《保护软件供应链安全：关于开源软件及软件物料清单使用的推荐实践》。开源组织层面，开放软件安全基金会（OpenSSF）接连发布多项有关开源软件安全的指南，其安全软件存储库工作组与CISA联合开发“软件包存储库安全原则”框架。企业层面，微软将其主导的“安全供应链消费框架”（S2C2F）共享给OpenSSF，谷歌Go语言团队的专家发布《幸存的软件依赖关系》研究报告等。另外，欧盟也制定了《网络弹性法案》（CRA），该法案于2024年3月由欧洲议会正式批准，旨在通过网络安全法规和潜在责任来提高软件的安全性。 （一）开源安全要解决两个核心问题和一个基本问题 在理解开源软件消费的风险时，会遇到两个核心问题。第一，最终用户和软件开发人员想使用某个开源软件时，需再引入哪些开源软件才能保障系统的正确运行。第二，确定所需要的各种开 源软件组件的版。 在解决两个核心问题的过程中，仍需解决一个基问题。即 如何弥合商业消费者的法律合同驱动的规范和开源软件开发商的社会合同驱动的文化规范之间的差距。开源软件生态是由不同的开发者组成的，有些是有偿的，但更多的是无偿的。公司通常依靠法律合同的可执行性来定义和执行规范。然而，开源软件生态通常基于社区驱动的价值观来激励发展，如声誉、道德或个人发展。这导致难以硬性要求志愿开发者按照公司的安全关键规范要求做出及时、有效的响应。 （二）需要承担开源安全责任的中介“管理员” “管理员”角色可解决开源软件消费缺乏安全责任人的根挑战。一方面，“按原样”提供的开源软件不作任何安全或质量保证，开源软件生产者或维护者在法律上并不具有保障安全的义 务。另一方面，政府和其他机构对软件的生产者提出各种高标准的要求，其中包括确保软件安全性的责任。为此，需要第三方“管理员”的加入，作为开源软件的生产者和消费者之间的中介，以满足消费者安全使用开源软件的需求。 消费者自身、开源软件社区、企业内部团队、政府机构、商 业公司等都可以扮演“管理员”角色。当消费者直接使用开源软件时，消费者自身承担了保障软件安全的“管理员责任”。部分开源项目的社区也承担了安全责任，例如FreeBSD项目的社区决 定遵循安全软件开发框架（SSDF），从而提供更为安全的软件产 品。企业内部，集中管理开源软件包的团队担任了管理员角色，通常为其他部门或团队提供安全补丁管理等服务。美国政府中，由指定的机构扮演管理员角色，为其他机构以及州、地方、部落和地区政府服务。。另外，也存在一些外包服务公司提供管理员服务，例如红帽公司（RedHat）以各种支持承诺销售Linux，在消费者眼中红帽公司就是负责任的生产者。 虽然尚处于起步阶段，管理员的外包对开源安全的提升至关 重要。外包管理员更为专业、更具规模化，并可以从专业化和规模化中获得显著的好处，工具的改进和人工智能的使用将进一步增加外包管理员的相对优势。另外，外包管理员利用标准化机制、 减少重复工作，可加速相关的标准或规范的采用，以解决开源软件消费决策中因缺乏标准而无法衡量软件保障级别、运营供应链安全、软件可认证性等问题。 （三）应推动采用软件物料清单和软件工件供应链级别 为确保开源安全消费，CISA应该推动采用软件物料清单 （SBOM）和软件工件供应链级别（SLSA），并建立SBOM和SLSA两种认证的互操作性格式。理想情况下，可由管理员确保软件包产生高质量的元数据（包括可互操作的SBOM、签名的SLSA出处信息等），并以可组合的方式交付。 软件物料清单（SBOM）标准提高软件内部“是什么”的透 明度。SBOM通过提供一个软件中包含的所有组件、依赖项和库 的详细列表，帮助最终用户跟踪和管理软件的安全历史。尤其是具有严格安全性和合规性要求的最终用户（如金融机构和受监管企业），可以在SBOM的帮助下做出更明智的软件选择方案，例如在SBOM揭示软件为旧版或存在已知安全漏洞的版且存在可替代版的情况下，选择风险较低的版。优势层面，SBOM有助于修复大规模漏洞以及采取风险预防措施。在已使用软件的漏洞响应时，拥有SBOM的企业可以快速确定所使用的软件是否易受攻击，并集中力量补救已确定存在的漏洞；没有SBOM的企业必须对所有部署的基础设施执行耗时的审计，逐个寻找可能存在漏洞的组件。在使用开源组件之前，软件开发团队可以根据SBOM中的开源软件组件依赖性、子组件、版号等信息，提高对可靠性和安全性风险情况的掌握。例如，OpenSourceInsights提供的公共工具可以显示各种开源软件包的已知漏洞，包括从依赖关系继承的漏洞。挑战层面，SBOM仍不成熟，具有一定的实践局限性。一是多个SBOM标准之间不能互操作，无法通过各组件的SBOM信息计算出所组合的软件包的SBOM。例如，SPDX标准和CycloneDX标准之间的互操作性较差。二是SBOM中缺少部分组件。例如，从一个可部署的构件（如二进制文件）计算出组件时，对应的SBOM很可能缺失。三是需要中间存储库提供 构件的SBOM。例如，包管理器和Docker容器存储库需要提供SBOM支持，否则消费者必须自行计算SBOM。四是SBOM没有提供软件依赖关系的安全性信息，例如供应链安全或软件开发生命周期（SDL）。 软件工件的供应链级别（SLSA）安全框架提供了标准和控 制清单。SLSA可以防止篡改，提高完整性，并保护软件包和基础设施。SLSA框架建立了处理供应链安全风险应遵循的目标，包括使用可信的构建过程，为生成的工件生成签名和安全哈希以 用于身份验证和防止篡改等。优势层面，SLSA框架下的源代码、构建和软件托管在平台上，可通过安全防护策略强化软件开发集成部署流水线的安全，使攻击者难以破坏基础架构、流程或代码。对于软件生产商，SLSA提供保护、防止篡改，降低内部风险的增强消费者信心。尤其是SLSA可以为开源项目和生态系统提供一个框架，以证明开源软件版中包含未被篡改的源代码和依赖项。对于软件使用者，SLSA提供判断软件依赖的安全实践方法。对于基础设施提供商，SLSA可协助建立生产者和消费者之间的安全软件供应链。挑战层面，SLSA仍处于起步阶段，具有一定局限性。一是供应链中的工件依赖关系非常复杂，完整的依赖关系图可能非常庞大。二是工作量大，实际工作中需要确定并关注供应链中的重要组成部分，可以手动执行。三是工件的 SLSA级别不可传递，虽然主要的工件具有很强的安全性，但其他地方可能仍然存在风险。四是全面审查每个工件的整个图表不切实际。 三、问题一：开源软件的安全消费规范 （一）研究内容：开源软件的安全消费需考虑“顺流而下”“逆流而上”两方面因素 开源软件项目的代码维护及更新具有“顺流而下逆流而上”的特点。“顺流而下”是指开源软件以源代码形式被原始开发者或维护者创建，并向下分发给其他开发者或消费者使用。“逆流而上”是指用户向上反馈给原始开发团队的代码，这些代码会被开源项目吸收。 “顺流而下”的安全消费规范：下游的消费者使用开源软件 时，应尽量与最新版保持一致。从作用看，保持最新版可在发现漏洞时实现快速响应。美国国家标准与技术研究院（NIST） 《安全