随着移动应用、互联网+时代的到来，几乎每个银行的都已经把主要的业务搬到互联网和移动互联网上来。随之而给带来了两个重大的趋势：

• 一方面，软件外包开发空前的繁荣起来，银行除了要提供网上银行，电话银行的业务，还要提供手机银行，银行APP, 网络支付、各类投资和理财业务APP等等。越来越多的银行业务需要更全面、功能更多、更强大的软件应用系统来支撑，这着实给本来就“压力山大”商业银行科技部(软件开发处)带来了不小的挑战。
• 另一个方面，信息安全、个人隐私受到了越来越大的威胁。网络安全事件，个人隐私泄露，网络站点被黑等等事件几乎天天可以看到。所以国家在今年6月1日及时地颁布了《网络安全法》，希望从法律层面，给社会各界提供有力的依据，公同保护互联网安全环境。

其中，现在网络安全攻击事件不断频发的一个主要原因，就是大量定制化外包开发出来的软件应用系统的源代码中都存在着各种各样的安全漏洞，极易受到黑客攻击。这一点，我们可以从国内多家安全漏洞曝光平台上可以看出(国内主要的曝光平台有，360公司补天、漏洞盒子等)，几乎各行各业的网站系统都会存在安全漏洞。其中不乏大型国企、央企、大中型商业银行、高校和科研单位等等。

2016年网络安全事件与源代码安全漏洞

面对上述严峻的网络安全形势，作为关系到国计民生、和老百姓的“钱”息息相关的商业银行，绝对不能再仅靠传统的几大件网络安全防护设备来解决问题。

正如上文所说，目前所面临的安全问题都是我们自主研发或者外包开发出来的定制化软件系统存在安全漏洞而导致的。而目前我国的绝大多数商业银行的软件系统开发是外包开发为主，由银行内所设置的科技部和信息系统部来管理。行方人员为数较少，常常都是一人身兼数职，同时也没有相对专业的软件安全管理人员。

针对中小型商业银行的软件开发特色，我们如果还是大谈如何在商业银行内部建立完整的SDLC安全开发生命周期来保证软件的安全性就显得非常的不且实际。今天，我们就来聊一聊大部分为外包开发模式的商业银行，用什么方法来保障自己所定制开发的软件系统、WEB站点以及移动APP等应用系统的源代码的安全性。

对于商业银行而言，自身不具备(也不必要具备)软件安全开发能力，不需要拥有很高的源代码安全开发水平。但对于自己的业务系统的安全性，商业银行是第一负责人，必须具备软件系统安全的检测和保障能力，否则一旦应用系统被攻击，触犯《网络安全法》的可是银行自己，要第一个被追责。所以，各个商业银行都应该在如何保证软件的源代码安全漏洞问题上下一番功夫，确保自身业务系统上线后的安全性、稳定性。

那么如何在外包开发模式下有效地对软件应用系统进行安全保障呢?换句话说，如何在“只有一个行方的开发项目经理，且方经理身兼多个项目”的情况下，又确保源代码是安全的?

根据我个人多年经验的总结，并结合外包管理的一些方法，我认为，在软件外包管理中引入软件源代码安全测试体系，建立强制性的源代码“安全验收”机制是最有效、最方便的手段。它可以从源代码层面上保证软件系统的安全性。这个“安全验收”机制如何建立才能即满足甲方安全保障的需要，又能让外包开发服务商积极地配合安全漏洞的检测和修复工作呢? 我们将其总结为一个“GATE+” 源代码安全测试管理模式，具体说明如下图所示：

“GATE+”安全测试管理模式

如上图所示，“GATE+”模式的主要思想就是，在外包开发管理中引入软件源代码的安全测试体系，对外包服务商所交付的软件系统的源代码进行安全性验收测试。如果交付的源代码存在易被攻击的安全漏洞，需要外包商进行安全修复，直至这些漏洞全部被消除，这个系统才能够验收，进行上线部署。该模式的几个关键点说明如下：

1. 行方制定并发布明确的《软件源代码安全测试验收标准》

由行方安全部门和开发项目经理联合专业的软件安全咨询顾问共同制定出明确的，符合甲方安全要求的《软件源代码安全测试验收标准》，并由行方权威部门正式发布，即上图中的“红线”。这是源代码安全验收时必须遵守的，也是最后的一道防线，由“行方开发项目经理”对标红线的进行各个项目的安全检查和验收。

与之相对应的是外包开发过程中的一个“虚黄线”。该虚黄线的意思是开发商可以在项目开发初期就明确地让开发人员知道将来的源代码验收标准，开发人员就可以提前预防，提前做好技术上的规避方案。这样一来，外包商和开发人员就会更加积极主动的配合安全漏洞的检查和修复工作。

2. 建立一个方便、高效的软件源代码安全测试管理平台

可能有安全管理人员会觉得源代码安全测试，直接找专业的第三方安全测试机构或者安全公司进行测试服务就可以了，不必要由行方自建源代码安全管理平台。

但根据经验，由甲方自建安全测试管理平台是非常有必要的。这是因为，如果把验收测试交由第三方来测试时，那势必安全测试只能在项目验收时进行一次到两次的测试。测试频度太低，时间后置，这样只能会造成“仓促地”测试和验收，外包人员“极不情愿地”配合和“应付式”修复漏洞的局面。一旦形成这样的情况，那上面行方项目经理的“安全验收”工作就会越来越难开展，也无法保证质量，慢慢地就只是留于“形势”了。

这一点，我们已经看到很多的商业银行就是这样的情况。所以，由甲方自建一个软件源代码安全测试管理平台，提供两种测试并行的方法才能把“安全测试标准”有效地执行下去。目前国内自主可控的源代码安全测试管理平台并不多，思客云公司找八哥云管理系统是个不错的选择。

3. “强制式”测试与“自助式”测试并行

为了避免上述的问题，在自建安全测试管理平台的基础上，我们提出了一个“强制式”测试与“自助式”测试并行的方案。

如上图中所示，验收式测试 +“蓝虚框”的外包自助式测试。其中验收式测试由甲方的项目管理人员完成。这是强制式的，每一个项目在交付前都要进行一次强制式验收测试。

同时，在开发过程中，允许外包商开发人员可以在开发过程中不定期的对源代码进行自助式的安全测试，这样可以让外包人员及时地检测出安全问题及时地修复漏洞。外包商就可以对强制验收式测试没有那么抵触，更加积极配合，安全测试工作就会更加的顺畅。同时也不会因为安全测试影响项目验收进度，影响交付和发布了。

软件源代码安全验收测试，一个简单又高效的软件安全保障手段，虽然已经提出多年，但是如果没有一个有效的模式为基础，则只会让商业银行，外包商，开发人员，安全人员和项目管理人员徒增烦恼。思客云找八哥系统以提供最佳“源代码安全测试”整体解决方案为己任，希望能够给您提供必要的帮助!

原文发布时间为：2017-10-18

本文作者：王宏

本文来自云栖社区合作伙伴51CTO，了解相关信息可以关注51CTO。