1、 开源安全深度观察报告开源安全深度观察报告 云计算开源产业联盟 金融行业开源技术应用社区 OpenSource Cloud Alliance for industry，OSCAR Finance Open Source，FINOC 通信行业开源社区 科技制造开源社区 ICT Open Source Community， ICTOSC Technology Manufacturing Open Source Community， TMOSC 2022年5月 版权及版权及免责免责声明声明 本指南的本指南的版权归版权归云计算开源产业联盟所有。 本指南所包含的云计算开源产业联盟所有。 本指南所包含的内

2、容内容、 资资料料与与信息信息，可，可能无法反应当前最新的法律发展能无法反应当前最新的法律发展，仅供您参考仅供您参考之用，并之用，并不构成法律意见或建议不构成法律意见或建议。 云计算开源产业联盟，。 云计算开源产业联盟， 本指南的参与单位本指南的参与单位与与编写人， 皆编写人， 皆不保证或担保本指南内容、不保证或担保本指南内容、 资料资料与与信息信息的准确性， 完整性，的准确性， 完整性，充分性或及时性。 云计算开源产业联盟，充分性或及时性。 云计算开源产业联盟， 本指南的参与单位本指南的参与单位与编写人，与编写人，明确不承担因基于本明确不承担因基于本指南指南的任何内容、的任何内容、 资料资料

3、与与信息信息， 而采取的， 而采取的作为或作为或不不作为所产生的一切责任。作为所产生的一切责任。 编写说明：编写说明： 牵头单位：中国信息通信研究院 参与单位：中国信息通信研究院、中国建设银行、建信金融科技有限责任公司、华为技术有限公司、华为云计算技术有限公司、中兴通讯股份有限公司、中电科拟态安全技术有限公司、深圳开源互联网安全技术有限公司、新思科技、悬镜安全、北京天融信网络安全技术有限公司、苏州棱镜七彩信息科技有限公司、国网电商科技有限公司、统信软件技术有限公司、浩鲸云计算科技股份有限公司 参与人员：李晓明、郭雪、郭贞、李鑫、李佩芳、袁巍、夏伟、牟宁波、崔锦国、郑志强、项曙明、李响、侯大鹏、

4、耿蕴秋、杨国梁、王 永雷、郑明、贺文轩、李佳雯、张弛、董毅、张荣香、刘美平、杨剑、梁大功、易焕腾、王媛媛、马大伟、何雪林、龙攀、郑明达、段知 前前 言言 近些年开源技术已成为新技术领域主流技术路线， 开源软件具备公开可获得的特性，在给全球企业带来便利的同时，开源安全事件层出不穷， 缺乏开源安全研发和治理能力导致开源安全威胁全球信息系统，本报告旨在从分析开源安全变化趋势、开源安全热门事件分析、国内外开源安全防范发展现状对比、 开源安全防范建议和开源安全发展展望五个章节全方位开展开源安全深度研究报告撰写， 致力于降低开源安全发生频率，为企业给出开源安全治理指南。 - 1 - 目录 一、开源生态发展

5、迅速，开源成为构建企业信息技术重要底座 . 4 二、开源安全风险严重威胁全球企业信息和财产安全 . 6 2.1 开源安全风险种类复杂 . 7 2.2 开源安全热门事件分析 . 8 （一）开源安全漏洞与后门植入事件频发，威胁全球信息安全 . 8 （二）隐私信息泄露事件威胁财产和人身安全，严重影响企业声誉 . 10 三、全球开源安全防范措施愈加严格，我国逐步深入探索 . 11 3.1 全球开源安全发展较早，多层面合力应对开源安全威胁 . 11 （一）开源安全防范政策层层加码 . 11 （二）开源安全组织探索开源社区安全保障 . 12 （三）开源社区致力构建安全开发自动化体系 . 15 （四）头部科

6、技公司开源安全防范体系建立较早 . 16 3.2 我国政府、企业和个人三管齐下应对开源安全风险 . 17 （一）多政策提及开源安全防范要求 . 17 （二）开源安全组织处于探索阶段 . 17 （三）开源社区安全开发意识有待加强 . 18 （四）出海企业开源安全防范体系落地较早 . 19 四、开源安全防范需兼顾上游开源社区与下游开源用户 . 20 4.1 开源社区需建立安全开发规范 . 20 4.2 用户企业需建立开源安全问题修复措施 . 22 （一）安全漏洞和后门植入需按照轻重缓急应修尽修 . 22 （二）隐私信息泄露防范需做好出口管理 . 25 五、开源安全发展展望 . 25 附录、企业级开

