應用安全不能只依靠防火牆，必須要在應用開發階段採取適當的安全控制措施，使得應用在釋出上線前就具備較好的安全性，避免人為失誤造成安全隱患。

不少企業早就意識到了這一點，然而理想和現實之間還隔著幾十個安全漏洞，尤其是那些採用敏捷或者精益開發模式的團隊，在具體的實踐過程中，幾乎無可避免的會遭遇到下面幾個挑戰。

挑戰1：一次性的安全檢查無法匹配持續性的交付

為確保團隊開發出來的應用具有足夠的安全性，最常見的選擇是對其進行全方位的安全滲透測試。無論這樣的測試是由企業自己的安全團隊執行，還是購買外部第三方服務，最終都會得到一份詳細的安全報告，團隊接下來需要做的就是基於這份報告所揭露的漏洞，對應用進行相應的調整，直到安全漏洞被修復為止。

持續交付是敏捷、精益開發團隊的核心能力之一，這意味著團隊可以做到每週甚至任意時刻釋出產品，持續性的從真實環境中獲取市場反饋，然後基於這些反饋對產品進行調整。一個可以參考的案例是，早在2014年的時候，亞馬遜平均每秒有一次以上的產品部署，每天如此。

與此同時，安全滲透測試卻沒有這麼高的“交付”速度。由於滲透測試的特殊性，雖然有大量的自動化漏洞掃描工具可以使用，但是一次全面、高質量的滲透測試依然需要人工參與，幾天甚至一兩週之後才能得到測試報告是普遍現象。

那麼問題來了，一方面開發團隊持續性的每週都有新功能上線和舊功能調整，另一方面滲透測試卻沒辦法在這麼短的時間裡完成，它只能是階段性、或者定期性的進行，例如每個季度測試一次。

這種情況下，開發團隊該何去何從？如果要安全，那麼就得等著做滲透測試，而且一旦發現安全漏洞還要花額外的時間去修復，產品釋出必定會延期。如果要效率，那麼就只能冒著風險釋出，因為誰也不知道當前應用有沒有安全漏洞，萬一被黑客發現並且加以利用，後果不堪設想。

問題的關鍵在於，開發團隊是在持續的釋出應用到生產環境，然而滲透測試卻是個相當耗時的一次性活動，它沒辦法跟上這麼快的交付速度。

挑戰2：缺乏自動化、自助化的支援，安全實踐落地難

開發團隊其實明白安全對於應用而言至關重要，也知道在開發過程中就應當通過運用各種安全最佳實踐來主動消除安全問題，把安全風險降至最低。不過現狀卻是，不少安全實踐要麼無法落地實施，要麼有流於形式的傾向。

一個真實的案例

一個開發團隊在做完業務需求梳理後，立即進入了開發階段。安全團隊雖然在專案啟動時提出過安全要求，例如要求團隊採用威脅建模活動，識別出應用面臨的安全威脅，並制定應對措施。然而由於該專案交付壓力大，時間緊任務重，再加上團隊成員對於威脅建模並不熟悉，最後這個活動被一拖再拖，直到應用開發完畢進行上線前的審批時，才發現沒有做威脅建模，而此刻為了能讓應用按時上線，只好回過頭來臨時補一份威脅建模的文件，僅用於應付安全部門的要求。這種情況下，安全威脅根本得不到全面的分析和應對，風險由此而生。

在專案前期的設計階段是進行威脅識別的最佳時刻，開發團隊只要在這時做一次威脅建模，就能識別出潛在的安全風險，並且在接下來的開發過程中採取適當的措施加以應對。但是開發團隊卻彷彿是懶癌晚期患者，硬是拖到上線前才把威脅建模補上，而此時它早已失去意義。

為何開發團隊一邊認同安全的重要性，一邊卻又對安全實踐如此怠慢呢？本質原因在於，某些安全實踐需要大量人工參與，或者對人員安全技能有很高的要求，與此同時又缺乏自動化、自助化的支援，因此在開發團隊看來，這些實踐的採納成本太高，在面臨交付壓力的情況下選擇性的忽略，或者認認真真的走個形式，就成了再正常不過的結果。

挑戰3：高聳的部門牆讓開發和安全團隊難以進行高效的協作

隨著敏捷、精益開發模式的普及，再加上DevOps轉型的助推，不少企業已經開始組建全功能開發團隊，團隊中各個角色有著共同的目標，相互協作以更高的效率交付應用。但是安全團隊卻依然隸屬於一牆之隔的安全部門。

別小看了這堵牆，說它是萬惡之源有點太誇張，但它的存在確確實實阻礙了企業實現其業務價值最大化。牆的這邊，開發團隊竭盡所能的以最快的速度完成應用開發，以求儘快上線獲取反饋；牆的另一邊，安全團隊只關心應用是否安全，至於是否急著上線，那不是他們關心的問題。但是他們都忽略了一個事實，那就是企業的成功需要兩者共同高效的協作。

小結

敏捷、精益團隊一方面要保持快速的交付速度，一方面還要提高應用的安全質量，看上去這是魚和熊掌不可兼得的事情，然而事實上我們依然有辦法解決這些挑戰。

開發團隊可以通過自動化，顯著降低安全實踐的實施難度和成本，把一次性的安全檢查轉變為持續性的安全質量反饋。對於安全團隊，也應當向著開發團隊邁進一步，打通開發和安全部門之間的隔離，以更加緊密和高效協作的方式，共同確保應用具備更高的安全質量。