直播回放 | 周幸：开源治理实践如何实现自动化和智能化落地

直播回放 | 周幸：开源治理实践如何实现自动化和智能化落地

“网安强中强”2022（第二届）数字安全创新实践直播大赛自2022年4月18日起正式启动。悬镜安全技术合伙人周幸接受了主办方安在的特邀，于4月19日做客直播间，以“开源治理实践如何实现自动化和智能化落地”为主题，分享了悬镜在开源治理方面的实践经验以及成熟的落地解决方案，在直播间和用户交流群中引起了热烈的讨论。以下为直播分享实录。

 

一、开源安全背景和现状

首先，众所周知，现在的企业正大量使用开源组件。从最初的瀑布式开发模式到敏捷开发模式，再到DevOps，开发模式的转变使得软件迭代和发布的速度变得越来越快。在这个过程中，除了自研代码，还引入了大量的开源组件。Gartner的报告显示，99%的企业在研发过程中都使用了开源组件。

其次，开源安全漏洞频发。比如去年的Log4j2事件和今年的Spring事件，这些主流的开源组件或框架，这些年来爆发漏洞的频率是越来越高，而且波及的范围也是越来越大。国家互联网应急中心的报告也显示，近六年来整个开源组件生态的漏洞数在逐年增加。

第三，开源组件一般会带有开源协议，所以会存在开源知识产权的风险。去年在国内就发生了几起关于开源组件和开源软件的知识产权纠纷事件。目前国家越来越重视自主创新和自主研发能力，强调自主知识产权。

第四，开源相关法律和政策相继出台。去年，开源首次被列入国家“十四五”规划和2035年远景目标纲要。在金融行业，五部门联合发文，出台了《关于规范金融业开源技术应用与发展的意见》。可以陆续看到在国家层面，在垂直行业内部，开始慢慢强调开源治理的规范性。

在这样的安全背景下，我把目前面临的安全现状总结为“四个不”。

第一个是“理不清”。企业不清楚在系统中使用了多少开源软件和开源组件。目前很多企业的现状是，在每一次快速迭代和快速发布过程中，都会引入一部分开源组件或者开源软件，但是由于团队多、涉及的业务范围广，导致无法清楚地知道具体使用了哪些。

第二个是“看不见”。企业在使用开源组件和开源软件的过程中，不知道它们中有的已产生过安全漏洞和知识产权风险。根据我的经验，很多企业用了一些非常老的组件和软件，之前爆发过很多安全漏洞，但没有及时去更新，所以对于这些已知漏洞的风险隐患，企业无法获悉。

第三个是“找不到”。企业在开源组件和开源软件出现漏洞的时候，无法快速地定位受影响的组件以及评估影响的范围。以去年的Log4j2事件和今年的Spring事件为例，当出现漏洞的时候，大部分人的第一反应往往是希望能够快速地找到受影响的组件，第二步才是设法进行治理。

第四个是“治不了”。当企业明确漏洞影响的范围以及受影响的组件并定位到具体项目，这时就需要进行相关治理工作，对组件进行相应的评估和修复。很多企业相对比较缺少这一方面的专业安全知识。

二、开源治理痛点

在进行开源治理之前一定要知道有哪些痛点，根据这些痛点再相应地建设开源治理体系。

先给大家介绍下开源治理“三要素”。无论是应用开发安全还是整个安全体系的建设，都有三个非常重要的环节：工具、人和流程制度体系。在整个建设过程中，我认为是可以以开源安全治理工具为基础，通过人员赋能，最后去推进整个流程制度体系的建设。

 为什么以开源治理安全工具为抓手?如果一上来就推进文化或者流程制度的建设，很难在短时间内得到想要的成果，因为如果缺少相应的自动化工具去寻找问题和解决问题，成果很难度量。所以我建议以开源治理安全工具为基础，在开源治理的各个阶段和各个流程进行自动化和智能化的检测。

在工具的基础上，要对相应人员和组织进行培训和文化赋能，比如对高危协议的讲解，对高危“0day”漏洞的及时分析培训，提高大家对开源安全的认识。

最后，在以工具为抓手和人员赋能的情况下，推进整个流程和制度的建设，最终完成整个开源治理体系的建设。

