6大原因導致「最安全的程式」也會出現隱患!

ONEASP發表於2015-12-09

儘管像銀行、大型電商以及政府等大型機構在確保程式設計師寫出最安全的軟體上付出了巨大的努力:比如僱傭最有經驗的程式設計師,使用昂貴的程式碼分析工具等等。但是媒體頭條上還是經常可以看到大型組織出現的安全事故。

這的確讓很多企業非常沮喪,管理者都可能在想同樣的問題:為什麼付出這麼多努力還是不能確保系統安全呢?是什麼原因導致這樣的情況發生呢?本文從6個方面來解釋為什麼編寫安全的程式碼只能解決安全的一小部分問題:

1,確保自己程式碼安全只是冰山一角

現代軟體尤其是大型的銀行系統軟體都是由自己的編寫的程式碼、開源軟體、第三方提供的元件以及軟體開發框架組成,現在幾乎沒有純粹使用自己的編寫的軟體就能完成一個系統,這無論從軟體思想和ROI方面考慮都是不現實的。研究標明通常一個現代軟體裡完全由本公司程式設計師編寫的程式碼只佔所有程式碼的10%到30%。所有即使是公司制定了最嚴格的程式碼安全規範同時每個程式設計師都有能並完美執行了安全編碼規範,也只能解決最多20%的潛在問題。 這些僅僅只是冰山一角。

2,應用系統大部分程式碼安全不可控

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

3,想修補了已經為時已晚

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

4,程式碼安全規範控制非常艱難

現代大型系統都已經告別小作坊的方式,大型系統通常需要很多程式設計師一起通力合作才能完成,這些程式設計師的能力,資歷以及性格各方面都有非常大的區別,專案外包也是一大趨勢,還有的大型公司的程式設計師工作在不同的地域,時區,文化,語言,國家,這些都給程式碼安全規範的統一完整實施帶來巨大的困難,代價非常的大。

5,應用程式執行環境也存在漏洞

即使企業有非常強大的整合能力,能確保自己編寫的程式和所有外部購買的程式都沒有漏洞,但是應用程式還是得部署到各種執行環境裡,比如 Java 程式需要 JVM,同時需要執行在各種 Web 容器裡(比如 Apache Tomcat, WebLogic, JBoss, WebSphere 等等),這些環境漏洞是企業沒有辦法控制的,只能將所用到環境跟新到最新的版本。其他的漏洞只能聽天由命了。

6,每個人都可犯迷糊的時候:

理想來說是每個人在寫每一行程式碼的時候都能夠遵循安全編碼的最佳實踐,這個本身就是違背基本規律的,每個人都有犯迷糊的時候,同時專案的進度,排期,以及各個部門的協調都會造成各種錯誤的發生。

儘管我們在這裡詳細的描述了僅僅通過安全編碼是不能完全杜絕安全事故發生,但是安全編碼對任何公司都是非常重要的,畢竟安全無小事,公司應該為開發者和安全編碼制定政策和程式,提供安全意識培訓,並結合各種程式碼掃描、分析工具,儘可能的減少程式碼漏洞的數目,對能承受修復漏洞需要付出的成本的大公司來說還是非常有意義的,它能有效的減少受到攻擊的可能性。

大型為了確保安全還可以採用滲透測試和分析公司 Gartner 提出來的一項新興技術,稱執行應用程式自我保護功能 RASP 。這種方法實現在程式執行時進行安全檢測和保護的能力,對防範零日攻擊和 APT 有非常好的效果。

相關文章