Web安全系列選題之 敏捷開發需事先內置
云計算等新型應用模式的出現，促使更多的應用程序運行著互聯網上，基于web應用程序可謂是隨處可見。這無疑對應用程序的安全性是個巨大考驗。
敏捷（Agile）開發日漸流行，很多開發者都采用安全功能事后補充是這種開發方式，無疑為未來的應用程序埋下了安全隱患。安全性必須是應用程序開發方法當中一個不可或缺的部分，敏捷開發流程也不例外。
應用程序安全性已成為所有軟件開發項目的一個關鍵部分。它包括在整個軟件開發生命周期中采取的所有措施，旨在防止程序缺陷被人利用。在應用程序的需求征集、設計、開發、部署、升級或維護等階段逐漸出現的眾多缺陷成了網絡攻擊的基礎。
由于應用程序缺乏固有的安全性，加上編程方法很糟糕，應用程序經常被黑客們鉆空子，并且幫助導致了數據泄密及知識產權失竊引起的重大經濟損失。這就是為什么安全性必須是應用程序開發方法當中一個不可或缺的部分，敏捷（Agile）開發流程也不例外。
據說敏捷開發流程早在2001年11月就問世了。近些年來，這種軟件開發方法日漸流行。敏捷開發流程致力于把程序開發與客戶需求和公司目標統一起來的迭代發現和開發。
盡管如此，筆者還是發現，敏捷開發的基本特點往往決定了直到業務功能建成后才考慮安全問題。許多時候，安全不是事先添加到最初發布的功能中，因而使敏捷應用程序的安全功能成了事后擴充（bolted on）的，而不是事先內置（built in）的。
我在分析應用程序安全問題時，往往把它們分成兩類：業務邏輯缺陷和技術安全漏洞。大家已認識到，安全必須事先內置到應用程序當中，而不是最后擴充上去。如果使用敏捷開發方法，這就帶來了難題。
這還引發了頗有意義的爭論：敏捷開發是否適用于涉及敏感安全信息的應用程序？或者是否適用于為進入其他系統提供秘密通道（即后門）的應用程序？
與許多人一樣，筆者也認為敏捷開發流程并不適用于對安全很敏感的應用軟件。這主要是由于敏捷開發流程具有輕便、非正式、漸進式開發（build-as-you-go）的特性。安全功能必須事先內置，而不是事后擴充；因而，安全功能必須融入到整個敏捷開發流程當中。
項目動工之前就要開始考慮安全了。必須一開始就要制訂安全策略和目標。之后及在項目定義步驟期間，必須制訂及記錄重要的安全需求和目標，并且告知開發團隊。一旦我們奠定了這些安全基礎，必須評估滿足這些目標的必要條件。在范圍界定和評估步驟，必須抽出時間來審查不斷變化的需求，從而完善安全需求和目標。
界定安全范圍、估計所需工作量后，可以制訂重要的安全計劃。你在制訂這些重要的安全計劃時，必須明確安全協調活動，以便評估迭代開發工作過程中每個階段的安全措施，并且確保這些措施已在考慮之中。現在基礎打好了，我們就可以探討在迭代開發周期（sprint，一般最多以30天為一個周期）內的安全。
迭代開發的首要步驟之一就是，為每個迭代開發周期確立一個主題，這個主題定義了這個開發階段著重處理哪種類型的功能。明確了每個迭代開發周期的主題后，就要發現及記錄預測的對安全帶來的影響，可能還要在開發過程中建立樁模塊（stub）。
借助建立樁模塊這種方法，不需要先為完整功能編寫代碼，就可以開發應用程序的某些部分。現在有必要獲取滿足下面這個條件的與安全有關的場景和細節：它們要與某個迭代開發周期的迭代發現和開發過程中所定義的功能相一致。
發現了安全需求后，就必須作出這個決定：現在添加安全功能、為它們建立樁模塊，還是推遲到以后的迭代開發周期來添加。兩個方面確實影響了把安全添加到迭代開發周期當中的決定。其中對這個決定影響最大的就是，會不會部署及積極使用軟件，以及會不會涉及安全風險和敏感信息。
如果軟件要加以部署，就必須事先內置安全，并進行測試，這是迭代開發周期的一部分。不然，建立樁模塊或推遲都是切實可行的選擇。這時候，迭代開發開始了。軟件開發好后，通常進行低層測試，還要演示，并讓客戶進行代碼走查（code walkthrough）。這些測試用例和場景必須實際檢驗安全措施。
話雖如此，實際檢驗這一步并不出現，這是我的個人經驗。所有添加的與安全有關的功能和特性都必須進行實際檢驗和演示。測試和代碼審查方面必須加大關注力度，尤其要注意競態條件、跨站腳本、信息泄漏和SQL注入攻擊。
事實已證明，這四種編碼問題都是Web應用程序當中最常見的軟件漏洞。一旦完成了基本測試，就可以讓軟件進入到模擬的部署環境。
作為迭代開發周期一部分提供的軟件安裝到具有代表性的操作環境中。十有八九，開發環境與操作環境大不一樣。這會導致軟件操作問題和安全問題。這時就需要部署到模擬生產環境的環境中，那樣才能解決這些問題。之前使用的所有測試用例和場景構成了回歸測試（regression testing）的基礎。
自動化測試腳本重新運行，確認在新環境下能夠正常操作。另外，建立新的測試腳本和場景，以便從頭到尾全面檢驗軟件；還要進行檢查及測試，查找有無軟件漏洞。一旦所有這些測試都成功通過，軟件可以進入到下一個階段：客戶驗收階段。
在這個階段，作為一個或若干迭代開發周期的一部分提供的軟件進行演示、評估和驗證，最終由商業客戶決定驗收或拒收。這一步必須包括對安全進行檢查。正如客戶有商業驗收標準，他們也應當制訂安全驗證標準。盡管這看似過于絕對化，其實不是這樣。有條件驗收是普遍慣例。
要是某個地方出現了變化，項目發起人往往只接收某個迭代開發周期的交付成果。如果確認了驗收條件，就要安排時間進行返工。一旦安排了時間，滿足驗收條件所需的返工就必須完成。一旦返工完成，并通過測試，就要審查返工部分，并向商業客戶進行演示，確保符合有條件驗證的目的。
獲得汲取的教訓是指收集、記錄及分析迭代開發期間所收到反饋的過程。這項工作很關鍵，那樣隨后的迭代開發周期就能從中獲益。
這項工作很關鍵的理由還在于，獲得安全方面汲取的教訓讓團隊成員有機會反省迭代開發周期過程中導致安全缺陷的任務、事件和活動。另外，獲得汲取的教訓需要回過頭去分析一下風險管理工具，并記錄優點和不足。
迄今為止開發出來的所有軟件必須整合起來加以驗證。一旦完成了這項工作，就必須加以驗證，以確保功能正常。短期內還需要監測及跟蹤，確保所有軟件和系統組件能協同順暢運行，沒有帶來安全漏洞。要站在安全的角度，測試系統之間的相互關系。必須在這個步驟創建及運用新的安全測試場景。
此外，如前所述，測試和代碼審查方面必須加大關注力度，尤其要注意跨站腳本、信息泄漏和SQL注入攻擊。一旦各方面可以協同順暢運行、而且安全，就可以準備發布到生產環境了。軟件發布管理（RM）是所有軟件開發方法和項目當中比較新的一部分。RM充當所有業務部門和IT部門之間的連接紐帶，可以保障順利過渡至新系統。
最后，是時候進入到下一個迭代開發周期了。收尾步驟表明某個迭代開發周期正式收工。另外，這個步驟帶來了項目工件（artifact），確保為代碼編寫了相應文檔，并對代碼作了備份和歸檔。這一步常常需要改變公司所部署的安全監控流程和功能。
安全行業把可怕事件頻發的2008年稱為“數據丟失年”，這是由于這一年發生了多起敏感信息安全泄密事件。美國國家情報總監Dennis C. Blair在國會聽證會中聲稱，去年全球各地的眾多公司因數據竊取而丟失的知識產權價值超過1萬億美元。
軟件漏洞是最主要的根源之一。這應該向從事應用程序開發的每個人敲響了警鐘，不管他采用什么方法來開發；這還向敏捷開發項目發出了預警信號：它們需要確保事先加入而不是事后擴充了合理的安全功能。
【編輯推薦】