接下来给大家介绍一下开源治理的三个风险点。

首先最重要的是组件。要清楚地知道组件的依赖关系并且进行影响分析。当漏洞爆发的时候，优先去定位组件，明确哪些部门或者哪些项目使用了这些组件，再去根据部门或者项目找到受影响的软件产品并进行修复。

其次是漏洞。不是所有漏洞都要去修复，从安全治理平衡的角度来说，应该更加关注那些对业务影响比较大的或者是危害比较大的漏洞，所以要对漏洞进行影响分析和定级。比如当出现“核弹”级别的如Log4j2漏洞的时候，是要及时修复的，因为受影响的面很大而且它的利用难度相对较低。

第三是许可证。近几年一直有关于GPL协议的知识产权纠纷。随着大家慢慢重视知识产权以及相关法律部门的介入，对组件的知识产权进行风险解析包括对其许可证协议进行分析变得越来越重要。

接着介绍开源治理的阶段流程。任何一个流程引入，它都应该是紧紧贴合目前已有的流程基础，为什么？开源治理的四个阶段流程，分别是引入、使用、运营和停止，与软件开发生命周期中的需求设计、编码、测试、发布上线运营是不是有类似之处？

具体谈谈这四个阶段流程。首先，什么是引入呢？企业自有的研发人员或者第三方供应商，在使用组件的过程中，无论从外部渠道引入还是从本地私服库引入，都属于引入流程。

其次，使用流程包含了编码阶段、持续集成和持续部署的阶段。

第三，运营流程。上线后对漏洞的预警和对漏洞的及时处理都属于运营环节。

第四，停止流程。当组件爆发漏洞的时候，定位这些组件，想办法进行及时的停止并同时更新，就属于停止流程。

所以整个开源治理的阶段流程与软件开发生命周期是可以在某些阶段进行融合的，后面我也会讲到如何进行结合。

三、开源治理方案

在以上这些认知基础之上，接下来要展开整个开源治理的方案。

第一部分是组件分析，对应三个风险点中的第一个点。组件分析需要支持开发阶段、CI/CD阶段以及测试阶段，全流程对开源组件的检测，梳理并管控开源组件的信息，并从企业、部门、项目及任务等多角度分析组件的影响范围和依赖关系。为什么？一个简单的道理是，当漏洞出现，尤其是“0day”漏洞爆发，大家在第一瞬间的反应是什么？是要定位，要清楚地知道哪些部门、哪些项目组、哪些APP受影响。在此基础上，才会针对性地寻找适合的防护手段，选择是从网络层、主机层还是从应用层去做阻断和防护。基于多维度的依赖关系分析，通过自动化和智能化的工具去协助企业形成SBOM清单，从而在追溯的过程中，能够快速地定位受影响的组件。

第二部分是漏洞分析。漏洞的来源非常多，但是一般会要求漏洞信息兼容OWASP TOP10、国家信息安全漏洞库（CNNVD）、国家信息安全漏洞共享平台（CNVD）及CWE标准。同时我们也希望能够监控开源社区、漏洞情报中心等。将这些漏洞数据收集之后，通过数据的清洗、关联和匹配，再结合企业形成的组件SBOM清单和引擎进行实时地分析。这样做的好处在于，引擎端会实时地跟线上的情报中心进行同步，当产生“0day”漏洞的时候或者发现一个新的组件漏洞的时候，能够实时且及时地向用户告警。用户在此基础上可以找到受影响的组件。漏洞分析最重要的点就在于建立漏洞库、组件库以及特征库等，结合引擎，对SBOM清单，对组件进行实时分析。

第三部分是许可证分析。开源促进组织OSI颁发了上百个开源许可证协议。要对这些开源协议进行风险梳理，尤其当引用了强传染性的协议时，要特别注意通过智能化的分析去找到相应的组件。当然通过组件也可以找到相应的许可证协议。这样就能够及时确定组件或者项目的知识产权风险。

在开源治理过程中，针对三个风险点需要掌握相对应的治理能力，同时也需要将能力和流程结合。安全和开发之间有时会有矛盾，当安全尝试介入时，原有的快速发布和快速迭代更新的目标可能会受到影响。所以安全工具、安全治理体系的引入要在不改变现有开发和测试模式的前提下，不影响业务发展流程，要给整个流程带来附加价值，这就需要结合整个软件研发流程去进行。

