技术分享 | 企业级开源威胁治理实践探索

企业开源软件应用空前广泛。闭源的系统软件、关键软件一旦存在后门，危害巨大，且难以检测识别。而开源替代品由于源代码开放，存在后门的隐患较小，出现漏洞时便于从源代码层面进行主动修复。此外，大量开源软件的免费使用，让初始费用较低，因而开源软件应用日趋广泛。企业如何对数量庞大的开源软件进行威胁分析，并合理进行开源治理成为了首要的问题。

2021 年 9 月 17 日，由中国信息通信研究院、中国通信标准化协会联合主办的“2021 OSCAR 开源产业大会”在北京召开，大会旨在进一步探索我国开源生态发展模式，加速开源技术在国内市场落地，提升企业开源治理能力，推动国内开源生态快速、健康有序发展。

悬镜高级解决方案架构师凌云应邀参会，并发表《企业级开源威胁治理实践探索》主题演讲，与现场观众分享了悬镜安全在企业级开源软件威胁分析与开源治理方面的实践经验。

凌云

悬镜高级解决方案架构师

【演讲实录】

大家好，今天与大家分享的内容分为两个部分，第一，开源软件的应用背景分析，即为什么要做开源治理，以及开源治理的方法、路线和目标。第二，对开源治理的部分实践与探索的介绍。

开源软件背景分析

PART 1

开源治理的背景主要分为三个方面：

第一，大多数开发者认为自己引用的开源组件是安全的，绝大部分的软件开发厂商都会去在软件开发过程中引用第三方组件，而负责开发的开发者并不关注所引入的组件是否存在安全风险问题。因此，开发者在完成功能开发的同时，可能也引入了安全隐患。

第二，不同开源软件的开源许可证可能存在合规性和兼容性风险问题。

第三，攻击者往往会利用第三方组件的安全风险进行攻击。

目前各大漏洞库中存储着庞大的漏洞数据，漏洞数据公示的初衷是为企业做好提醒，但在另一方面它也为攻击者提供了相应的漏洞信息，使攻击者可以利用这些信息发起攻击。因此以往在hw期间对组件的攻击也比较常见。

针对开源治理的痛点，我们总结为看不清、摸不透、拿不准、治不好四点。

第一，看不清，即企业在做项目开发时可能并不清楚在成百上千的项目中引用了哪些组件。

第二，摸不透，企业并不知道在引入的开源组件当中，有哪些存在安全风险。但此类信息一方面可以从CNVD这类数据库里查到，另一方面，各大厂商，像Apache等，会对其发布的软件做漏洞信息的推送，说明某个版本中存在哪些安全风险。这两种方式都可以作为漏洞信息来源。

第三，拿不准，企业对开源组件的引入分为直接引用和间接引用，而对于存在安全风险的组件影响范围有多大，其实企业并不清楚。

最后，治不好，当发现风险之后如何对其进行修复？因为这个过程中可能存在版本不兼容，或老版本已经不再维护的情况，导致不知道如何对组件的安全隐患进行修复。

针对以上痛点，企业可以通过下面四个步骤进行开源治理，逐步完善。

第一步，统一源头。在开发过程中对开源组件的引入需要有统一的源头，如果企业有上百个开发项目，而对组件引入的源头不统一，事后需要对其进行一对一的监控，这会造成非常高的监控成本。因此，第一步要先缩小入口。

第二步，通过依赖管理的工具去完成对dependent tree（依赖树）的分析。常见的构建工具包括适用于Java的Maven、Gradle，适用于Node的npm等。

基于前两步可以获取项目在开发过程中所有的组件依赖关系。

第三步，漏洞信息获取，通过将CNNVD、CNVD、NVD等漏洞库作为信息来源，匹配漏洞信息。

基于前三点的开源入口、组件信息和漏洞数据，即可完成初步的治理。

第四步，安全前置，或者称为全流程管理，将安全治理前置到开发阶段甚至更早期进行开源治理。

结合开源治理的四个痛点，我们对开源治理的路线和目标也总结出四点：看得清、摸得透、拿得准、治得好。治理目标就是了解开发项目里引入了哪些组件，存在哪些安全风险，安全风险的影响范围有多大，以及修复方案是怎样的。

结合明确的目标路线，我们梳理出四个治理要点。

第一，对整体的开源软件使用情况进行梳理，出具检测报告。

第二，建立监管机制，设立对开源软件的使用策略，明确哪些软件可以使用，哪些不能使用。

第三，依据监管策略进行差异化管理。不能将所有问题一刀切，需要根据不同项目场景，比如内网、外网、APP应用、优先级等，进行差异化管理。

第四，持续优化，企业制定好策略后，对开源软件进行分批管理，再通过持续优化来缩小白名单范围，使效果不断优化。

开源治理的实践探索

PART 2

开源治理实践分为三步，分别对应了治理之前的信息梳理，迭代时的交互和更新时的实时监控，以及对未来开源风险的持续预警。

对开源软件的信息梳理分为四个阶段。首先对企业的存量项目系统进行整体梳理，包括代码仓库、私服库，以及产品应用的各个分支，出具整体的安全报告。然后建立修复策略，明确哪些需要修复，哪些不需要修复，建立全局级、项目级的开源管控策略或开源软件基线。依托管控策略做分批整改，对各类项目进行等级划分或优先级排序，分期修复。最后进行修复验证。对开源漏洞进行闭环式管理。

对迭代中、更新中的项目整体进行实时监控，通过右侧流程图（上图右侧）可以看到，对软件开发的不同阶段进行实时的开源检测，包括从编码阶段到CI/CD阶段，整个流程都需要进行监控。

悬镜源鉴OSS产品，即可针对企业整体研发流程的不同阶段进行监控。从最初的编码阶段开始，提供编译插件，在IntelliJ IDEA、Eclipse等不同的编译环境中查看开发者在开发项目过程中是否引用了有开源风险的组件。在开发完成后代码被提交到代码仓库，还可以定期进行实时检测，来发现代码仓库里的项目是否存在风险。

通过源鉴OSS提供的探针技术，能实时获取运行中的应用是否存在安全风险。结合下一步的风险预警来讲，好处在于当漏洞库或者个人曝出一些开源风险漏洞时，通过探针技术可以在运行时发现不同企业的用户应用里是否已经加载了此类刚曝出来的风险，并进行实时反馈，对整体的CI/CD流程做实时监控。

关于未来对开源漏洞的风险预警，这里简单举例说明，但实际情况可能复杂得多。企业需要实时获取漏洞库、开源组件平台等发布的开源漏洞信息，然后与现有的依赖库和组件库做匹配，再把相应的信息反馈到产研团队进行修复，这就是整体的风险预警流程。

总结一下，开源治理整体包含四个要点：

第一，开源治理需要结合不同企业的研发流程，无论是技术还是工具，需要将治理嵌入到研发流程当中，进行实时监控。

第二，建立开源策略并不断优化，初期建立的开源策略可以根据不同的场景做划分，但在之后不断优化的过程中需要慢慢缩小开源软件使用策略范围。

第三，根据建立的策略做差异化开源治理，制定全局级或者更细颗粒度的项目级的开源治理管控。

最后，培养安全意识，赋能给产品研发团队，共同为安全负责。核心观点即事先的防护成本要远远低于事后补救的成本。

 X MIRROR 

关于悬镜安全

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