7、源安全治理实践案例 . 27 - 2 - 华为开源安全实践 . 27 中兴通讯开源安全实践 . 29 - 3 - 图目录 图 1 GitHub 近五年开源项目数量及增长率 .错误!未定义书签。 图 2 Gitee 近五年开源项目数量及增长率 . 5 图 3 Gitee 近五年开源企业数量 . 5 图 4 全球开源软件应用比例 . 6 图 5 我国开源软件应用比例 . 6 图 6 开源漏洞增长情况 . 7 图 7 Apache Log4j2 漏洞攻击趋势 . 9 图 8 开源安全漏洞修复流程 . 24 图 9 企业级开源软件安全治理架构 . 29 图 10 开源软件治理体系总体架构 .错误!未定

8、义书签。 4 一、开源生态发展迅速，开源成为构建企业信息技术重要底座 开源项目数量爆发式增长。全球开源项目数量持续提升，连续三年增长率超过40%。 根据全球最大开源代码托管平台GitHub 2021年度报告数据显示1，截至2021年GitHub托管仓库已超过2.6亿个，2021年新增仓库6100万个。全球开源项目紧跟技术更迭趋势，在新兴领域占据绝对优势， 比例高达60%。 根据Gitee2021年度报告数据指出2， 2021年Gitee平台上开源项目与2020年相比增长比例为33%， 达到了2000万。 来源：GitHub，2021年11月 图 1 GitHub 近五年开源项目数量及增长率 1

9、 The 2020 State of the OCTOVERSE,github,2020 2 https:/ 6.79.4142026.138%40%50%43%31%0%10%20%30%40%50%60%0500202021项目数（千万）增长率 5 来源：Gitee 图 2 Gitee 近五年开源项目数量及增长率 企业逐渐重视对外开源贡献。根据 Open Source Contributor Index公布的 2022 年 4 月的全球开源厂商 GitHub 开源贡献排名3，华为、腾讯、阿里分别位列 12、14、16 位，华为活跃开发者人数为 5

10、47，参与社区为 1473。同时根据 Gitee2021 年度报告显示，2021 年 Gitee 企业用户达到 20 万， 相较于 2020 年的 18 万家企业， 增长率达到 33%。 来源：Gitee，2021 图 3 Gitee 近五年开源企业数量 企业开源软件应用比例逐年提升。 近年来企业对开源技术的接受 3 https:/opensourceindex.io/#:%7E:text=OSCI%20measures%20the%20Active%20Contributors 3005205830025002017年2018年2019年2020年

11、2021年项目数（万）251018200%10%20%30%40%50%60%70%057年2018年2019年2020年2021年企业数（万）增长率 6 程度越来越高，使用开源技术已成主流。根据 BD2022 开源安全与风险分析报告 显示， 2021 年全球企业应用开源软件的比例已经达到78%，与 2018 年相比比例增加 30%且四年来开源软件使用率持续增加。 根据中国信通院调查显示， 2021 年我国已经使用开源技术的企业占比为 88.2%，暂未计划使用开源技术的企业占比为 2.1%。 来源：新思科技，2022 年 5 月 图 4 全球开源软件应用比例 来源：中国信

12、息通信研究院 图 5 我国开源软件应用比例 二、开源安全风险严重威胁全球企业信息和财产安全 软件供应链安全作为国家近几年新提出的网络安全理念， 不再是针对软件供应链上单一环节进行安全防护， 而是针对软件供应链全链路进行安全监控防护，薄弱环节的安全预防更是重中之重。随着开源60%62%64%66%68%70%72%74%76%78%80%2002188.2%9.5%2.1%已经使用有计划使用暂时没有计划使用 7 软件成为各行业构建信息系统的主流趋势，且开源软件迭代快、安全开发机制欠缺、 维护人手不足等现状导致开源安全成为软件供应链安全风险中重要一环，并且造成的风险影响力遍布

13、全球。 2.1 开源安全风险种类复杂 开源安全风险成为开源首要关注的风险点。 开源由于未经过商业化系统性安全测试，漏洞暴露在互联网会降低代码安全性。根据 BD2022 开源安全与风险分析报告 显示， 87%的代码库至少含有一个漏洞，漏洞含有比例近四年逐年增高，49%的已审核代码库包含高风险漏洞。 来源：新思科技，2022 年 5 月 图 6 开源漏洞增长情况 开源安全风险按照分类可分为开源漏洞风险、 开源后门植入风险和开源隐私信息泄露风险。 开源漏洞风险：开源漏洞风险是指开源软件、硬件、软件、协议的具体实现或系统安全策略上存在的缺陷， 从而可以使攻击者能够在未授权的情况下访问或破坏系统。近些年