在编码阶段用户可以引入IDE插件，比较多的是Eclipse和IDEA。在编译器上，当引入组件包时做实时分析，将结果直接反馈给开发人员，也就是用插件的方式进行及时审查，在开发侧发现问题后做及时修复。

在提交代码到代码仓库的环节中，可以对接Git/SVN仓库。在这个过程中，可以对提交的代码做全量的检测。

在使用的过程中，可能会用到Jenkins或者商业化的DevOps平台，可以用插件化或者是流水线脚本的方式，结合引擎进行实时检测。这样做的好处是可以结合现有的发布流程做一些卡点设计等。当通过引擎的集群检测，与代码、组件、漏洞的仓库进行关联匹配之后，可以把数据同步到可视化界面上，甚至可以同步到用户内部的bug管理平台比如Jira、禅道，这样用户不需要登录其他平台就能查看漏洞。

 最后，在这些基础之上，建立整个制度体系。其实在每一个阶段都可以通过工具化的方式实现自动化和智能化。比如引入阶段，在本地库里没有找到对应组件，那么在向上申请的过程中，可以用自动化工具做能力的审核，检测组件是否存在漏洞问题。在软件使用的过程中，可以形成组件清单，当漏洞爆发时，可以快速定位到那些有问题的或者受影响的组件。在运维或者安全漏洞持续评估阶段，当发现安全漏洞时，可以通过相应的治理工具能力去告诉用户哪些项目是受影响的，有哪些修复的方案。

至于开源治理工具，应该要继承应用安全缺陷检测等核心能力。

第一点要求是要有丰富的语言支持和海量的知识库支撑。每一个企业都会用到很多语言，除了前端和后端，还包括随着市场需求变化引入的新技术和新框架。这就要求工具的检测能力要有非常大的覆盖面。知识库包括组件库、许可证库和特征库等，有大量的知识库支撑才能使分析结果比较完善。

第二点，要具备组件依赖解析和可视化SBOM分析的能力。从组件定位到相关部门和企业，从相关组件的漏洞定位到受影响的组件，这实际上是多维度关联分析。同时通过工具化的方式，生成可视化的SBOM清单去帮助企业快速梳理内部的资产。

第三点，要具备许可证分析能力。要能够做到对主流许可证的检出以及对合规性和兼容性的检测。

第四点，拥有企业级的核心引擎。整个引擎能够独立出来，那么基于海量的知识库，对特殊的特征文件能进行精准识别，提高组件的检出率。如果知识库的体量不够大，不是企业级的检测和分析引擎，检出的结果一般是比较差的，误报率会比较高，同时给出的修复建议和方案也不能够满足企业需求。

因为技术是在不断演进的，所以在介绍完基础的工具能力之后，给大家简单补充能力提升的一些方向。比如在静态分析的情态下，除了基于依赖关系分析、基于文件级别的分析、基于代码片段的分析，还有动态组件的实时分析。它是在测试环境，依赖IAST插桩技术原理，在用户进行功能测试和性能测试的同时，发现运行中相应组件的信息。这就能够避免数量巨大的误报和检出无法应用的漏洞，因为在静态分析中，有一些实际上未被使用的组件，如果都通报，对于开发人员来说，修复难度是比较大的。

 开源治理工具还要与开源治理方案的三个阶段也就是安全开发、安全测试和安全管理相结合。

在安全开发阶段，首先，工具需要结合企业的IDE，做到安全前置，帮助开发者快速定位漏洞并提供修复方案。其次，工具具备的企业级核心引擎要支持二次开发，因为每家企业的情况是不一样的，需要对接不同的工具和平台。第三，工具对于开发人员要友好，不能增加他们的工作量，还要给他们带来文化和价值的赋能，提升他们相应的能力。

在安全测试阶段，工具要具备对产品第三方开源组件的安全性测试功能和系统上线前开源组件的安全审查功能，帮助提高软件产品的安全性，防止应用带“病”上线。

