开源治理初次实践

程序员一粟

已于 2024-01-06 18:22:18 修改

阅读量268

点赞数

文章标签：开源 web安全安全架构网络安全计算机网络网络安全

于 2023-10-23 11:02:50 首次发布

本文链接：https://blog.csdn.net/jennycisp/article/details/133984993

版权

前言：

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

CSDN大礼包：《黑客&网络安全入门&进阶学习资源包》免费分享

一、什么开源技术

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

二、软件开发和开源技术

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

三、开源治理框架

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

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

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

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

四、开源治理实践

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

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

4.1组织机制

整个组织的构成为：

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

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

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

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

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

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

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

实践过程：

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

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

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

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

4.2管理制度

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

1695896077_6515520d6dd1115055a3e.png!small?1695896078175

小结：

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

4.3存量盘点和风险管理

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

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

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

1695896163_651552633c766c548a5b2.png!small?1695896163224