汪杰：企业开源治理实践指南

开源软件运动起源于20世纪80年代，随着GNU计划、Linux操作系统和Apache HTTP服务器等项目的兴起，开源社区开始吸引越来越多的开发者和组织，这一运动推动了开源软件的广泛应用，然而随着开源项目的数量和规模不断增加，项目的管理和协同变得更加复杂，大型开源项目往往涉及多个贡献者、组织、代码库和依赖关系，需要更强大的治理结构。

对于贡献者和组织来说，随着企业对于开源项目的积极参与，导致了开源和商业之间的相互作用，比如开源软件的使用和分发问题，会涉及复杂的法律和知识产权问题，如开源许可证合规性、专利侵权等。除了企业外，开源项目也吸引了来自不同文化和背景的参与者，在这种多样性下，开源治理需要考虑社区成员之间的不同需求和观点，以确保包容和公平。因此，开源治理也需要解决项目可持续性和融资的问题。

对于开源技术来说，开源项目通常处于技术演进的前沿，同时也涉及到标准化和互操作性。因此，开源治理需要协调技术和标准的发展。

对于开源社区来说，开源社区越来越关注社会责任和伦理问题，包括开源软件的社会影响、可访问性和包容性等。这些问题需要在开源治理中得到反映和解决。

综上所述，开源治理的背景反映了开源软件社区的快速增长和多样性，以及开源项目在技术、社会和商业领域的广泛应用。为了应对这些挑战，开源治理需要采取适当的决策和管理模型，以确保开源项目的可持续性和成功。

经过我们多年的客户服务经验，发现企业中存在的开源治理问题有以下几种情况：

1）不知道开源治理怎么做，缺乏基于企业内部现实情况的开源治理工作指导；

2）企业内开源组件的使用情况不明，无法实行有效监管；

3）开源组件漏洞信息感知及发现不敏感，经常容易引发安全事件；

4）对于治理工作希望能实现全流程的自动化集成，不需要或者仅需要少量人工干预工作；

5）缺少漏洞及合规风险的影响分析，无法形成有效的安全决策；

6）缺乏行之有效的开源组件风险修复手段；解决这些开源治理问题需要建立明确的政策、流程和责任，以确保开源组件的合规性、安全性和可维护性。同时，不同企业可能需要根据其特定的需求和环境定制开源治理策略。

通过多年的开源治理工作经验的总结，此处重点在组件引入和使用、漏洞风险管理与合规风险管理最关键的三个方面进行分享和介绍。

1.开源组件引入和使用规范

开源软件的引入是企业解决开源问题的重要流程，对于开源软件的引入，使用单位需要关注和遵循以下规范：

1）对于正在引入的开源组件、开源代码、开源软件，需要提供详细安全审计证明。如：国际/国内的第三方证明等。

2）提供完整且详细的软件资产成分清单，并且清晰呈现引入组件的漏洞风险及许可信息。包括但不限于：组件名称、组件版本、风险等级、漏洞情况、许可情况、修复建议等。

3）提供交付物的软件物料清单（SBOM）交付能力，可提供轻量级CycloneDX或SPDX国际标准。

4）提供交付物的组件资产清单需要清晰展示组件间的依赖关系，比如直接依赖和间接依赖。

5）不允许出现难以验证来源的组件，原则上如果确需使用的，则需要提供相关详细证明，比如组件的来源，安全风险审计报告，同时确保掌握代码结构和技术原理，具备修改和二次开发能力，并进行醒目标注，说明原因等。

6）不允许出现较老（3年以上）的组件，原则上如果确需使用的，则需要提供相关详细证明，比如组件的来源，安全风险审计报告。

7）不允许出现已经停服/闭服的组件，原则上如果确需使用的，则需要提供相关详细证明，比如组件的来源，安全风险审计报告。

8）不允许出现带有中危及高危以上漏洞风险的组件。

9）不允许出现带有传染性许可的组件。

10）提供的交付物需要提供明确的清晰的组件作用域信息，如：Java语言下Compile、Test、Runtime等。

11）不允许出现引入组件中存在签名不一致的组件，如某组件属于开源组件但是Hash认证发生变更。

12）详细提供使用组件的引入详细路径，包括文件方式的行级引入与二进制的目录引入信息。

13）记录和保留开源软件、第三方组件的原始供应方、开源社区或开发贡献者等相关信息。

14）外采/商用软件入网前需要完成软件资产的安全检查，检查结果由专业人员进行评估和分析，需要修复的问题，并第一时间提交给供应方进行修复整改。

15）提供组件的基本状态信息，包括开源、非开源、自研等。

