金融行业开源技术应用社区（FINOC）研讨实录：开源组件安全问题与升级方式

在开源成为全球趋势的今天，抢跑科技创新的金融机构成为开源技术的重度用户。然而，由于我国金融机构对开源软件的管理尚不完善，不具备较成熟的开源治理体系，金融机构在引入和管理开源软件时总会遇到种种困难，这也带来了一定程度的开源风险。

对于紧跟开源技术趋势的金融机构而言，哪些开源软件适合自身业务已经不再是问题，他们更加关心的是如何解决业务中的实际问题，例如：

• 银行应如何构建开源软件管理体系？

• 开源软件安全治理的最佳实践是什么？

• 如何实现开源商业化？开源项目的评价标准是什么？

• 金融行业开源技术框架的管理方法和案例实践有哪些？

• 金融机构如何使用MySQL？

• 金融机构如何参与和贡献开源？

• 构建金融开源生态圈的可行性有多大？

为了解决这些普遍性的行业痛点，一群来自金融行业的技术专家提出了一个大胆的想法：如果没有答案，那我们就自己去寻找合适的行业方案。

2018年，一个略显神秘和低调的金融行业组织形成了。这个最初由中国信通院联合浦发银行发起，由农业银行、兴业银行、中信银行、人寿保险、太平洋保险等10余家金融机构作为首批成员成立的“金融行业开源技术应用社区”（FINOC）。首次开启了国内金融行业对开源技术应用的自我探索之路。

有趣的是，不同于人们所熟知的金融科技类联盟，这个“金融开源社区”有三大特点：一是不收会费；二是每隔1-2个月社区就会发起研讨会，而且每次研讨必会输出干货。更为社区成员们津津乐道的是，研讨会有一个必不可少的环节——“吐槽大会”，这也成为金融机构与同行们探讨困扰已久的难题、吸取同业机构实践经验的一次绝佳机会。

成立两年以来，“金融开源社区”在毫无推广、只凭口口相传的自然发酵下，如今已经吸引了35家头部金融机构、8家知名科技公司、多位独立技术专家的共同加入。这种对金融机构实际痛点的精准覆盖、高频次的行业干货输出，让“金融开源社区”在行业内名声大振。

2020年12月中旬，“金融开源社区”在中国信通院的牵头下举办了第15次线上研讨会活动，这一次的研讨主题是“开源组件安全问题与升级方式”。

在长达2.5小时的激烈讨论中，来自浦发银行、平安银行、广发银行、光大银行、中信银行、交行卡中心、上海农商行、中国银行、上海银行、工行软件开发中心、微众银行、太平人寿、宁波银行、海通证券、农业银行、中原银行、华泰证券等金融机构的技术负责人，以及奇安信、棱镜七彩、新思科技、默安科技等多家技术厂商的专家们，又一次在“吐槽大会”中碰撞出精彩纷呈的观点。

这一次关于“开源组件安全问题与升级方式”的话题，反映了金融机构哪些普遍性的痛点？不同规模和性质的金融机构，又是如何在自己的实际业务中去解决开源升级和安全的问题？

为了让更多金融机构和科技厂商能够深入了解这一问题，本文整理了此次研讨会的干货内容。以下为“金融行业开源技术应用社区研讨会：开源组件安全问题与升级方式”实录精编。

01

问题一

开源组件存在升级后由于再次披露漏洞需要频繁升级，影响业务运转，有没有解决方案？

开源组件升级是一个不可避免的事实，由于升级框架或组件，往往会导致兼容性或安全问题。由于各个金融机构的应用与漏洞情况不同，行业内并没有通用的解决方案。对于这一问题，多位技术专家给出了自己的看法，我们将其总结为六个方向的解决方案：

一、安全检测“左移”

微众银行开源管理办公室  钟燕清：这个问题没有一步到位的快捷方法，尽量在开发早期就执行安全检测，形成“黑白名单”。在开发过程中，对开源引用情况、漏洞解决方案、安全评估、组件版本等都要有详细的记录，在整个DevOps过程中形成严格的漏洞控制追踪流程，并给予强制+建议性的安全措施。

此外，要培养开发人员的安全意识，让所有开发人员都既有意识，也有可用的工具，具备专业的能力来做这件事。

中国信通院开源专家 俊哲：安全检测“左移”，就是要在开发早期就执行安全检测；如果发现了安全问题，那么选择安全版本时，可选取最新的稳定版，并建立开源资产清单，以便持续跟踪。

二、先评估后整改

