6大緣由致使「最安全的程序」也會出現隱患！

儘管像銀行、大型電商以及政府等大型機構在確保程序員寫出最安全的軟件上付出了巨大的努力：好比僱傭最有經驗的程序員，使用昂貴的代碼分析工具等等。可是媒體頭條上仍是常常能夠看到大型組織出現的安全事故。

這的確讓不少企業很是沮喪，管理者均可能在想一樣的問題：爲何付出這麼多努力仍是不能確保系統安全呢？是什麼緣由致使這樣的狀況發生呢？本文從6個方面來解釋爲何編寫安全的代碼只能解決安全的一小部分問題：

1，確保本身代碼安全只是冰山一角

現代軟件尤爲是大型的銀行系統軟件都是由本身的編寫的代碼、開源軟件、第三方提供的組件以及軟件開發框架組成，如今幾乎沒有純粹使用本身的編寫的軟件就能完成一個系統，這不管從軟件思想和ROI方面考慮都是不現實的。研究標明一般一個現代軟件裏徹底由本公司程序員編寫的代碼只佔全部代碼的10%到30%。全部即便是公司制定了最嚴格的代碼安全規範同時每一個程序員都有能並完美執行了安全編碼規範，也只能解決最多20%的潛在問題。 這些僅僅只是冰山一角。

2，應用系統大部分代碼安全不可控

根據金融機構的統計數據，大部分銀行最少也有通常的軟件系統都是從第三方買來的，有可能在買來的系統中作一些定製化的修改。這些軟件一般是不提供源代碼，因此企業也很難確保這些買來的軟件的開發過程遵照安全代碼開發最佳實踐。正如咱們所看到的，過去兩年，許多知名度很是高的安全事故都是攻擊第三方應用和IT供應量的漏洞。這個趨勢會愈來愈明顯。

3，想修補了已經爲時已晚

在項目啓動就制定並執行最佳代碼安全實踐效果是最理想的，可是不幸的在大部分大型項目開發，等意識到須要代碼安全並制定規範和標準的時候，大部分功能都已經實現了，每一個經歷過大型項目的人都太熟悉這個場景了。這個時候想修復想經過重構代碼去修復漏洞幾乎不可能，重構大型軟件須要很是程的時間，這在開發週期和人力成本都是不可承受的，帶病上線是很是正常的事情。這些帶着已知漏洞運行的系統只能寄但願虛擬防火牆補丁甚至是運氣來防止災難性的安全事故發生。

4，代碼安全規範控制很是艱難

現代大型系統都已經告別小做坊的方式，大型系統一般須要不少程序員一塊兒通力合做才能完成，這些程序員的能力，資歷以及性格各方面都有很是大的區別，項目外包也是一大趨勢，還有的大型公司的程序員工做在不一樣的地域，時區，文化，語言，國家，這些都給代碼安全規範的統一完整實施帶來巨大的困難，代價很是的大。

5，應用程序運行環境也存在漏洞

即便企業有很是強大的整合能力，能確保本身編寫的程序和全部外部購買的程序都沒有漏洞，可是應用程序仍是得部署到各類運行環境裏，好比 Java 程序須要 JVM，同時須要運行在各類 Web 容器裏（好比 Apache Tomcat, WebLogic, JBoss, WebSphere 等等），這些環境漏洞是企業沒有辦法控制的，只能將所用到環境跟新到最新的版本。其餘的漏洞只能聽天由命了。

6，每一個人均可犯迷糊的時候:

理想來講是每一個人在寫每一行代碼的時候都可以遵循安全編碼的最佳實踐，這個自己就是違背基本規律的，每一個人都有犯迷糊的時候，同時項目的進度，排期，以及各個部門的協調都會形成各類錯誤的發生。

儘管咱們在這裏詳細的描述了僅僅經過安全編碼是不能徹底杜絕安全事故發生，可是安全編碼對任何公司都是很是重要的，畢竟安全無小事，公司應該爲開發者和安全編碼制定政策和程序，提供安全意識培訓，並結合各類代碼掃描、分析工具，儘量的減小代碼漏洞的數目，對能承受修復漏洞須要付出的成本的大公司來講仍是很是有意義的，它能有效的減小受到攻擊的可能性。

大型爲了確保安全還能夠採用滲透測試和分析公司 Gartner 提出來的一項新興技術，稱運行應用程序自我保護功能 RASP 。這種方法實如今程序運行時進行安全檢測和保護的能力，對防範零日攻擊和 APT 有很是好的效果。