前言：

随着时代的发展，开源技术运用的越来越广泛。在Synopsys的《开源安全和风险分析报告》（2023年）报告中，分析了1703个代码库样本，其中96%包含开源代码。据中国信通院《全球开源生态研究报告》（2022年）中统计，得益于开源技术的发展和广泛应用，开源软件为企业带来超过8%的成本节省。但新兴技术总是一把双刃剑，开源技术给各企业带来便利的同时，也带来了巨大的安全漏洞和合规风险。针对开源技术带来的安全漏洞和合规风险进行治理，已然成为了许多企业亟须解决的工作。本文就本人做开源治理的一些落地实践做一些简单分享和总结。

一、什么开源技术

《关于规范金融业开源技术应用与发展的意见》中定义，开源技术是指从代码托管平台、技术社区、开源机构官方网站等渠道获取，或通过合作研发、商业采购等方式引入的开源代码、开源组件、开源软件和基于开源技术的云服务等。

二、软件开发和开源技术

现代软件开发可以参考传统产品生产，传统产品是由原材料制作成中间组件半成品，然后再将中间组件半成品组装成完整的产品，即可做产品交付。而现代软件开发也是类似，开发者完成软件设计后，选型各种开源组件，再使用自己的代码将各个开源组件加工粘合到一起，形成各个软件模块，然后开发者团队再将各个软件模块通过各种协议组装到一起，形成最终的软件系统或平台。这一过程，可以称之为软件供应链。软件供应链带来的问题不仅包括开源组件问题，其中还有数据安全风险、接口漏洞、系统安全等等，但本文仅限于讨论其中的开源组件安全问题和治理实践分享。

三、开源治理框架

正所谓，理论是实践的基础，在实践前，首先得有一个理论框架作为基础。

中国信通院早些时间已经开始了开源治理的探索，在《开源软件治理能力评价方法 第3部分：成熟度模型》（还没正式发布）中，提出了开源软件治理能力成熟度模型框架，供以我们后续的工作提供了理论支撑。

开源软件治理能力成熟度模型

四、开源治理实践

最开始做这个事，倒不是什么政策要求，比如《“十四五”软件和信息技术服务业发展规划》中强化安全服务保障中要求的提升开源代码、第三方代码使用的安全风险防控能力，也不是刚刚提到的《关于规范金融业开源技术应用与发展的意见》使用开源技术时，应遵循“安全可控、合规使用、问题导向、开放创新”等原则去做这个事情。

做这个事情只是领导有想法，想从根源去减少应用漏洞的产生，类似SDL的安全左移思想，便有了开源治理（当时我们内部还没叫开源治理）的这个事情。

4.1组织机制

整个组织的构成为：

技术负责人（背锅和汇报的）主要负责整体开源治理负责人，统筹整体组织的运作。

领导小组成员为各组负责人，负责领导各小组开源治理的工作事项，处理在治理过程中各类冲突和矛盾问题。

安全组负责牵头整个开源治理工作，推进各个事项的进展，同时安全组下属的安全测试团队负责对漏洞的可利用性进行评估。

架构组负责开源组件的选型工作，在遇到开源组件升级替换时给出相关建议，并协助软件开发组进行开源组件升级替换等工作，并协助安全组进行相关开源组件的安全研究工作。

运维组负责协助安全组、软件开发组排查开源中间件、开源组件等安全风险问题，进行一些组件漏洞的缓解修复工作。

软件开发组负责确认开源组件安全问题，并针对开源组件进行升级替换工作。

项目管理组统筹项目开发工作事项，同时包括安排紧急组件漏洞修复工作，组件版本迭代计划等。

实践过程：

在启动开源治理时，牵头部门是安全这边，所以整体开源治理关注的点，聚焦在开源组件的“安全”和“合规”上面。

前期我们由安全组牵头，随之将架构组、运维组（这两个组愿意一起是因为组件漏洞着实消耗了他们大量的精力）拉进来一起做规划，而后又通过与软件开发组组长沟通，成功把开发组组长拉过来一起做这个事情。

在成功运作之后，有一定成果后，由安全组长向上汇报，成功把负责技术的分管领导拉进来，作为整个开源治理组织的负责人。自此，我们的这个开源治理虚拟组织自下而上成功成立了。

简单来说，组织机制已超过了成熟度模型中的基础级，正在以增强级为目标发展。

4.2管理制度

在开源治理过程中，需要制定制度规范各项开源治理工作的流程及要求。制度中分别明确了组织结构和组织职责，开源治理的目标，开源组件的使用流程，以及安全漏洞的处理原则。

小结：

在目前阶段，仅有《开源组件管理制度》作为治理依据，说是这个规范只是作为参考依据，但最主要的还是靠各个组长和分管技术领导的支持，可以说是管理制度只是刚好达到成熟度模型中的基础级要求。

4.3存量盘点和风险管理

在实践过程中，我们并未单独将存量盘点和风险管理分开，两个工作紧密相连，在本文中我就放在同一小结里。

在开源治理过程中，最核心的部分就是存量盘点工作，在我们实践过程中，称之为应用组件清单梳理，它既是统计了以往的应用组件清单，也是不断地将新应用新版本所引进的组件进行统计和登记管理。我们制定的应用组件清单是借助SCA（软件成分分析）工具进行梳理分析，记录了组件名称、简单描述、下载地址、厂商、版本号等（不包含漏洞信息），初步形成了SBOM清单，亦可称之为台账。

通过应用组件清单，我们即可进行风险发现，通过分析组件版本信息，可以从漏洞库获取到对应的漏洞信息。而这一过程都通过SCA工具进行自动化处理了，在发现风险后，我们在安全测试团队支持下，对漏洞的可利用性进行评估，再形成报告，通过漏洞管理平台（沟通机制）提交给对应开发进行修复工作。

而后在实践过程中，我们因为漏洞修复优先级问题，根据制度中的安全漏洞处理原则细化出了漏洞管理规范，用于重新评估组件漏洞的重新评分、明确需要修复漏洞优先级以及修复时间。误打误撞地已经把VPT（漏洞优先级技术）的理念实现了。

安全组定期将开源组件列表进行统计，进行风险分析和梳理，向开源治理组织汇报开源治理工作。存量盘点和风险管理两个维度基本都超过成熟度模型中的基础级要求。

意义：

其实在整个治理过程中，最重要的价值体现就在存量盘点和风险管理这一块。

1、通过建立应用组件清单，上级监管单位下发的组件漏洞排查工作，几乎是一下发，我们就可以响应，不像以前，一个组件漏洞排查工作，少说也得三四天才能响应完；

2、而通过风险管理，1年时间内，我们将平均1个应用30个高危、严重级别的组件，收敛到20个高危、严重级别的组件。可利用级别的组件漏洞全部清空。

五、总结

在成熟度模型中，还涉及到了测评选型、使用管理、运维管理、定期健康、退出管理和第三方管理工作。限于我们的治理精力，我们并未对其他维度进行更细化的工作，但简单来说，其他维度大部分都满足成熟度模型中的基础级要求。

在未来的工作中，我们将开始迈入上述成熟度模型中组织机制、管理制度、存量盘点和风险管理的增强级要求建设工作，完善测评选型、使用管理、运维管理、定期健康、退出管理和第三方管理工作的基础级要求。开源组件的许可证问题也将在未来，开始着手进行初步的治理工作。

治理工作任重而道远，正所谓饭要一口一口吃，步子迈大了容易扯到蛋。

初次执笔发表文章，欢迎各位大佬留言指点。