企业开展开源安全治理必要性及可行性详细分析(1)

作者：菜鸟追梦旅行 | 2024-04-13 20:27:15

踩

但是面对这样一个热门的方向，行业头部企业都在积极投入和规划，我们应该如何客观看待，开源安全治理到底是昙花一现的伪需求？还是企业真正值得长期投入的新方向？我觉得我们需要冷静客观的深入分析一下它的必要性及当下开展这项工作的可行性，这篇文章我会结合我自己过去在企业甲方的实践经历和墨菲安全创业过程中做开源安全治理产品工具的经验心得，对这两个关键问题进行深入剖析，文末也欢迎大家参加有奖调研和我讨论。

从我沟通和调研过的各行业数百家企业中，其中开源安全治理的必要性大家已经有基本的共识了，关于可行性是目前大家讨论和担忧比较多的，所以本文也会重点分析可行性，如果你只关注可行性的分析，请直接跳到第二部分。

必要性分析

回答一件事情的必要性，我们可以从长期和短期两个视角来分析，长期我们主要看趋势及其必然性，短期我们看需求的刚性程度。

长期来看**，**随着全球及中国数字化程度越来越高，企业对于软件的制造和生产的需求越来越大，软件制造的供应链会越来越成熟，就像过去几十年汽车制造的发展过程一样，随着人们生活水平的提升，出行需求的快速增长，复杂的企业工业到今天拥有非常成熟的供应链体系。而一个成熟的供应链体系就需要不同的供应商将一个个具体的需求转化成标准件，最后由企业根据它的需求将这些数百个甚至数千个不同的标准件组装起来，完成一个成品软件的生产制造。

而开源软件就是软件制造工业的供应链体系中，数量最庞大的标准件。随着未来数字化需求的不断增长，开源软件的数量及其应用量只会越来越高。由于开源软件的开放性及软件开发过程的复杂性，必然导致这些开源软件会存在大量的安全漏洞缺陷，而这些漏洞缺陷会传导到最终企业加工出来的成品软件中。从而使得企业应用软件中大量的安全漏洞缺陷来自它的开源软件供应链。在这种情况下，黑灰产为了寻找漏洞来攻击企业以牟利，必然会有越来越多的开源组件漏洞被发现和利用。

所以，长期来看随着企业应用的开源软件越来越多，这些开源软件的安全漏洞在黑灰产攻击者的利益驱使下会以更快的速度和更高的频率被曝出，进而使得开源软件的安全威胁成为企业面临的主要威胁。

短期来看，开源安全治理的紧迫性主要来自企业需求，而企业的安全需求通常来自两方面，一方面是安全事件驱动，另外一方面是政策合规要求。

LockBit勒索团伙相信大家都听说过，去年底工行美国子公司被勒索事件就是出自LockBit，据海外多家网络安全公司（包括Dragos、Malwarebytes等）统计分析，全球有超过1/3～1/2的勒索攻击事件来自LockBit，而LockBit最惯用的攻击手法之一就是利用各种开源软件的0day/1day漏洞进行攻击，之后实施勒索行为。而在2024年2月，美国、法国、英国等国执法机构联手对头号勒索软件组织LockBit展开了大规模清剿，这个代号“克罗诺斯行动”的行动，对LockBit团伙用来做勒索的相关系统后台进行了渗透攻击，而此后披露的信息来看，执法机构用来渗透攻击LockBit的漏洞也是开源软件PHP的一个0day漏洞。由此可见在主流的网络安全攻防战场，最高效和主流的攻击方式都是围绕开源软件的漏洞展开的。

而且值得关注的是，勒索团队的攻击往往是全球化无差别的攻击，任何一个企业，只要有软件服务暴露在公网都有可能被攻击，他们通常对全球的互联网进行开源软件的0day/1day进行扫描，一旦发现哪个企业暴露在互联网上的软件存在漏洞，马上启动自动化的数据加密勒索攻击。而往往任何一个企业通常在这三个时间点容易遭受勒索攻击：

在进行软件/应用的更新和新发布时（此时往往意味着引入了新的组件漏洞）；
一个新的开源软件漏洞被曝出时；
一个老的开源组件漏洞被第一次曝出poc/exp时；

而每年国家及各地区的大型攻防演练中，开源软件及商业软件中依赖的开源软件的漏洞也一直都是近几年红队用来攻击目标单位的主要手段，由此可见，从红队的视角来看，国内各行业企业主要的安全缺陷也是来自软件供应链，包括商业软件供应链及开源软件供应链。

