在全球技术供应链中,开源软件和社区生态日益成为技术创新与数字经济的基础和重要驱动力,其安全性问题也随之成为焦点。2019年,Apache软件基金会发布声明,回应其非美国子公司被列入美国联邦登记公告实体裁决清单的问题,引发广泛讨论。2021年底的log4j安全漏洞事件,影响了全球数以百万计的设备,包括重要的政府和商业系统,再次反映出开源软件安全性问题。以上事件推动了各国在立法层面对开源软件安全性的关注和行动。

2022年9月,美国民主党、共和党参议员提出一项保护开源软件法案,建议美国网络安全和基础设施安全局(CISA)创建“风险框架”,以降低使用开源软件系统的风险。这项法案标志着美国政府对开源软件安全性的重视达到了新的高度。

2023年《开源软件安全法案》(S.917 - Securing Open Source Software Act of 2023)是在此基础上的进一步发展。该法案强调了开源软件作为公共数字基础设施的重要性,并对CISA在提高开源软件安全性方面的职责做出规定。按照立法者的说明,这一法案的提出是对开源软件安全性挑战的直接回应,也是对开源社区的支持和保护。同时,也意味着针对开源软件的法律监管进入了一个新阶段,该阶段被一些开源社区成员描述为“充满忧虑和不确定性”的时期。相较于五年前(2019年),新时期的开源软件将不仅更商业化,也更受约束。

(下图为初步佐证)

近年来,我国对开源软件安全性的关注显著增加。在此背景下,研究美国《开源软件安全法案》具有重要的参考意义和现实价值。该法案的内容和措施可以为我国制定相关政策法规提供一些启示或借鉴;同时,通过比较中美在开源软件安全性方面的法律框架,可以促进开源软件安全性标准和实践方面的跨国社区交流与合作,共同提升全球开源软件的安全水平。

本期简报翻译了美国2023年《开源软件安全法案》初始版本,以供参考。全文翻译如下:

法案

旨在明确网络安全和基础设施安全局负责人在开源软件安全保障方面应履行的职责,以及其他相关事宜。

第1条 简称

该法案可称为《2023年开源软件安全法案》。

第2条 研究结果

国会认为——

(1) 开源软件促进技术发展,是总体网络安全不可或缺的一部分;

(2) 一个安全、健康、充满活力和弹性的开源软件生态系统对于确保美国的国家安全和经济活力至关重要;

(3) 开源软件是促进自由开放互联网的数字基础设施基础的一部分;

(4) 由于开源软件的独特优势和开源软件安全的历史投资不一致,在保护开源软件方面存在独特的挑战;以及

(5) 联邦政府应在确保开源软件的长期安全方面发挥支持作用。

第3条 开源软件安全职责

(a) 总则,2002年《国土安全法》第二十二章经修订——

(1)在第2 200条中——

(A) 将第(22)款至第(28)款分别改为第(25)款至第(31)款;以及

(B) 在第(21)款后加入以下内容:

“(22) 开源软件——‘开源软件’一词是指将人类可读的源代码提供给公众使用、研究、重复使用、修改、增强和重新分发的软件。

“(23) 开源软件社区——‘开源软件社区’一词是指由个人、基金会、非营利组织、公司和其他实体组成的社区,这些实体——

“(A) 开发、贡献、维护和发布开源软件;或

“(B) 以其他方式努力确保开源软件生态系统的安全。

“(24) 开源软件组件——‘开源软件组件’一词是指向公众提供的开源软件的单独存储库。

(2) 在第2202(n)条中——

(A) 第(13)款末尾删除“以及”;

(B) 将第(14)款改为第(15)款;以及

(C) 在第(13)款之后插入以下内容:

“(14) 根据第2220F条的规定,在联邦机构的软件开发生命周期中支持(包括提供服务)安全使用和部署软件(包括开源软件);以及”;并且

(3) 在末尾添加以下内容:

“第2220F条 开源软件安全职责

“(a) 定义——在本节中,术语“软件物料清单”具有商务部发布的软件物料清单最低要素或该机构发布的任何替代定义中赋予该词的含义。

“(b) 雇用——负责人应在最大可行范围内,在该机构中雇用以下人员:

“(1) 具有参与开源软件社区的专业知识和经验;以及

“(2) 履行(c)款所述的职责。

“(c)负责人的职责。

“(1) 总则——负责人应——

“(A) 开展外联并参与活动,以加强开源软件的安全性;

“(B) 支持联邦政府加强开源软件安全;

“(C) 酌情与非联邦实体协调,努力确保开源软件的长期安全;

“(D) 充当非联邦实体(包括州、地方、部落和地区合作伙伴、私营部门、国际合作伙伴和开源软件社区)在开源软件安全方面的公共联络点;以及

“(E) 通过鼓励加强开源软件安全的努力,支持联邦和非联邦供应链安全工作,例如——

“(i) 根据第2209(n)条,协助协调开源软件组件中的漏洞披露;以及

“(ii) 支持联邦采购安全委员会的活动。

“(2) 评估关键开源软件组件。——

