那些我們還不知道的程式驚人複雜性

在過去幾十年的高速編碼中，我們已經飛速實現自動化，導致我們現在已經無法保護我們構建的東西。首先，讓我們看幾個事實：

通常情況下，中等規模的金融機構擁有超過1000個應用程式，而大型企業則超過10000個應用程式。平均來說，這些應用程式都有數十萬行自定義程式碼，最大的應用程式可能有超過千萬行程式碼。此外，每個應用程式都包含幾十個到幾百個軟體庫、框架和元件，這通常超過自定義程式碼的10倍。並且，這個數量正在迅速增長，超過20%的應用程式每年都會有新增和更新的程式碼。

例如美國聯邦政府稅程式碼(US Federal Tax Code)，在過去幾年已經大幅增長，目前，該程式碼已經擁有超過440萬行，但卻只有幾個應用程式。作為安全研究人員，筆者發現程式碼中包含數千個漏洞。但作為前任執行長，筆者還分析了法律合同中的漏洞。有趣的是，無論筆者審查軟體程式碼還是法律語言，這兩種分析並沒有你想象的那麼不同。這兩種分析都需要了解專門的語言以及基本業務。

當前的安全形勢

在摩根大通安全洩露事故的細節披露後，該公司一名前僱員告訴《紐約時報》，攻擊者彷彿竊取了國會大廈的構造圖，摩根大通沒辦法監控每個門和玻璃窗。實際上，筆者認為情況更糟糕，摩根大通花了幾十年時間來建立其軟體基礎設施，沒有簡單的辦法可以對其作出改變。

現在，根據安全專家表示，典型的企業web應用程式一般包含22.4個嚴重漏洞。這些漏洞通常很容易找到，但其嚴重程度不相同。通過結合這些漏洞以及日益複雜的威脅，我們看到越來越多的安全洩露事故。單單是今年的安全洩露事故已經非常發人深省。

傳統應用安全的侷限性

在過去，我們進行手動滲透測試和程式碼審查來發現漏洞。這些審查可以很好地發現漏洞，而開發人員也有時間在程式碼進入生產之前來修復問題。但最近軟體開發領域的進步，包括庫和元件的廣泛使用、高速開發方法、複雜的框架以及高深莫測的協議，都減慢了手動分析。

很多行業已經發展到，生產速度已經最大化，而質量卻無法跟上。汽車行業經過很多艱苦歲月來換裝備以提高質量。Agile和DevOps社群已經成功地使用更快的迭代來保持軟體專案不會偏離軌道太遠。現在，我們正在越來越快地構建程式碼，但安全沒有同步發展。我們必須找到新的技術來確保快速發展和擴充套件中的安全性。

重構應用安全

首先，我們需要摒棄安全例外的觀念，並從其他行業借鑑經驗。我們可以監控整個軟體開發過程(設計、開發、測試和生產)，確保應用程式不斷測試自己並提供實時安全反饋資訊。從本質上講，我們必須將安全測試、入侵檢測和響應以及執行時保護作為每個應用程式的一部分。

Etsy、Netflix、Twitter和Yelp等公司已經意識到這個問題，並開始部署新的安全工具。這些工具不像傳統工具，在開發過程的最後使用。這些工具用於軟體開發過程中，在應用程式被構建、整合、測試和部署時實時收集安全資訊。最重要的是，這些工具(例如連續整合和連續交付工具)並不會干擾正常的軟體交付過程。干擾或者減緩軟體交付的安全工具不會被使用。正如Signal Science公司的Zane Lackey所說，企業把延誤視為破壞，會盡量避免。

我們怎樣才能實現那樣的情況?這並沒有你想象的困難。你可以從建立指令碼、測試用例或執行簡單測試的工具開始。或者使用免費的Contrast for Eclipse外掛。你將需要的大部分基礎設施可能已經由Agile and DevOps團隊建立好了。

我們需要重新構想我們所有的安全測試技術，讓它們可以共同發揮作用。我們還需要我們的安全專家變成教練和工具達人，而不只是追逐漏洞，因為這樣永遠不會形成規模。