14、以 Apache Log4j 等一系列开源漏洞爆发导致全球范围内安全攻击事件频发， 因受影响的信息系67%78%60%75%84%87%53%77%40%49%60%49%0%20%40%60%80%100%2001920202021至少含有一个漏洞含有高危漏洞 8 统遍布全球基础设施，轻则影响网络，重则影响国家基础设施安全，影响人们衣食住行正常运转。 开源后门植入风险： 这类攻击是将恶意代码直接注入到开源项目的存储库中，攻击方式包括：1）从项目维护人员那里窃取凭证；2）在公共存储库中发布项目新版本；3）向包含恶意代码的项目中提供pull requests；4）篡改开源开

15、发人员工具，将恶意代码注入下游应用程序。这类攻击方法一般是在上游“设置陷阱”，然后通过供应链将漏洞植入到数千家企业的代码库中，向下游发起攻击。SolarWinds 后门攻击事件和美国明尼苏达大学 （UMN） 为开源 Linux 项目提交后门代码为典型开源后门植入类事件，此类风险为被动开源安全风险，后门植入隐蔽且不自知，可造成个人、企业和国家通过开源后门植入代码被监控，严重威胁信息安全。 开源隐私信息泄露风险：这类风险是指个人、组织或企业对外开源项目、 贡献代码时无意或有意将未经隐私信息清洗的代码公开到托管平台上去，导致涉及个人或企业隐私的信息被迫公开。此类风险涉及信息类型众多，严重威胁个人财产

16、和隐私安全。 2.2 开源安全热门事件分析 （一）开源安全漏洞与后门植入事件频发，威胁全球（一）开源安全漏洞与后门植入事件频发，威胁全球信息安全信息安全 Apache Log4j2 漏洞影响全球 70%的网络系统。Apache Log4j2 于2021 年 12 月爆发漏洞，该漏洞编号为 CVE-2021-44228，CVSS 评分为 10.0，划分为严重漏洞。Apache Log4j2 是基于 java 的日志记录第 9 三方组件，根据统计 Java 现存日志框架在 Github 上的关注量中，Log4j2 的关注量排名第三，属于基于 Java 的第三大日志记录框架。该漏洞影响 log4j-

17、core JAR 文件，Log4j2 对每条日志通过消息工厂（Message Factory）创建消息（Message）对象，然后创建处理事件（event） ，将消息（MeaageFactory）加入到处理事件（event）中，对消息进行处理。在消息处理过程中，log4j2 的 format 方法（函数）会判断组件是否启用了 lookup 方法，一旦启用 log4j2 组件就会读取日志消息中的$ 关键词并将$关键词中的内容传递给 lookup 方法。最终 lookup 方法调用 JndiLookup 中 Lookup 方法，从远程拉取攻击Paylod，造成远程代码执行漏洞。 来源：360 图

18、7 Apache Log4j2 漏洞攻击趋势 SolarWinds 后门攻击事件波及全球重要科技发达地区的敏感机构。2020 年 12 月 13 日，美国网络安全公司 FireEye 发布分析报告称，SolarWinds 旗下的 Orion 基础设施管理平台的发布环境遭到黑客组0246810121416攻击次数/K 10 织入侵，黑客对文件 SolarWinds.Orion.Core.BusinessLayer.dll 的源码进行篡改添加后门代码， 该文件具有合法数字签名会伴随软件更新下发。后门代码伪装成 Orion OIP 协议的流量进行通信，将其恶意行为融合到 SolarWinds 合法行

19、为中。FireEye 称已在全球多个地区检测到攻击活动，包括北美、欧洲、亚洲和中东的一些政府、咨询、技术公司。 美国明尼苏达大学 （UMN） 研究人员为 Linux 内核提交恶意代码。2021 年 4 月 Linux 内核项目维护者 Greg Kroah-Hartman 决定禁止明尼苏达大学为开源 Linux 项目做贡献。 其原因是明尼苏达大学的研究人员被发现提交了一系列的恶意代码， 或故意在官方 Linux 代码库中引入有安全漏洞的补丁以作为其研究活动的一部分。 （二）隐私信息泄露事件威胁财产和人身安全，严重（二）隐私信息泄露事件威胁财产和人身安全，严重影响企业声誉影响企业声誉 某连锁酒店信

20、息泄漏波及上亿条信息。2018 年，某连锁酒店用户数据在暗网公开售卖，数据涵盖酒店官网注册资料、酒店入住登记信息、酒店开房记录、住客姓名、身份证号、手机号码、邮箱、登陆账号密码等大量敏感涉密信息，涉及酒店 10 余家。据统计，此次泄露的数据数量则总计达 5 亿条， 其中， 酒店官网注册资料信息共 53GB，约 1.23 亿条记录;入住登记身份信息共 22.3GB， 约 1.3 亿条;酒店开房记录共 66.2GB， 约 2.4 亿条。 据分析此次事件源于内部人员在 Github上传一个开源项目，该项目源码中包含酒店的服务器及数据库 IP 地址、路径、用户名和密码及网站密钥等机密信息，这些隐私信息

