讓安全實踐在敏捷團隊落地(2)

那么為什么攻擊者可以獲得Web系統權限呢？這種幾率到底有多大呢？如果可能性非常小，我們是不是不必花費太多精力在安全上面呢？

我們來看一下Web系統的組成，一個最簡單的系統都至少有這么幾個部分：

如上圖，瀏覽器發送請求到服務器，服務器給瀏覽器響應，服務器會查詢數據庫，數據庫返回結果。在這個過程中，我們開發的Web程序不可避免的存在安全漏洞，甚至我們開發系統所使用的編程語言也會有安全問題。在開發時，我們常常會引用一些第三方的工具、組件，而第三方的安全性也沒有辦法保障，甚至數據傳輸過程中使用的協議、操作系統本身也會有安全問題。所以可以想象一下，如果我們不做任何的安全防范，那么每一個軟件都是一個非常脆弱的系統，很容易出現安全問題。

常見的Web安全問題

既然這么多環節都有潛在的安全風險，那么該如何著手呢？可以參考OWASP TOP 10，以便對最嚴重的Web應用程序安全問題有個大致的了解。

敏捷開發模式現狀

我們是一個已經實施敏捷開發七年的團隊，一共有五十多人，劃分成不同的Feature小組進行日常的工作，其敏捷開發模式已經非常成熟，我所在的Feature小組有6個開發人員，1個業務分析師，1個QA，我們每個小組的交付模式都是這樣的：

如上圖，以用戶故事為單元，所有的用戶故事都會經歷一個從分析到最后給客戶演示的生命周期，多個用戶故事組成一個Feature，然后我們會進行Feature的功能測試，給客戶展示整個功能，最后在發布之前，客戶會邀請第三方的專業安全公司做滲透測試，然后找我們的開發團隊修復安全缺陷。

那么這種方式有什么問題呢？

1.守門員模式，安全測試非常滯后

2.安全問題的修復時間非常有限

3.只有少數人關注和了解安全

4.依賴獨立的滲透測試

所謂守門員模式，指的就是把所有的問題和風險都留在最后，靠少數人來保障，在當時的開發模式下，第三方的安全公司就是我們系統的安全守門員，可想而知，如果我們的團隊對安全沒有任何了解，在用戶故事的開發階段引入的安全問題要等到發布之前才能夠被發現，安全測試是非常滯后的，反饋周期特別長。

另外當第三方的安全公司發現問題，留給我們團隊修復問題的時間特別有限，因為滲透測試是發布前的最后一個階段，長時間的修復又會導致發布延期，所以經常會導致安全修復以補丁的方式發布。

而且除了少數修復過安全缺陷的開發人員對安全有一點點了解之外，團隊內是沒有人關心安全的。

最大的問題是，所有的安全防范都依賴于最后的獨立滲透測試。雖然因為執行滲透測試的是專業的第三方安全公司，他們有專業的安全知識，可以發現很多公共的安全問題，也可以提供專業的極具權威性的安全報告，但這種方式的滲透測試有個致命的弱點，他們對業務知識了解不夠，很難發現跟業務相關的安全問題，而這一類的安全問題又占了相當大的比重。

原文轉自：http://www.infoq.com/cn/articles/let-safe-practices-land-in-the-agile-team