“(A) 框架——本条颁布之日起1年内,负责人应公开发布一个框架,纳入政府、行业和开源软件社区的框架和最佳实践,包括美国国家标准与技术研究院发布的框架和最佳实践,用于评估开源软件组件的风险,包括直接和间接的开源软件依赖关系,该框架应至少纳入以下内容:

“(i) 特定开源软件组件中代码的安全属性,例如该代码是否用内存安全编程语言编写;

“(ii) 特定开源软件组件的开发、构建和发布过程的安全实践,例如维护者使用多因素身份验证和发布的加密签名;

“(ⅲ) 特定开源软件组件中公开已知的、未修补的漏洞数量和严重程度;

“(ⅳ) 特定开源软件组件的部署范围;

“(v) 与开源软件组件的集成或部署位置相关的风险程度,例如该组件是否在网络边界或特权位置运行;和

“(vi) 针对特定开源软件组件的开源软件社区健康状况,包括(在适用的情况下)开源软件组件的当前及历史投资和维护水平,例如个人维护者的数量和活动。

“(B) 更新框架——在根据(A)款公布框架之日起,负责人应每年不少于一次——

“(i) 确定是否需要对(A)款所述框架进行更新,包括增加、添加或删除(ⅰ)至(vi)项所述的要素;以及

“(ii) 如果负责人确定需要根据第(i)条进行其他更新,则对框架进行这些更新。

“(C) 制定框架——在制定(A)款所述框架时,负责人应与下列机构协商:

“(i) 适当的联邦机构,包括国家标准与技术研究院;

“(ii)来自开源软件社区的个人和非营利组织;以及

“(iii)来自开源软件社区的私营公司。

“(D) 可用性——负责人应尽最大可能确保(A)款所述的框架可供开源软件社区使用,包括通过(C)款所述的磋商。

“(E) 联邦开源软件评估——在(A)款所述框架公布后1年内,以及此后不少于每两年一次,负责人应在实际最大可行范围内,适用(A)款所述框架——

“(i)对联邦机构直接或间接使用的开放源码软件组件进行评估,评估应基于现成的信息,并尽最大可能基于机器可读的信息,例如

“(I)在评估时向联邦机构提供的或可通过互联网访问的软件物料清单;

“(II) 在进行评估时,负责人可从该机构的持续诊断和缓解计划中获得的软件物料清单;以及

“(III) 有关开源软件组件的其他公开信息;以及

“(ii) 根据评估结果,制定一份或多份第(i)项所述组件的排序清单,例如按组件的关键性、风险程度或使用情况排序,或两者结合排序。

“(F) 自动化——负责人应在最大可行范围内使根据(E)款进行的评估自动化。

“(G) 公开——负责人应将为进行(E)款所述评估而开发的任何工具作为开源软件公开发布和维护。

“(H) 共享

“(i) 结果——负责人应促进与致力于支持开源软件安全的特定联邦和非联邦实体共享(E)(i)项所述的各项评估的结果,包括为特定联邦和非联邦实体提供自动下载评估的方法。

“(ii) 数据集——负责人可酌情公开公布因(E)(i)项所述评估而开发或合并的任何数据集或数据集的版本。

“(I) 关键基础设施评估研究和试点。

“(i) 研究——在(A)款所述框架公布后2年内,负责人应就其对关键基础设施实体进行(E)款所述评估的可行性进行研究。

“(ii) 试点

“(I) 一般情况——如果负责人确定第(i)项所述的评估是可行的,可与部门风险管理机构和每个参与部门的部门协调委员会协调,在自愿的基础上对一个或多个关键基础设施部门进行试点评估。

“(II) 终止——如果负责人继续进行(ii)(I)所述的试点,则试点应在开始之日起2年后终止。

“(iii) 报告——

“(I) 研究——负责人完成根据(i)进行的研究之日起180天内,应向有关国会委员会提交一份报告,应包括:

“(aa) 总结研究情况;以及

“(bb) 说明负责人是否计划进行(ii)(I)所述的试点。

“(Ⅱ) 试点——如果负责人进行(ii)所述的试点,在开始试点之日起1年内,负责人应向适当的国会委员会提交一份报告,其中包括——

“(aa) 概述试点结果;以及

“(bb) 关于在(ii)(II)所述的试点结束后是否应继续开展试点活动的建议。

“(3) 与国家网络局负责人的协调——负责人应——

“(A) 向国家网络总监简要介绍本小节所述的活动;以及

“(B) 酌情与国家网络总监协调活动。

“(4)报告

“(A) 总则——本条颁布之日起1年内,以及此后每两年,负责人应向有关国会委员会提交一份报告,其中包括:

“(i) 负责人在报告所涉期间开展的开源软件安全工作的概要,包括与负责人有联系的联邦和非联邦实体的清单;

“(ii) 根据第(2)条(A)款制定的框架;

“(iii) 自上次提交报告以来,依第(2)条(B)款对根据第(2)条(A)款制定的框架所作的任何更新的摘要;

“(iv) 自上次提交报告以来,根据第(2)条(E)款进行的每次评估的摘要;

“(v) 自上次提交报告以来,对根据第(2)条(E)款进行的评估所作修改的摘要,包括总体安全趋势;以及