中国银行信息科技运营中心 李维银：“先评估后整改”，即对漏洞的危害程度进行评估，再根据漏洞等级采取相应的修复措施。目前，我行采用了很多自动化工具，如果修复漏洞要改动配置，也会同步修改自动化脚本，以解决隐患。

农业银行研发中心信息安全与风险管理部  姜晓璇：最终目标如果是“消灭漏洞“会比较困难，最好还是采取降低漏洞数据的策略，按比例修复漏洞，这样可操作性比较大，开发人员也有选择余地。

如果兼容性允许，就升级到安全的版本；如果兼容性不允许，那就升级到漏洞数量比较少的版本，先解决存量开源组件的问题。对于增量开源组件，则直接使用安全策略，嵌入Devops流程。

随着时间的增长，这种循环上升的态势，应该能达到更好的效果。

中国信通院开源专家 俊哲：若评估漏洞风险对系统的影响情况较小，可以考虑不采取措施，但要记录在案。

若评估漏洞风险对系统安全性影响较大，但因为业务连续性要求，导致难以承受升级带来的系统兼容性风险，则可以考虑是否有漏洞风险的缓解措施可以使用，如：增加或修改安全配置、临时禁用受影响的功能等。但缓解措施宜作为临时处置方案，最终还是要升级到安全版本，从而从根本上修复漏洞。

有些情况下可能没有适用的缓解措施，需要通过升级才修复高风险漏洞。在选择升级版本时不宜简单的选择最新的版本，最好是选择与当前所使用版本兼容的补丁版本或者版本号接近的安全版本。

有可能存在升级版本就会有兼容性问题的情况，由于开源软件源代码可公开获得，可以考虑自己在使用的版本上，通过修改源代码来修复漏洞，从而自己来保证兼容性。

三、先可知再可控

新思软件质量与安全部门 王永雷：提高项目的透明度，不管在开发还是测试环节，版本漏洞、漏洞严重情况等，都要能清楚的看见和管理。例如，漏洞有没有影响到代码，要进行快速判断。即使是中高危漏洞，也不一定都会影响代码。因此，除了透明度，还要提高评估的效率。

目前，我们会在产品中提供实时通知，对漏洞影响到现有版本提供动态监控，以工程化的手段，将开源组件版本的安全从前到后管理起来。

苏州棱镜七彩信息科技有限公司 但吉兵：由于企业应用程序、运行环境的不同，在漏洞修复时的策略也不一样。例如：针对存量系统，应用程序的组件有安全问题，就需要跨部门协作。而增量系统，遇到大的开源组件有补丁，则通过治理工具或者外部安全服务进行管控和运维。

先可知再可控，就是要根据不同的环境、场景，详细了解每个版本的情况，再提供更全面的治理工具。

四、管理规范性和机制常态化

技术专家项曙明：开源管得不好，企业会增加管理成本，风险更大。因此，企业应构建快速发现和治理开源风险的能力，从管理机制、工具和培训三个方面共同构建常态化的机制。

首先，从管理的规范性看，如何引入开源代码、如何管理代码，都应该从企业层面制定符合企业本身的开源漏洞治理方案，不要把修复漏洞的责任与义务全部附加给程序员。

其次，要约束项目组的用法，如：代码治理、许可证治理等。尽量不要源码引用，如果源码引用，那就尽量对代码进行解耦，以降低风险。

第三，除了日常使用漏洞扫描工具、治理工具进行管理，出了问题有没有能力快速应对？企业需要构建和检验自己快速应对风险的能力。

五、与社区联动

微众银行开源管理办公室钟燕清：目前，我们在内部形成了小的组件社区，专门跟踪开源社区、关注开源漏洞问题，并由内部专家进行维护，以保证系统的高可用性、低成本、快速升级；同时，我们也会对重要的组件做封装，以达到升级时应用无感。

技术委员会成员专家  项曙明：企业应积极将发现的漏洞和代码贡献到开源社区，及时跟进社区的进度，并从社区得到反馈，这样对企业了解自身开源风险其实是非常有益的。

新思软件质量与安全部门 王永雷：企业需要和社区形成紧密关联，并指派专家参与到开源社区的活动中，和社区形成良性的互动，更好的应对开源组件的的风险。

六、自动化工具

技术委员会成员专家  史少锋：大型企业一定要成立专门的安全小组，采用自动化工具来扫描和管理各类开源组件，一方面减少人力投入提高效率，另一方面及时告知，以降低安全风险。例如OWASP的 Dependency Track 项目就可以帮助自动化监测统计依赖变化以及各种安全漏洞。

02

问题二

除了升级，开源漏洞还有什么解决办法？