21、被黑 11 客利用导致大量数据泄露。 三、全球开源安全防范措施愈加严格，我国逐步深入探索 3.1 全球开源安全发展较早，多层面合力应对开源安全威胁 （一）开源安全防范政策层层加码（一）开源安全防范政策层层加码 多国实施开源漏洞悬赏计划提高开源项目安全性。 欧盟委员会发布漏洞悬赏计划。欧盟相关权力机构首次在 2015 年批准了自由和开源软件审计(FOSSA)项目设立，该项目旨在定期提供悬赏奖金，支持常用开源软件漏洞挖掘奖励。首个 FOSSA 版本作为试验计划运行于2015 年和 2016 年，最初的预算是 100 万欧元。欧盟创造了欧盟办公室和员工使用的最流行的开源项目， 并且针对应当赞助哪些项

22、目的安全审计， Apache HTTP web 服务器和 KeePass 密码管理器成功入选。FOSSA 第 2 版运行于 2017 年，方式是作为 VLC Media Player app 在 HackerOne 上设立的漏洞奖励计划。该计划共获得 200 万欧元的资助，但该计划的预算上限是 6 万欧元。FOSSA 第 3 版 2019 年开始启动，涵盖 14 个漏洞奖励计划。获得最高预算的是 PuTTY 和DrupalCMS。内容包括软件项目、赏金（欧元） 、起始日、截止日以及漏洞奖励平台。2021 年欧盟委员会提供 20 万欧元为欧盟公共服务中使用最多的 LibreOffice、 Mas

23、todon、 Odoo 和 Cryptpad 提供漏洞悬赏。美国国土安全部资助 Coverity 公司开展“开源软件代码测试计”。美国自 2006 年开始，美国国土安全部资助 Coverity 公司开展“开源软件 12 代码测试计划” ，针对大量开源软件进行安全隐患的筛查和加固，截至 2017 年 2 月，累计检测各种开源软件 7000 多个，发现大量安全缺陷。 国家级开源安全指导提供企业开源安全防范新思路。 英国政府发布开放代码的安全注意事项指南 。英国政府认为开源可以在协作开发中创建更好的代码，并提高与用户的接触，但同时需要遵循指南中注意事项保障开源代码安全。美国白宫开源软件安全峰会推动

24、1.5亿美元开源软件保护计划。 参会者表示开源是国家安全的关键组成部分，是当今软件创新投资数十亿美元的基础，各方有义务来升级集体网络安全。 （二）开源安全组织探索开源社区安全保障（二）开源安全组织探索开源社区安全保障 2019 年英国成立开源组织 OpenUK， 该组织关注开源软件， 开源硬件和开放数据， 设立开源安全顾问委员会对开源软件安全性进行统一审查， 委员会由 7 位资深安全专家组成； 同时 OpenUK 致力于构建SBOM 标准体系提高开源安全性， 探索开源安全和开源软件收入之间的关系。 2020 年 8 月 linux 基金会成立开源安全基金会 （OpenSSF） ， 该基金会是一

25、个由 Linux 基金会主办的跨行业组织， 汇集了世界上最重要的开源安全计划，以帮助识别和修复开源软件中的安全漏洞，并开发改进的工具、培训、研究和最佳实践，提高开源软件安全性。基金会正式成立包括设立一个理事会(Governing Board)，一个技术咨询委员会(Technical Advisory Council)，并对每个工作组和项目进行单独的监 13 督。截至 2022 年 4 月，该基金会共拥有 74 位会员，包括 25 位重要会员，41 位普通会员和 8 位协会会员。目前基金会共托管 2 个主要开源项目，并形成 5 个工作组推进开源安全治理。漏洞披露工作组旨在提高漏洞披露和漏洞修复效

26、率， 同时为漏洞报告创建统一的格式和API；安全工具工作组旨在为开源开发人员提供最好的安全工具满足更广泛的开源社区需求； 识别开源项目安全威胁工作组目标是确定关键指标使利益相关者更好了解各个开源组件的安全状况； 安全最佳实践工作组目标是为开源开发人员提供最佳实践建议； 保护关键项目工作组目标是执行审计，保证，响应团队，改进和动手战术工作。 开源安全基金会 （OpenSSF） 最佳实践徽章提供为开源软件提供安全证明。 最佳实践徽章是自由/自由和开源软件 （FLOSS） 项目展示其遵循最佳实践的一种方式，分为及格、银、金三个级别。徽章的使用者可以快速评估哪些开源项目遵循最佳实践， 因此更有可能生产

