随着移動應用、網際網路+時代的到來，幾乎每個銀行的都已經把主要的業務搬到網際網路和移動網際網路上來。随之而給帶來了兩個重大的趨勢：
一方面，軟體外包開發空前的繁榮起來，銀行除了要提供網上銀行，電話銀行的業務，還要提供手機銀行，銀行APP,
網絡支付、各類投資和理财業務APP等等。越來越多的銀行業務需要更全面、功能更多、更強大的軟體應用系統來支撐，這着實給本來就“壓力山大”商業銀行科技部(軟體開發處)帶來了不小的挑戰。
另一個方面，資訊安全、個人隐私受到了越來越大的威脅。網絡安全事件，個人隐私洩露，網絡站點被黑等等事件幾乎天天可以看到。是以國家在今年6月1日及時地頒布了《網絡安全法》，希望從法律層面，給社會各界提供有力的依據，公同保護網際網路安全環境。
其中，現在網絡安全攻擊事件不斷頻發的一個主要原因，就是大量定制化外包開發出來的軟體應用系統的源代碼中都存在着各種各樣的安全漏洞，極易受到黑客攻擊。這一點，我們可以從國内多家安全漏洞曝光平台上可以看出(國内主要的曝光平台有，360公司補天、漏洞盒子等)，幾乎各行各業的網站系統都會存在安全漏洞。其中不乏大型國企、央企、大中型商業銀行、高校和科研機關等等。
2016年網絡安全事件與源代碼安全漏洞
面對上述嚴峻的網絡安全形勢，作為關系到國計民生、和老百姓的“錢”息息相關的商業銀行，絕對不能再僅靠傳統的幾大件網絡安全防護裝置來解決問題。
正如上文所說，目前所面臨的安全問題都是我們自主研發或者外包開發出來的定制化軟體系統存在安全漏洞而導緻的。而目前我國的絕大多數商業銀行的軟體系統開發是外包開發為主，由銀行内所設定的科技部和資訊系統部來管理。行方人員為數較少，常常都是一人身兼數職，同時也沒有相對專業的軟體安全管理人員。
針對中小型商業銀行的軟體開發特色，我們如果還是大談如何在商業銀行内部建立完整的SDLC安全開發生命周期來保證軟體的安全性就顯得非常的不且實際。今天，我們就來聊一聊大部分為外包開發模式的商業銀行，用什麼方法來保障自己所定制開發的軟體系統、WEB站點以及移動APP等應用系統的源代碼的安全性。
對于商業銀行而言，自身不具備(也不必要具備)軟體安全開發能力，不需要擁有很高的源代碼安全開發水準。但對于自己的業務系統的安全性，商業銀行是第一負責人，必須具備軟體系統安全的檢測和保障能力，否則一旦應用系統被攻擊，觸犯《網絡安全法》的可是銀行自己，要第一個被追責。是以，各個商業銀行都應該在如何保證軟體的源代碼安全漏洞問題上下一番功夫，確定自身業務系統上線後的安全性、穩定性。
那麼如何在外包開發模式下有效地對軟體應用系統進行安全保障呢?換句話說，如何在“隻有一個行方的開發項目經理，且方經理身兼多個項目”的情況下，又確定源代碼是安全的?
根據我個人多年經驗的總結，并結合外包管理的一些方法，我認為，在軟體外包管理中引入軟體源代碼安全測試體系，建立強制性的源代碼“安全驗收”機制是最有效、最友善的手段。它可以從源代碼層面上保證軟體系統的安全性。這個“安全驗收”機制如何建立才能即滿足甲方安全保障的需要，又能讓外包開發服務商積極地配合安全漏洞的檢測和修複工作呢?
我們将其總結為一個“GATE+” 源代碼安全測試管理模式，具體說明如下圖所示：
“GATE+”安全測試管理模式
如上圖所示，“GATE+”模式的主要思想就是，在外包開發管理中引入軟體源代碼的安全測試體系，對外包服務商所傳遞的軟體系統的源代碼進行安全性驗收測試。如果傳遞的源代碼存在易被攻擊的安全漏洞，需要外包商進行安全修複，直至這些漏洞全部被消除，這個系統才能夠驗收，進行上線部署。該模式的幾個關鍵點說明如下：
1. 行方制定并釋出明确的《軟體源代碼安全測試驗收标準》
由行方安全部門和開發項目經理聯合專業的軟體安全咨詢顧問共同制定出明确的，符合甲方安全要求的《軟體源代碼安全測試驗收标準》，并由行方權威部門正式釋出，即上圖中的“紅線”。這是源代碼安全驗收時必須遵守的，也是最後的一道防線，由“行方開發項目經理”對标紅線的進行各個項目的安全檢查和驗收。
與之相對應的是外包開發過程中的一個“虛黃線”。該虛黃線的意思是開發商可以在項目開發初期就明确地讓開發人員知道将來的源代碼驗收标準，開發人員就可以提前預防，提前做好技術上的規避方案。這樣一來，外包商和開發人員就會更加積極主動的配合安全漏洞的檢查和修複工作。
2. 建立一個友善、高效的軟體源代碼安全測試管理平台
可能有安全管理人員會覺得源代碼安全測試，直接找專業的第三方安全測試機構或者安全公司進行測試服務就可以了，不必要由行方自建源代碼安全管理平台。
但根據經驗，由甲方自建安全測試管理平台是非常有必要的。這是因為，如果把驗收測試交由第三方來測試時，那勢必安全測試隻能在項目驗收時進行一次到兩次的測試。測試頻度太低，時間後置，這樣隻能會造成“倉促地”測試和驗收，外包人員“極不情願地”配合和“應付式”修複漏洞的局面。一旦形成這樣的情況，那上面行方項目經理的“安全驗收”工作就會越來越難開展，也無法保證品質，慢慢地就隻是留于“形勢”了。
這一點，我們已經看到很多的商業銀行就是這樣的情況。是以，由甲方自建一個軟體源代碼安全測試管理平台，提供兩種測試并行的方法才能把“安全測試标準”有效地執行下去。目前國内自主可控的源代碼安全測試管理平台并不多，思客雲公司找八哥雲管理系統是個不錯的選擇。
3. “強制式”測試與“自助式”測試并行
為了避免上述的問題，在自建安全測試管理平台的基礎上，我們提出了一個“強制式”測試與“自助式”測試并行的方案。
如上圖中所示，驗收式測試 +“藍虛框”的外包自助式測試。其中驗收式測試由甲方的項目管理人員完成。這是強制式的，每一個項目在傳遞前都要進行一次強制式驗收測試。
同時，在開發過程中，允許外包商開發人員可以在開發過程中不定期的對源代碼進行自助式的安全測試，這樣可以讓外包人員及時地檢測出安全問題及時地修複漏洞。外包商就可以對強制驗收式測試沒有那麼抵觸，更加積極配合，安全測試工作就會更加的順暢。同時也不會因為安全測試影響項目驗收進度，影響傳遞和釋出了。
軟體源代碼安全驗收測試，一個簡單又高效的軟體安全保障手段，雖然已經提出多年，但是如果沒有一個有效的模式為基礎，則隻會讓商業銀行，外包商，開發人員，安全人員和項目管理人員徒增煩惱。思客雲找八哥系統以提供最佳“源代碼安全測試”整體解決方案為己任，希望能夠給您提供必要的幫助!
本文作者：王宏
來源：51CTO