一、专业化漏洞研究团队

中国信通院开源专家 俊哲：开源组件漏洞修复，绝大部分是通过升级解决的，建议升级到距离当前版本没有漏洞的最接近的版本进行升级，这样兼容性较好。

如果有特殊组件无法通过升级解决，需要专业化漏洞研究团队，针对特定组件漏洞进行特定修复，这样成本比较大。

奇安信代码安全事业部 韩建：企业内部漏洞数量特别大的情况下，需要识别是否是企业内最应该修复的漏洞，需要收集已经POC的漏洞。此外，奇安信有专门的漏洞防护小组和分析报告，可以提供大型的漏洞分析和建议。

如果是社区已经不维护的组件出现漏洞，那就需要找专业漏洞挖掘团队，专门去打补丁。

二、查看不同的漏洞库

新思软件质量与安全部门 王永雷：不同的角色针对同一个安全漏洞可以通过不同的视角去查看漏洞的信息（CVE、CWE、CAPEC等）来协助判断和评估漏洞的风险等级。

三、修改源代码工具

农业银行研发中心信息安全与风险管理部  姜晓璇：除了升级，还可以通过修改源代码修复漏洞，但是需要注意代码的改动量，修改量大的话容易无法持续监控。

03

问题三

一个组件的处置会涉及到依赖组件的同步升级， 如何处理？

新思软件质量与安全部门 王永雷：组件的直接与间接依赖，与漏洞是否需要修复没有直接关系，需要考虑整个函数调用链路是否被触发，如果被触发需要有限考虑修复。当然，这需要整个项目部门合作、组件开发过程透明，理清组件之间的关系。

农业银行研发中心信息安全与风险管理部  姜晓璇：攻击链路很可能是通过间接组件发生的，这个常常会被大家忽略。希望能有安全工具，可以提供间接依赖组件的漏洞修复措施。

04

问题四

系统因漏洞升级主框架要重新做测试，导致运维工作量巨大涉及系统广，配合度跟不上，这种情况如何解决？

中国信通院开源专家 俊哲：先评估该漏洞是否有缓解措施可以使用，若有缓解措施使用，可以在保持业务连续性的基础上，为升级测试争取更多的时间。若没有缓解措施，也可考虑自己修改源码进行漏洞修复。

如果经过评估该框架已经产生副作用，在系统依赖关系不紧密的情况下可以直接弃用。

05

问题五

有些高版本的组件，依赖高版本的JDK环境，一旦升级JDK，很可能整个项目代码都得重构，修复代价非常大，这种情况是否有修复办法？

科技安全研究院 韩宏舟：高版本的组件相较于当前正在使用的组件，除了漏洞修复部分以外，可能大部分更新是我们不需要的。依赖高版本JDK特性可能正是这些不需要的更新，所以可以通过修改当前使用组件版本的源码，修复漏洞后重新打包。但是这相当于一个自定义的版本，可能会对后续版本跟踪造成干扰。

06

问题六

在开源产业链条中，是否有专门针对热门组件的商业化安全服务？

中国信通院开源专家 俊哲：目前有商业化公司针对热门开源软件的一些商业化服务，包括部署、安装、运维等，针对开源组件，也可以向开源治理厂商订阅商业化服务，如威胁情报、安全版本推荐、修复建议等。

上海银行信息技术部 郑位威：安全厂商的确会提供漏洞扫描报告PDF，内容包括威胁情报、安全版本推荐、修复建议等，但这都是一些通过做法，并没有针对企业的实际情况，给出实际的落地方案。业内缺乏既懂安全，又懂技术的复合型人才，解决实际问题的商业方案也很少。

海通证券开发中心平台部 周靖：建议厂商针对主流开发框架（例如Springboot2.x系列，热门组件）定制安全版本，基本上能覆盖日常 70%以上的常规安全漏洞和功能设计漏洞，剩下不多的漏洞则由企业根据自身特点进行定制化积累，将安全融合在框架、组件中。

除了针对以上话题展开了激烈讨论，此次研讨会还根据之前在金融开源社区内的调研，将大家反馈问题最多、升级代价比较大的组件版本，进行了展示和讨论。

由于时间的限制，还有多个金融CTO们关注的议题尚未得到充分讨论，例如：什么样的流程与制度，可以让安全部门与开发部门之间良好协作？如何衡量开源安全治理的好不好，工具与度量指标是什么？

相信在这场意犹未尽的金融行业“吐槽大会”之后，技术专家们还将继续各自的思考与实践，并满心期待下一次的江湖再见。

精彩内容推荐