敏捷开发模式下金融机构开源软件引入风险及管控举措

*本文原创作者：haiczh，本文属于FreeBuf原创奖励计划，未经许可禁止转载

一、背景

随着电子商务在我国的蓬勃发展，互联网企业积累了海量的用户数据，逐渐掌握了用户金融服务的需求和偏好，并将其提供的金融服务由最初的简单支付渗透转账汇款，小额贷款，现金管理，资产管理、供应链金融、代销基金和保险等传统商业银行的业务领域 [1]。这就不可避免的与商业银行在市场占有，客户规模，利润空间等多领域构成竞争。

为了更好的提升客户服务质量，传统商业银行近年来在服务方式，支付方式，平台模式，服务渠道等积极拥抱互联网，加快加速转变，合理的把传统的金融构架与互联网的组织构架进行有机的融合，建立了一个互联网金融商业银行专属的战略系统，形了商业银行自己独特的互联网架构 [2]，并在大数据，云计算，人工智能领域大胆尝试和创新。而大多数现代智能技术多以开源架构为蓝本，在银行业金融机构这一重要而又相对封闭的行业中大量引入开源软件，使用开源技术，必然会引入新的风险点。对开源架构、技术及其工作特性的不了解，不正确使用而与银行传统网络或系统架构产生冲突造成的安全事件在过去的几年里时有发生。监管机构也多次发出风险预警，要求各银行机构排查开源技术使用情况。

为此，在敏捷开发模式下，如何在快速开发和开发风险控制二者间取得很好的平衡点是摆在商业银行开发者和安全管理部门面前的一道难题。

二、开源软件应用现状

据Gartner调查显示，99%的组织在其IT系统中使用了开源软件，同时开源软件在服务器操作系统、云计算领域、Web领域都有比较广泛的应用。

开源软件市场规模稳居服务器操作系统首位。根据《Linux 内核开发报告2017》显示，全球公有云上运行的负载有90% 是 Linux 操作系统，在嵌入式市场的占有率是62%，而在超算的市场占有率更是达到了99%。还有，它运行在世界上超过 82% 的智能手机中，也是所有公有云厂商的主要支撑服务器（90%）。

云计算领域开源目前主要以IaaS以及PaaS两个层面为主，IaaS有OpenStack、CloudStack、oVirt、ZStack等，PaaS层面有OpenShift、Rancher、Cloud Foundry以及调度平台Kubernetes、Mesos等。而对于OpenStack的应用，2017《OpenStack User Survey》显示： OpenStack行业应用前四名分别为电信、研究、金融和政府。

2013年 Docker 发布之后，技术日渐崛起。截至2014年底，容器镜像下载量高达1亿；到2017年初，这一数量超过80亿。

开源软件在Web领域占据主要市场份额。根据 Netcraft《Web Server Survey》调查发现，Nginx市场份额增加到21.4%，较上一年增长3.84%，成为了面向Web的计算机市场上第三大服务器厂商。Apache的市场份额下跌了0.35个百分点，它在面向 Web 的计算机市场的份额达到42.8%。目前，至少有7200万个网站宣称在他们的服务器头部正在使用 Apache 2.2。Apache 已经成为互联网站点最为流行的 Web 服务平台。

开源软件在人工智能领域的应用逐步推广起来。谷歌将TensorFlow 开源，机器人操作系统 ROS 也大多采用开源技术 [3]。

三、开源软件安全现状

整体来讲，开源软件安全现状不容乐观。根据安全公司Snyk发布的开源软件安全现状报告，2012年以来，每年公布的开源软件漏洞都在快速增长，2017年全年同比增幅创下历史新高。

Snyk 通过扫描了数以百万计的Github代码库和程序包，和对超过500个开源项目的维护者进行调查发现：

只有8%的开源项目维护者自认为有较高的信息安全技术和意识。

接近半数的开源项目维护者从来不审计代码，只有 11% 的维护者能做到每季度审核代码。

开源软件漏洞产生到发现公布的平均时间周期为89 年 75% 的漏洞都没有被项目维护者发现。

5% 的开源项目维护者都没有公开的漏洞公布策略（这直接导致了开源项目极低的漏洞上报率）。

漏洞采纳到公布的最长时间为9年，平均时间为2.5年（这意味着黑客手里拥有大量的0day漏洞）。

漏洞从公布到被修复最长时间为94天，平均时间为16天。[4]

四、开源软件采用风险

不管是直接使用开源技术，还是购买开源技术的商业软件都需要考虑开源技术带来的风险，只不过是规避开源技术风险的责任主体不同。 金融机构在使用或引入开源软件或代码时，除了需要考虑开源或许可证兼容风险、违约或其他法律风险、以及数据安全或隐私风险这些开源软件本身所带来的风险外，还要考虑监管合规风险等行业特定风险。

4.1 开源或许可证兼容风险

开源风险主要包括受开源协议与许可证的影响，有可能会使金融机构强制公开其私有代码或应用。在采用开源软件或代码时，未能充分理解和考查许可涵义，导致按照开源许可证所规范的义务或要求，金融机构将自己的私有软件必须对外公开源代码。

下图为几种开源许可证之间的关系 [5]：

4.2 违约或其他法律风险