27、出更高质量的安全软件。获得徽章应满足以下要求： 项目需要具备完善的开源软件基础信息。项目明确指定许可证，该项目生成的软件必须以符合开源定义或自由软件定义的方式（FLOSS） 发布， 此类许可证的示例包括 CC0， MIT， BSD 2 子条款，BSD 3 子条款修订版， Apache 2.0， 小型 GNU 通用公共许可证 （LGPL）和 GNU 通用公共许可证（GPL） 。这也意味着许可必须是：开源计划（OSI）批准的许可，或自由软件基金会（FSF）批准的免费许可，或Debian main 可接受的免费许可证，或 Fedora 认证的许可证；该项目必须为生成的软件提供基本文档，必须包含在某些

28、媒体中，其中包括 14 安装、启动以及安全使用方法。 项目需要保障开源代码数据传输安全。项目站点（网站，存储库和下载 URL）必须使用 TLS 支持 HTTPS；该项目必须具有版本控制的源存储库， 该存储库是公共可读的并且具有 URL， 项目的源存储库必须跟踪进行了哪些更改，谁进行了更改，以及何时进行了更改。为了实现协作审查， 项目的源存储库必须包含用于在发布之间进行审查的临时版本，它不能只包括最终版本；项目必须为每个由用户使用的版本提供唯一的版本标识符， 可以通过多种方式实现， 如提交 ID、 版本号；该项目必须在每个版本中提供发行说明，说明是该发行版中主要更改的可读摘要， 以帮助用户确定是

29、否应升级以及升级影响将是什么，发行说明绝不能是版本控制日志的原始输出。 项目需要建立开源漏洞监控和修复机制。 该项目必须为用户提供一个提交错误报告的流程，支持使用问题跟踪器来跟踪个别问题，响应在过去的 2-12 个月（含）中提交的大多数错误报告，以及回应在过去的 2-12 个月（含）中大多数（ 50）的增强请求；项目必须发布报告项目漏洞的流程；使用标准的开源工具作有效的构建，如启用并修复编译器警告和类似 lint 的检查，以及执行其他静态分析工具，并修复可被攻击利用的问题；拥有涵盖大部分代码/功能的自动化测试套件，并正式要求对新代码进行新的测试；自动运行所有更改的测试，并应用动态检查，如执行内

30、存/行为分析工具（sanitizers/Valgrind等） ，以及执行模糊测试器（fuzzer）或 Web 扫描程序；有开发者了解安全软件和常见漏洞错误；项目生成的软件，必须仅使用由专家公开 15 发布和审查的加密协议和算法，不重新实现标准功能，项目生成的依赖于加密的软件中的所有功能，必须由开源加密实现，使用保持安全的密钥长度，不使用已知损坏或已知弱算法，使用具有前向保密性的算法，使用密钥拉伸算法，使用迭代、加盐和哈希值存储任何密码，使用加密随机数源； 该项目必须使用一种抵御 MITM 攻击的传递机制。如 https 或 ssh + scp；必须没有公开超过 60 天的、中等或高度严重的未修

31、补漏洞。 （三）开源社区（三）开源社区致力致力构建安全开发构建安全开发自动化体系自动化体系 Alpha-Omega 项目旨在通过直接参与软件安全专家和自动化安全测试来改善开源软件（OSS）的安全状况。它最初由微软和谷歌支持，总投资为 500 万美元。该项目通过与项目维护人员合作，系统地寻找开源代码中尚未发现的新的漏洞并加以修复，从而提高了全球OSS 供应链的安全性。 “Alpha”将与最关键的开源项目的维护者合作，帮助他们识别和修复安全漏洞，并改善他们的安全状况。“Omega”将确定至少 10,000 个广泛部署的 OSS 项目，它可以在其中将自动化的安全分析，评分和修复指南应用于其开源维护者

32、社区。 Sigstore 是一套工具，开发人员，软件维护者，包管理员和安全专家可以从中受益。它将 Fulcio，Cosign 和 Rekor 等免费使用的开源技术结合在一起，处理数字签名，验证和检查所需的来源，以使分发和使用开源软件更安全。该项目使用 Cosign 生成对工件进行签名和验证所需的密钥，尽可能地实现自动化。 SLSA 是一组可逐步采用的安全准则， 由行业共识建立。 SLSA 制 16 定的标准是软件生产者和消费者的指导原则： 生产者可以遵循指导方针，使他们的软件更安全，消费者可以根据软件包的安全状况做出决策。SLSA 的四个级别旨在实现增量和可操作性，并防止特定的完整性攻击。SL