“(vi) 自上次提交报告以来,根据第(2)条(H)款与之共享评估的各类实体的概要,包括与之共享评估的联邦和非联邦实体的清单。

“(B) 公开报告——在负责人根据(A)款要求提交报告之日起30天内,负责人应在机构网站上公布报告。

(b) 技术性和一致性修正案——对《2002年国土安全法》第1(b)条的目录进行了修订,在与第2220E条有关的项目后插入以下内容:

“第2220F条 开源软件安全职责。”

第4条 软件安全顾问小组委员会

对《2002 年国土安全法》第2219(d)(1)条进行了修订,在结尾处加入以下内容:

“(E) 软件安全,包括开源软件安全。”

第5条 开源软件指南

(a) 定义——在本条中:

(1) 有关国会委员会——“有关国会委员会”一词具有2002年《国土安全法》第2条给出的含义。

(2) 覆盖机构——“覆盖机构”一词是指《美国法典》第31篇第901(b)条所述机构。

(3) 负责人——“负责人”一词是指管理和预算办公室负责人。

(4)国家安全系统——“国家安全系统”一词具有《美国法典》第44篇第3552条给出的含义。

(5)开源软件;开源软件社区——术语“开源软件”和“开源软件社区”具有经本法第3条修订的2002年《国土安全法》第2200条给出的含义。

(b) 指南

(1) 总则——在本法案颁布之日起1年内,负责人应与国家网络局负责人、网络安全和基础设施安全局负责人以及总务署署长协调,就各覆盖机构首席信息官在开源软件方面的职责发布指南,其中应包括:

(A) 考虑到行业和开源软件社区的最佳实践,各覆盖机构首席信息官应如何

(i) 管理和降低使用开源软件的风险;以及

(ii) 指导开源软件的贡献和发布;

(B) 首席信息官应如何促进而不是禁止各覆盖机构安全使用开源软件;

(C) 管理和预算办公室于2016年8月8日发布的备忘录M-16-21的任何相关更新,题为“联邦源代码政策:通过可重用和开源软件实现效率、透明度和创新”;以及

(D) 覆盖机构如何公开贡献其使用的开源软件,包括首席信息官应如何鼓励这些贡献。

(2) 国家安全系统豁免——根据第(1)款发布的指南不适用于国家安全系统。

(c) 试点

(1) 总则——在本法颁布之日起1年内,根据第(2)款选择的各覆盖机构首席信息官与负责人、国家网络局负责人、网络安全和基础设施安全局负责人以及总务署署长协调,应在覆盖机构中建立试点开源功能,以便——

(A) 以开源项目办公室为蓝本,例如私营部门、非营利部门、学术界和其他非联邦实体的开源项目办公室;以及

(B) 应—

(i) 支持所覆盖机构安全使用开源软件;

(ii) 酌情与所覆盖机构的总法律顾问办公室和采购办公室协商,制定向所覆盖机构提供和发布开源软件的政策和流程;

(iii) 与开源软件社区建立联系;以及

(iv) 管理和降低在所覆盖机构使用开源软件的风险。

(2) 试点机构的选择——负责人应与国家网络局负责人、网络安全和基础设施安全局负责人以及总务署署长协调,选择不少于1家且不超过5家机构进行第(1)款所述的试点。

(3) 评估——在第(1)段所述的试点开源功能建立后1年内,负责人应与国家网络局负责人、网络安全和基础设施安全局负责人以及总务署署长协调,评估是否应在部分或所有覆盖机构建立开源功能,包括——

(A) 如何在覆盖机构内组织这些功能,例如创建开源项目办公室;以及

(B) 这些功能的相应角色和责任。

(4) 指导——尽管根据第(5)款终止了试点开源职能,但如果负责人根据第(3) 款所述的评估,确定应在部分或所有覆盖机构中建立部分或全部开源功能,则负责人应与国家网络局负责人、网络安全和基础设施安全局负责人协调,总务署署长应就这些功能的实施发布指南。

(5)终止——第(1)款所述的试点开源功能应在建立后4年内终止。

(d) 简报和报告——负责人应——

(1) 本法颁布之日起1年内,向有关国会委员会简要介绍根据(b)款发布的指导意见;以及

(2) 在根据第(c)(1)款建立试点开源功能后540天内,向有关国会委员会提交一份报告,内容包括:

(A)试点开源功能;以及

(B)根据第(c)(3)款进行的评估结果。

(e)职责——《美国法典》第44篇第3554(b)条修订如下——

(1)在第(7)款末尾删除“以及”;

(2)在第(8)款中,删除末尾的句号,并插入“;以及”;并且

(3)在末尾添加以下内容:

“(9) 确保软件安全使用和开发的计划和程序,包括开源软件(定义见2002年《国土安全法》第2200条)。

第6条 解释规则

本法或本法修正案均不得解释为向其中所述的任何联邦机构提供任何额外的监管权力。(原浩 谢永红 祝媛

声明:本文来自苏州信息安全法学所,版权归作者所有。文章内容仅代表作者独立观点,不代表安全内参立场,转载目的在于传递更多信息。如有侵权,请联系 anquanneican@163.com。