隨著移動應用、互聯網+時代的到來，幾乎每個銀行的都已經把主要的業務搬到互聯網和移動互聯網上來。隨之而給帶來了兩個重大的趨勢：

• 一方面，軟件外包開發空前的繁榮起來，銀行除了要提供網上銀行，電話銀行的業務，還要提供手機銀行，銀行APP, 網絡支付、各類投資和理財業務APP等等。越來越多的銀行業務需要更全面、功能更多、更強大的軟件應用系統來支撐，這著實給本來就“壓力山大”商業銀行科技部(軟件開發處)帶來了不小的挑戰。
• 另一個方面，信息安全、個人隱私受到了越來越大的威脅。網絡安全事件，個人隱私泄露，網絡站點被黑等等事件幾乎天天可以看到。所以國家在今年6月1日及時地頒布了《網絡安全法》，希望從法律層面，給社會各界提供有力的依據，公同保護互聯網安全環境。

其中，現在網絡安全攻擊事件不斷頻發的一個主要原因，就是大量定制化外包開發出來的軟件應用系統的源代碼中都存在著各種各樣的安全漏洞，極易受到黑客攻擊。這一點，我們可以從國內多家安全漏洞曝光平臺上可以看出(國內主要的曝光平臺有，360公司補天、漏洞盒子等)，幾乎各行各業的網站系統都會存在安全漏洞。其中不乏大型國企、央企、大中型商業銀行、高校和科研單位等等。

2016年網絡安全事件與源代碼安全漏洞

面對上述嚴峻的網絡安全形勢，作為關系到國計民生、和老百姓的“錢”息息相關的商業銀行，絕對不能再僅靠傳統的幾大件網絡安全防護設備來解決問題。

正如上文所說，目前所面臨的安全問題都是我們自主研發或者外包開發出來的定制化軟件系統存在安全漏洞而導致的。而目前我國的絕大多數商業銀行的軟件系統開發是外包開發為主，由銀行內所設置的科技部和信息系統部來管理。行方人員為數較少，常常都是一人身兼數職，同時也沒有相對專業的軟件安全管理人員。

針對中小型商業銀行的軟件開發特色，我們如果還是大談如何在商業銀行內部建立完整的SDLC安全開發生命周期來保證軟件的安全性就顯得非常的不且實際。今天，我們就來聊一聊大部分為外包開發模式的商業銀行，用什么方法來保障自己所定制開發的軟件系統、WEB站點以及移動APP等應用系統的源代碼的安全性。

對于商業銀行而言，自身不具備(也不必要具備)軟件安全開發能力，不需要擁有很高的源代碼安全開發水平。但對于自己的業務系統的安全性，商業銀行是第一負責人，必須具備軟件系統安全的檢測和保障能力，否則一旦應用系統被攻擊，觸犯《網絡安全法》的可是銀行自己，要第一個被追責。所以，各個商業銀行都應該在如何保證軟件的源代碼安全漏洞問題上下一番功夫，確保自身業務系統上線后的安全性、穩定性。

那么如何在外包開發模式下有效地對軟件應用系統進行安全保障呢?換句話說，如何在“只有一個行方的開發項目經理，且方經理身兼多個項目”的情況下，又確保源代碼是安全的?

根據我個人多年經驗的總結，并結合外包管理的一些方法，我認為，在軟件外包管理中引入軟件源代碼安全測試體系，建立強制性的源代碼“安全驗收”機制是最有效、最方便的手段。它可以從源代碼層面上保證軟件系統的安全性。這個“安全驗收”機制如何建立才能即滿足甲方安全保障的需要，又能讓外包開發服務商積極地配合安全漏洞的檢測和修復工作呢? 我們將其總結為一個“GATE+” 源代碼安全測試管理模式，具體說明如下圖所示：

“GATE+”安全測試管理模式

如上圖所示，“GATE+”模式的主要思想就是，在外包開發管理中引入軟件源代碼的安全測試體系，對外包服務商所交付的軟件系統的源代碼進行安全性驗收測試。如果交付的源代碼存在易被攻擊的安全漏洞，需要外包商進行安全修復，直至這些漏洞全部被消除，這個系統才能夠驗收，進行上線部署。該模式的幾個關鍵點說明如下：

1. 行方制定并發布明確的《軟件源代碼安全測試驗收標準》

由行方安全部門和開發項目經理聯合專業的軟件安全咨詢顧問共同制定出明確的，符合甲方安全要求的《軟件源代碼安全測試驗收標準》，并由行方權威部門正式發布，即上圖中的“紅線”。這是源代碼安全驗收時必須遵守的，也是最后的一道防線，由“行方開發項目經理”對標紅線的進行各個項目的安全檢查和驗收。

與之相對應的是外包開發過程中的一個“虛黃線”。該虛黃線的意思是開發商可以在項目開發初期就明確地讓開發人員知道將來的源代碼驗收標準，開發人員就可以提前預防，提前做好技術上的規避方案。這樣一來，外包商和開發人員就會更加積極主動的配合安全漏洞的檢查和修復工作。

2. 建立一個方便、高效的軟件源代碼安全測試管理平臺

可能有安全管理人員會覺得源代碼安全測試，直接找專業的第三方安全測試機構或者安全公司進行測試服務就可以了，不必要由行方自建源代碼安全管理平臺。

但根據經驗，由甲方自建安全測試管理平臺是非常有必要的。這是因為，如果把驗收測試交由第三方來測試時，那勢必安全測試只能在項目驗收時進行一次到兩次的測試。測試頻度太低，時間后置，這樣只能會造成“倉促地”測試和驗收，外包人員“極不情愿地”配合和“應付式”修復漏洞的局面。一旦形成這樣的情況，那上面行方項目經理的“安全驗收”工作就會越來越難開展，也無法保證質量，慢慢地就只是留于“形勢”了。

這一點，我們已經看到很多的商業銀行就是這樣的情況。所以，由甲方自建一個軟件源代碼安全測試管理平臺，提供兩種測試并行的方法才能把“安全測試標準”有效地執行下去。目前國內自主可控的源代碼安全測試管理平臺并不多，思客云公司找八哥云管理系統是個不錯的選擇。

3. “強制式”測試與“自助式”測試并行

為了避免上述的問題，在自建安全測試管理平臺的基礎上，我們提出了一個“強制式”測試與“自助式”測試并行的方案。

如上圖中所示，驗收式測試 +“藍虛框”的外包自助式測試。其中驗收式測試由甲方的項目管理人員完成。這是強制式的，每一個項目在交付前都要進行一次強制式驗收測試。

同時，在開發過程中，允許外包商開發人員可以在開發過程中不定期的對源代碼進行自助式的安全測試，這樣可以讓外包人員及時地檢測出安全問題及時地修復漏洞。外包商就可以對強制驗收式測試沒有那么抵觸，更加積極配合，安全測試工作就會更加的順暢。同時也不會因為安全測試影響項目驗收進度，影響交付和發布了。

軟件源代碼安全驗收測試，一個簡單又高效的軟件安全保障手段，雖然已經提出多年，但是如果沒有一個有效的模式為基礎，則只會讓商業銀行，外包商，開發人員，安全人員和項目管理人員徒增煩惱。思客云找八哥系統以提供最佳“源代碼安全測試”整體解決方案為己任，希望能夠給您提供必要的幫助!