33、SA 4 代表理想的最终状态，较低的级别代表具有相应完整性保证的里程碑。 （四四）头部科技公司开源安全防范体系建立较早）头部科技公司开源安全防范体系建立较早 头部科技公司对内成立开源管理办公室（OSPO）管理企业，统筹内部开源的安全开发、安全测试和漏洞修复等工作。根据 Linux 基金会开源办公室调查报告显示，在 2,700 名研究参与者中，超过一半（52）拥有正式或非正式开源项目办公室，或者他们的公司计划创建一个计划。 头部科技公司对外积极推动开源安全生态发展， 对于现有开源项目贡献资金和人员， 谷歌宣布资助两名专职人员开发和维护 Linux 内核安全，微软和谷歌正在支持由 OpenSSF

34、宣布开源的 Alpha-Omega项目，初始投资为 500 万美元，旨在提高开源软件的安全性。同时头部科技公司致力于开源重要领域安全类开源项目，微软开源Counterfit，用于 AI 系统安全测试的自动化工具；谷歌开源 Allstar 项目， 通过不断监控和执行一系列安全策略来保护 GitHub 项目的安全，从而阻止基本的安全配置错误问题； IBM 研究实验室发布开源安全工具包 SysFlow，用于查找云和容器环境中的漏洞。 17 3.2 我国政府、企业和个人三管齐下应对开源安全风险 （一）（一）多多政策政策提及开源安全防范要求提及开源安全防范要求 不同行业多政策提及开源安全防范要求。针对金

35、融行业发布关于规范金融业开源技术应用与发展的意见提及开源安全。意见提及坚持安全可控， 金融机构应当把保障信息系统安全作为使用开源技术的底线，认真开展事前技术评估和安全评估，堵塞安全漏洞，切实保证技术可持续和供应链安全，提升信息系统业务连续性水平。同时意见中还支持金融机构制定应急处置预案，应对开源技术潜在漏洞、后门及闭源、停服等突发情况。工信部发布 “十四五”软件和信息技术服务业发展规划侧重知识产权治理。规划提出在发展开源生态的同时需要开展开源治理工作，对知识产权进行托管、建立开源软件知识产权基金等，开源安全治理部分尚未单独说明。在开源安全层面，建设国家和行业级别开源社区的安全审查体系， 保证各

36、行业广泛使用的重要开源产品及技术服务的安全性； 以国家规章制度和行业自律公约等形式规范开源软件的治理工作， 推动公正的中立第三方代码托管平台，保证开源服务的安全和可信的运行态的服务试用。 （二）开源安全组织处于探索阶段（二）开源安全组织处于探索阶段 开放原子开源基金会关注开源项目安全漏洞治理。 开放原子开源基金会 openX 研究工作组下设的目标是构建一个公益性的开源研究机构，汇聚领先开源人才和智力；同时以一个开放、透明的社区的形式，以跨学科的视角，将“开源开发” 、 “开源治理” 、 “开源运营”等 18 研究融为一体，持续输出“方法” 、 “技术” 、 “工具” 、 “规范”等前沿知识性成

37、果。 下设开源项目安全漏洞治理子工作组通过专题小组的研究和产出，帮助更多的企业和组织提升安全漏洞治理的能力，提升企业和组织的生产力和竞争力，为企业和及其开源项目保驾护航。 中国信息通信研究院创建“可信开源”品牌探寻开源安全标准化工作。中国信通院已开展多项开源方面工作，标准制定方面形成包括企业级开源治理、开源供应链、开源工具、开源项目和社区在内的可信开源治理体系，为企业规范开源治理，降低开源风险提供参考；白皮书撰写方面， 继续深入产业研究， 正在编写包括 开源生态白皮书在内的多本开源领域白皮书，树立行业标杆；社区建设方面继续扩大金融行业开源技术应用社区规模，吸纳 50 余家金融成员探讨金融行业开

38、源痛点问题；公共服务方面建成综合性开源治理平台，为企业和个人提供开源风险检测和开源生态监测公共服务。 （三）开源社区安全开发意识有待加强（三）开源社区安全开发意识有待加强 国内部分活跃度高的开源社区陆续设立开源安全漏洞治理组保障社区安全治理。MindSpore 社区建立单独漏洞管理团队，协调漏洞从接收到披露的整个过程，包括：漏洞收集：社区成员和外部研究者发现的疑似安全漏洞， 都可以通过邮件上报给 VMT； 漏洞跟踪处置：VMT 会将确认的漏洞录入 MindSpore 社区， 并负责漏洞的确认/修复，期间会与上报者保持有效沟通；负责任的披露：漏洞得到妥善的修复后，VMT 将会以 SA 的形式将漏