目前各国法律或法院，对于开源软件使用者，在违反开源许可证的义务或要求的情况下，是否构成合同违约，仍未有一致规定或见解。这一风险多半与开源风险同时发生，当金融使用开源软件后，违背许可证规定，不开放其私有软件或代码时，也会构成违约风险，由此也可能会导致知识产权风险，著作权风险等一系列法律风险。

4.3 数据安全或隐私风险

由于开源软件的透明，开放机制，给了黑客或攻击者更多的研究代码漏洞的机会。而开源社区维护者在代码开发过程中，并没有给予安全足够多的重视，导致数据或隐私成为开源软件最大的一块短板，也是金融机构引用开源软件需要重点考虑的安全风险。

开源代码在安全设计上的存在缺陷的重要一个原因是每一个开源使用者都很自然的认为其经过了大多数的测试和审查，而实际上，并没有多少人在使用时测试系统的安全性。心脏出血漏洞、GNTTLS里的“Ghost”漏洞和破壳漏洞都是很好的例证：开源将源代码公布，许多双眼睛宣称将检查它，因而任何可能的不良代码都逃不脱众人之眼。

然而自2012年2月发布之日起，这段有问题的代码就一直暴露在‘众人之眼’前，但没有任何一个人发现它，直到两年之后，漏洞都被利用滥了才忽然醒悟。

4.4 监管合规风险

监管合规风险是金融行业比较特殊的一类风险，如果监管合规风险关把控不严格，出现监管违规，有可能不只是之前的努力付之一炬，可能还会给企业带来更严重的后果，如评分降级，经营受限等等。

例如人民银行明确规定，对于创新技术在支付领域的首次应用，跨境合作，社会关注度较高等重要支付创新项目，必须在系统或项目上线前30日内向人民银行备案。

五、开源软件采用风险控制措施

5.1 建立开源软件采用管理机制

商业银行应建立属于自己的开源软件管理机制，无论是与更新现有的软件管理机制，还是单独建立开源软件管理机制，都需要对现有的ISMS管理进行丰富和修正，实现开源软件引入和使用的标准化、规范化和合规化。可参考以下框架设计：

开源软件管理规定中明显商业银行哪一类系统可以使用开源软件，并明确采用开源软件后，应按照软件全生命周期进行跟踪和管理。

在三级文档中明确开源软件管理规定中具体的每一个阶段应该做什么的问题。以开源软件引入为例，在引入管理办法中应明确开源软件引入时要进行开源项目评价，并明确可以引入的标准，对于达不到标准的开源项目拒绝引入。从而在引入阶段把控风险。同时还需要指出在技术层面要进行代码的安全性和可靠性测试等内容。

在四级文档中规定具体的做和操作手册，保证管理办法中的要求可以得到正确的执行。如开源项目评估，操作手册中应明确规定评估的内容和方法，包括但不限于开源协议理解，版权及法律风险评估，开源项目活跃度评价[1]，开源项目成熟度评估[2]等内容。

5.2 建立商业银行代码安全需求库

开源软件经过严格的审核和评价机制被引入后，开发团队一般需要对进行基于业务需求的开发和测试。这一过程，是系统安全性弹性变化最大的阶段，建立商业银行代码安全需求库，可以很好的保证开发的软件在安全需求上的满足。商业银行可以根据自己的业务场景来制定自己的安全需求库，例如系统登录中的身份认证，安全需求可设计如下：

5.3 引入第三方机构进行安全评估

任何系统的上线前评估是金融行业信息系统监管评估的红线，不容侵犯。而对于基于开源软件开发的系统进行安全评估时，商业银行的技术能力很难达到，建议与第三方安全公司合作，来进行评估，必要时，可以进行软件代码成分分析 [3] 和代码审计这样更细粒度的评估。甚至可以对软件的网络报文，流量组成等进行跟踪与测试，以评估与现有网络设备、系统架构的兼容性。

参考文献

[1]降磊，“互联网金融时代的商业银行发展模式研究”，《西南交通大学》, 2013。

[2]张庆，“互联网金融时代的商业银行发展模式研究”，《现代经济信息》, pp. 55-55，2015。

[3]中国信息通信研究院，“开源治理白皮书” ，2018-04。

[4]snyk, “The State of Open Source Security,” 2017. https://snyk.io/stateofossecurity/#the-open-source-landscape.

[5]2 5 2011. http://www.ruanyifeng.com/blog/Cc-By-3.0/.

[6] http://www.qsos.org/ .

[7] http://www.openbrr.org/ .

（1） 开源项目活跃度评价可以从开源社区数目，社区活跃程度，如贡献者数量，提交的问题数，外部采用者数量，流行程度，下载量等进行进行评估。

（2） 开源项目成熟度评估可以参考国际上比较流行的开源项目评估模型OSMM Capgemini，OSMM Navica，QSOS [5]，OpenBRR [6]，QualiPso Opensrouce Maturity Mode等，具体内容在此不再展开，感兴趣的读者可以自行查阅。

（3） 软件代码成分分析（SCA）技术是指通过对软件的组成进行分析，识别出软件中使用的开源和第三方组件（如底层库、框架等等），从而进一步发现开源安全风险和第三方组件的漏洞。通常，SCA的检测目标可以是源代码、字节码、二进制文件、可执行文件等的一种或几种。

*本文原创作者：haiczh，本文属于FreeBuf原创奖励计划，未经许可禁止转载