在安全管理阶段，第一点是对第三方组件和供应商软件的安全准入，一定要制定相应的准入标准和评估体系，这与软件供应链安全也是相关的。第二点是在企业内部建立安全组件库，比如maven私服库等，好处在于有一个统一管理的组件引入来源。第三点是软件和组件的可视化清单分析。有了这样一个清单，就能够及时地进行相应的定位。最后一点就是要助力安全部门的合规审查及相关开源治理工作。我们会发现安全合规以及法律部门的介入，都在慢慢推进整个开源治理体系的建设。

四、自动化智能化落地实践

最后简单介绍一下自动化和智能化的开源治理落地实践。这是悬镜安全在结合某家企业自有的DevOps前提下，形成的DevSecOps开源治理体系，覆盖编码和CI/CD等阶段，在引入、使用等相关阶段集合引擎进行相关组件安全质量控制。

 整个体系可以分三层。上面这层是不同人员的介入，包括项目经理、研发经理、测试人员、运维人员。中间这层就是软件开发生命周期，包括需求下达、进入研发、触发构建、提交测试、提交预发布以及提交发布这些不同阶段。下面这层就是相应的开源安全工具能力的嵌入。

在整个开源治理过程中，也是以工具引入为抓手，把工具能力嵌入现有的流程，并解决了三个问题。

第一个问题就是在引入环节如何进行管控。开源组件从互联网到进入本地的私服库，就需要解决引入来源的问题。这家企业的第三方外包人员和自有的研发人员都会从本地的私服库去下载开源组件，那么就要保证私服库的安全性。当我们的引擎和私服库进行对接时，可以做定时的扫描，帮助发现漏洞问题以及督促更新解决。私服库已有的组件可以通过这种方式去检测，但是从互联网引入的组件，该怎么确保其安全性？这家企业原本就有一个内部的评估流程和评估体系，通过一个审核平台让开发人员线上提交审核申请，在审核过程中，系统会告知组件是否合规，存在哪些漏洞，最安全的是哪个版本，最新发布的是哪个版本，这些能力都可以通过引擎端的接入实现。比如发起一次审批，把组件的相关信息发给审核平台，接入我们引擎端的能力，在审批之后，如果发现该组件没有高危漏洞，就可以直接通过平台自动化地从网上下载。如果存在高风险，整个评估流程就会被阻断，同时会告知阻断的原因，还会建议其他安全版本的组件。

在解决引入问题之后，第二个要解决的是增量和存量的问题。如何解决存量的问题？先对接仓库地址，对仓库进行相应的扫描，检测出已经发生漏洞问题的组件。如何解决增量的问题？流程中间有个触发构建的环节，当有新的应用发布时，可以将引擎能力嵌入现有的流水线中做实时的检测。

第三个要解决测试环节的问题。当进行功能测试和性能测试时，通过IAST插桩技术去分析运行时第三方组件，提高检测第三方组件的精准率。

总的来说，给这家企业建设整个开源治理体系也是分了三步。第一步，在引入环节，管控组件来源。第二步，解决增量和存量的问题，审核现有的和未来新增的组件。第三步，在功能测试和性能测试的时候去做最后阶段的审查。

在整个过程中会发现，人员介入相对比较少，很大程度上是依赖工具化的方式，包括审批流程也是通过自动化的工具去帮助完成。

以上就是我今天想与大家分享的，就是如何通过自动化和智能化的工具方式去实现开源治理体系的建设。要注意的是，在这个过程中，要结合企业内部的实践情况，慢慢优化整个开源治理体系，最终实现开源治理体系的闭环。

我的演讲就到这里，感谢大家。

关于悬镜安全

悬镜安全，DevSecOps敏捷安全领导者。由北京大学网络安全技术研究团队“XMIRROR”发起创立，致力以AI技术赋能敏捷安全，专注于DevSecOps软件供应链持续威胁一体化检测防御。核心的DevSecOps智适应威胁管理解决方案包括以深度学习技术为核心的威胁建模、开源治理、风险发现、威胁模拟、检测响应等多个维度的自主创新产品及实战攻防对抗为特色的软件供应链安全服务，为金融、能源、泛互联网、IoT、云服务及汽车制造等行业用户提供创新灵活的智适应安全管家解决方案。更多信息请访问悬镜安全官网：www.xmirror.cn