2.开源组件安全风险管理规范

1）开源组件安全管理人员应明确组织内部的相关开源安全基线标准，并建立可对内公开的开源安全白名单库，同时对于基线过程中的变更信息，包括变更原因和变更时间等关键信息，进行记录和存档。

2）开源组件在环境内安装前必须确认版本信息，版本信息须来源于官方发布版本。对于开源组件的获取及维护活动以及对遗留系统的变更都应该进行软件安全评估及计划，并进行安全计划评审，以确保软件安全计划得到正确的执行。

3）开源组件在环境内安装后，必须通过开源环境漏洞检测流程，对开源组件漏洞进行全面扫描，并得出结果报告。报告由相关安全管理人员进行审查后给出建议并归档。

4）开源组件使用过程中，每一次版本变更，必须由开源环境漏洞进行监测，监测结果生成报告。

5）开源组件所安装、调试的系统环境必须长期处于开源环境漏洞监测工具的实时监控之下，私自卸载、改装、屏蔽等影响开源软件环境漏洞监测的行为均属于违规行为，不符合规范的执行。

6）开源组件使用前后检测或检测所产生的漏洞结果报告，必须由专人负责统计和管理，由专业人员进行评估，并第一时间提交给有关部门的负责人。

7）开源组件使用过程中，所产生的漏洞必须尽快根据漏洞结果报告的建议修复方式进行漏洞的修复工作，负责人有义务监督并管理整个漏洞修复的实施过程。

8）必须定期检查开源组件的运行状况、定期调阅软件运行日志记录，进行数据和软件日志备份。将这些进行文档化保留。

9）禁止在服务器上进行试验性质的软件调试，禁止在服务器随意安装软件。需要对服务器进行配置，必须在其它可进行试验的机器上调试通过并确认可行后，才能对服务器进行准确的配置。

10）对会影响到全局的开源组件更改、调试等操作应先发布通知，并且应有充分的时间、方案、人员准备，才能进行软件配置的更改。

11）对开源组件配置的更改，应先形成方案文件，经过讨论确认可行后，由具备资格的技术人员进行更改，并应做好详细的更改和操作记录。对软件的更改、升级、配置等操作之前，应对更改、升级、配置所带来的负面后果做好充分的准备，必要时需要先备份原有软件系统和落实好应急措施。

12）不允许任何人员在服务器等核心设备上进行与工作范围无关的软件调试和操作。未经允许，不允许带领、指示他人进入机房、对网络及软件环境进行更改和操作。

13）应严格遵守张贴于相应位置的安全操作、警示以及安全指引。

14）提交证明具有漏洞分析及处理能力，包括但不限于：漏洞编号、漏洞名称、利用难度、弱点类型、漏洞描述、CPE、CVSS2/3得分、发布时间、关联其他漏洞编号、修复建议等信息。

15）提供新漏洞应急处理方案证明，方案中应约定根据不同漏洞严重及影响情况，提供配套的处理时间安排，包括高危及以上漏洞应该在24H内提供预警，并给出相关处理方案，中危漏洞应该在3—5个工作日给出预警，并提供相关处理方案，低危漏洞应该在15—20个工作日给出预警和相关处理方案。

16）提供新漏洞影响范围分析报告，报告中对漏洞的影响组件、影响的产品进行明确说明，供使用方进行风险评估，并进行分级分类的处理。

3.开源组件合规风险管理规范

1）安全管理人员有义务告知组织内人员相关许可知识，可阶段性组织相关许可的解读培训，明确许可使用范围和建立明确的使用标准和使用范围要求通知。

2）针对交付物中存在的传染性强的许可，如AGPL、GPL类，需要明确许可的使用规范要求，并制定相关处理措施和方案。

3）针对交付物中存在LGPL、EPL类等弱传染性许可，需要提供相关证明，证明当前引用的合规性。

4）针对交付物中存在无许可标识的组件，合规人员需要重点关注，并进行结果审计，对于明确无许可的组件，需要及时通告组织并加入整改清单中。

5）针对交付物中因同时出现存在多个许可而导致的冲突问题，如Apache-V2与GPL-V2、LGPL-V3与GPL-V2等，需要建立许可冲突清单，并及时通告组织相关人。

6）对于自研组件的许可，需提供详细组件说明及严格遵循开源许可证的要求，如特定的权属说明等。

7）应输出一个真实、完整、可信的分发说明，证明解决方案提供商针对开源许可证合规风险已开展哪些治理工作，如：对某些采用GPL许可证的组件独立进行构建分发等。

8）应明确交付物中各个开源组件的开源许可证，并且提供相关组件与许可的关联信息材料。