不管是勒索攻击还是大型攻防演练，当前针对开源软件的攻击事件已经严重影响到了国家一些重要的基础设施单位及企业，所以不管是从欧美还是中国来看，政府近几年都密集出台了大量法律法规来要求企业和政府事业单位加强开源软件安全治理。

所以，从短期来看，企业开展开源安全治理目前也是各行业企业和政府监管的共识，因为各方也都面临这同样的威胁。

可行性分析

可行性分析的目的是全方面调研分析该项目是否具备在企业成功落地，达成预期效果的可行性，分析思路上我们可以从行业最佳实践效果、技术方案成熟度、关键难点及挑战应对方案等多方面进行分析。

我自己因为创业的原因，过去三年一直专注在软件供应链安全领域，所以跟各个行业企业做安全的朋友们交流最多的当然也就是这个方向，在软件供应链安全领域，相对来说大家今天关注最多的其实就是开源安全治理。其中有一部分企业的安全负责人在真正开展开源安全治理工作时多少有些顾虑，主要顾虑的点还是这项工作建设的可行性。

主要挑战（坑在哪？）

从跟大家交流来看，首先大家认为开源安全治理时一项非常复杂且具有挑战的工作，它的挑战主要来自五个方面：

企业引入开源软件的方式非常多，管控复杂：包括自研的软件中自主引入，也包括采购的商业软件中引入的开源组件，同时还包括大量免费的办公软件中也会引入大量的开源组件。这里面包括直接引入和间接引入，所谓间接引入就是直接引入的这些开源组件本身又依赖了大量开源组件，而商业软件和免费的闭源软件中引入的大量开源组件对于企业来说是黑盒不透明的，管理起来难度更大。
开源软件的类型非常多，管理标准不一，治理难度大：企业自研及外部引入的软件中，涉及的开发语言主流的有5～6种，还有10～20种不是很主流的开发语言。这些不同语言的开源组件在治理时会给识别和治理的难度大大增加，因为这些不同语言的开源组件的包管理工具生态不一样，包管理生态的成熟度也不一样，甚至一种开发语言有多种包管理工具的生态，比如Java的Maven和Gradle等，而c/c++干脆没有什么特别成熟和覆盖度高的包管理工具生态，甚至很多研发人员在使用开源组件时会魔改这些开源组件以及不使用规范的包管理工具来管理其代码项目的开源组件的引入。
开源软件的治理涉及的相关方较多，内部推动难度大：因为开源软件在企业内使用广泛，且几乎涉及到软件开发的所有流程，所以开源安全治理几乎与所有的技术部门都相关。当然最主要的挑战还是来自软件研发人员和安全管理部门之间的协同。软件开发人员在开源软件方面更关注软件工程问题，而安全管理部门更关注安全及合规性问题，而两者之间往往存在一些冲突。此外，就是软件研发人员更懂工程但是缺乏安全知识，而安全工程师更懂安全风险但是缺乏工程知识。而开源安全治理工作是同时需要具备这两方面知识的，这就使得双方必须协同。
行业缺乏成熟的技术工具来支撑开源安全治理工作，无法闭环落地：因为开源软件在企业的应用模式和自研代码有很大的区别，导致过去应用安全相关的工具在开源安全治理时并不适用，过去市面上大多数应用安全类的工具（SAST/IAST/DAST/SCA等）大多数都是针对企业自研代码产生的漏洞进行治理的，多数都是侧重代码安全漏洞的检测，而非常轻修复的能力。实际上研发自研的代码部分自己发现漏洞进行修复相对简单，毕竟自己写的代码。但是开源组件的很多漏洞企业开发者没办法自己改代码去修复（而且从工程管理的角度上也不建议自己去改人家开源组件的代码来修复安全问题），这就导致过去的工具失效了。当前的局面是，企业检测出来大量的开源组件安全漏洞，修复成本极高，这就导致研发很抵触这项工作，从而难以运营落地。
行业缺乏成熟的治理体系和成功的最佳实践，缺乏参照：根据我的观察，国内企业在开源安全治理方面，3-5年前开始有一波金融&互联网行业先行试点过，从效果来看，只有极少数一波企业（蚂蚁似乎做的还不错）效果相对还不错，其他的大多数基本上都踩到坑里了。这就导致这两年大家再开展治理的时候一方面并没有很多成熟的最佳实践参考，另外一方面也多少没有太多信心。