39、洞信息发布到社区。Open Harmony社区建立安全问题响应组，发布安全问题处理和发布流程，通过安全 19 漏洞例行扫描、内部上报和外部上报等方式及时发现开源安全问题，安全问题分法员完成对新问题的确认， 修复负责人将组织修复团队并会根据问题的严重性，开发需要的时间和发布经理反馈的版本计划，综合自己最佳的判断来制定问题的修复计划。FATE 设立安全响应委员会/安全专委会， 安全专委会（Security Response Committee）是社区的安全合规工作机构，负责社区技术安全监督、开源合规管理，协同多方资源为社区生态安全保驾护航。 安全专委会的主要职责主要有三点：建立开源安全治理规范，推

40、进隐私计算领域开源软件风险治理工作；制定安全事件披露、应对策略，统筹应对安全风险，包括内部协作和对外披露，并及时处理安全问题；协同社区内外部资源，吸纳更多的安全领域专家，促进社区安全生态的管理和营运。 （四四）出海企业开源安全防范体系落地较早）出海企业开源安全防范体系落地较早 涉及海外业务企业精细关注开源安全隐患，追求漏洞快速响应。涉及海外业务企业关注开源安全隐患颗粒度细分至代码片段级别。 根据中国信通院调研数据显示， 涉及海外业务企业通常采购代码片段级别开源组成成分识别工具对所使用到的开源成分进行识别， 对应识别开源安全漏洞并对应分析是否所应用的开源代码片段部分涉及开源安全漏洞，同时给出修复

41、方案。涉及海外业务企业追求快速漏洞响应速度。根据中国信通院调研数据显示，涉及海外业务企业需要确保项目版本发布时使用的开源软件不包含已知漏洞或者已知漏洞已经关闭； 确保项目已发布版本中若新增开源漏洞时企业具备开源软件安全风险应对能力；构建企业产品、解决方案能够在较短时间内解决开源软件安全问题的能力。 20 四、开源安全防范需兼顾上游开源社区与下游开源用户 4.1 开源社区需建立安全开发规范 开源社区首先应对社区运营的开源软件提供安全开发规范指引，包括输入数据安全规范、编程习惯规范、异常处理规范及数据库使用规范等。安全开发规范应首先关注输入数据安全，要避免直接使用不可信数据拼接 XML 或记录到日

42、志中，注意从格式化字符串中排除用户输入。对压缩输入流做校验，防止 XML 外部实体攻击及 XML 内部实体扩展；对于跨信任边界传递的数据，要验证其路径；对数据格式做标准化并进行校验，重点防止 SQL 注入，避免直接调用操作系统命令解析器并防止命令注入； 安全开发规范应注重安全的编程习惯，要避免在日志中保存用户口令或者密钥， 及时清除存储在可复用资源中的敏感信息，正确使用经过安全验证的安全标准加密算法，不将敏感信息在程序中硬编码，不能在共享目录中创建临时文件。授权时，遵循最小权限原则；引入开源组件时，遵循组件建议的调用方法，在充分理解调用参数含义的基础上选择适合应用需求的参数； 安全开发规范应在

43、程序计算和异常处理方面给出建议，要避免使用整数溢出、除数为零、与空值比较、用浮点数作为循环计数器等可能导致计算结果和预期不符的操作，尤其是避免在分布式、多线程等不易复现的环境下，使用可能导致异常的计算。不要抑制或者忽略异常信息，出现异常后将系统恢复到异常之前的状态； 安全开发规范应关注涉及数据库使用的安全与效率，包括索引、分区、事务、死锁及 SQL 语句的 21 编写规范等方面。首先，应明确索引创建的原则，降低联机交易表上索引数量，优化复合索引，对高频访问的数据表应做分区索引，使用有业务意义的字段做主键，在外键字段上创建索引。其次，相同结构的表应尽量使用分区， 避免仅因为日期等细微业务不同就创

44、建过多的表。为提高管理精细度和可用性，应尽量避免出现过大的 segments，在单表分区时，应该控制在每分区记录的上限、分区的大小。此外，还应控制大型事务的回滚风险，对于联机业务系统，应约束每个事务影响的记录数上限，如果事务影响记录过多，应限制其提交频率。对于应用查询，须增加分页机制，对返回记录数进行控制，不要使用SELECT * FROM 的方式，并在前端防止客户反复点击同样的查询。 开源社区需进行开发过程全流程安全扫描与识别， 在开发阶段进行开源软件引入选型，关注开源软件社区活跃度、成熟度等指标项，同时建立安全编码要求， 通过自动化安全测试工具、 安全策略等手段，识别编码过程中的安全风险，

45、确保系统代码层面的安全性，进行代码相似度审查和依赖组件的安全管理；在测试阶段进行安全测试、代码扫描、模糊测试和渗透测试审查敏感数据、安全隐私、漏洞等问题并及时进行修复；在开源前进行发布阶段安全检查，确保开源软件开源或新版本发布之前具有明确的病毒扫描、完整性检查要求；自动化进行病毒扫描以及数字签名验证等完整性校验， 校验结果作为发布的前置条件； 开源软件开源或新版本发布之前具有完整依赖开源组件和软件清单列表。 开源社区需建立漏洞响应机制提高漏洞修复效率。 开源软件开源 22 后社区应持续进行开源漏洞跟踪与修复，根据安全漏洞情况，持续更新漏洞内/外部影响范围，如遇问题应及时组织相关人员对漏洞进行修

46、复。开源社区应持续进行健康度监测保障社区安全运维能力。评估者应检查开源软件所在社区具备以下组织多样性、贡献多样性要求：开源软件所在社区应具备组织多样性， 项目主要贡献者应来自不同国家或组织，社区组成多元化，对所有成员应一视同仁；开源软件所在社区应具备贡献多样性， 社区内贡献者应具备多样的贡献方式来保证社区的健康度，除了提交代码外，还可以包括社区管理、安全漏洞提交、项目布道、用户支撑、市场运营等工作；开源软件所在社区应进行社区活跃度监测，指标应包括项目状态、贡献者趋势、用户数量、社区文章阅读量、 用户案例趋势、 企业/组织劳动力投入和活动分析。 开源社区应进行分支版本与工作流管理提高开源安全。

47、开源软件所在社区具备以下分支版本与工作流管理要求： 社区的开发需要根据自己的项目规模和项目维护的策略选择自己项目的工作流； 下游的开发可能在局部采取不同于上游的工作流； 缺陷修复遵循上游优先的原则。先在上游修复；分支应及时合入主干，以减少合并风险；合入到主干分支之前都要进行充分的测试。 4.2 用户企业需建立开源安全问题修复措施 （一）安全漏洞和后门植入需按照轻重缓急应修尽修（一）安全漏洞和后门植入需按照轻重缓急应修尽修 随着软件开发过程中开源软件的使用越来越多， 开源软件事实上已经成为了企业软件开发的核心基础设施。开源软件由于其特殊性，横跨企业软件开发需求设计、研发编码、运维交付等多个环节，

48、在此 23 背景下，需要企业搭建新型的安全开发体系，进行安全左移，强化开源风险管控手段，覆盖软件开发的全生命周期，保障开源软件的开发和使用过程的安全可靠。 企业应在研发运营过程中持续进行开源安全扫描与识别，对于发现的安全漏洞和后门植入按照漏洞评估与解读、组件分析与修复方案制定三个关键步骤进行漏洞修复。 漏洞评估与解读首先为用户企业提供漏洞全貌。 首先组件漏洞扫描出来后，根据重要等级，发生时间和漏洞影响范围进行排序；第二步解读 CVE， 通过公布的信息与资料完成； 第三步分析涉及的系统等级及渠道， 需要重点关注对客互联网及网络区域中非安全区域的系统。 受影响组件分析为用户企业梳理漏洞修复优先级。

49、 通常单个组件漏洞职责单一的，这类漏洞较易处理；单个组件是框架类的处理起来比较麻烦；单个组件升级后相应关联组件或底层中间件需同步升级，处理中比较麻烦甚至可能需要修改程序代码；单个组件有漏洞，但相关程序代码未涉及的情况较易处理；单个组件含有另外一个组件，但未使用另外一个组件功能的较易处理。 修复方案制定应结合用户企业实际情况实施。 根据漏洞修复方案，安全问题可以由升级组件解决的情况优先考虑升级修复。 但此种修复方案会产生兼容性等问题， 升级框架或组件导致的兼容性问题因应用与漏洞情况不同没有通用的解决方案，但是有一些原则来参考： 安全检测“左移” 。在开发早期就执行安全检测；如果发现了安全问题，那

50、么选择安全版本时，可选取最新的稳定版，并建立开源资产清单，以便持续跟踪。 24 若系统已上线， “先评估后整改” 。若评估漏洞风险对系统的影响情况较小，可以考虑不采取措施，但要记录在案；若评估漏洞风险对系统安全性影响较大，但因为业务连续性要求，导致难以承受升级带来的系统兼容性风险， 则可以考虑是否有漏洞风险的缓解措施可以使用，如增加或修改安全配置、临时禁用受影响的功能等。但缓解措施宜作为临时处置方案，最终还是要升级到安全版本，从而从根本上修复漏洞；有些情况下可能没有适用的缓解措施，需要通过升级才修复高风险漏洞。在选择升级版本时不宜简单的选择最新的版本，最好是选择与当前所使用版本兼容的补丁版本或