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

可以看到，這種敏捷開發模式的現狀就是：試圖將安全注入一個已經成型的系統中。

安全落地嘗試

那么了解了之前開發模式存在的問題，安全又這么重要，客戶和團隊都希望可以改變這種現狀，提高安全質量，減少補丁，讓每一個人都關心安全，但是我們都擔心安全需要巨大的投入，會影響功能的發布，所以我們決定選擇一個Feature小組做為安全試點，目標周期為一個月（我們的發布周期），觀察投入產出比，然后決定是否要在整個團隊實行。

首先我們小組開始學習BSI，我們認為它所傳遞的是這樣一些理念：

1.將安全融入整個軟件開發過程中

2.所有團隊成員一起為安全負責

3..安全的設計和實施一個持續進行的過程

那么在一個幾乎沒有安全知識儲備的團隊中，如何將以上理念在團隊應用呢？我們遇到了很多的困難，比如：

1.不知道怎么把安全和日常開發結合起來

2.不知道如何編寫安全需求，怎么做安全測試

3.接受了很多安全培訓，不知道如何下手

4. 對安全缺乏專業的認知,對安全開發和測試沒有信心

5.不知道如何滿足客戶期望

分析這些困難，我們開始邁出了艱難的第一步。

首先，召集團隊的核心成員（包括了業務分析師，開發人員，測試人員，技術主管），同時我們邀請了公司的一位安全專家幫我們解答難題，大家頭腦風暴，參考OWASP TOP 10， 結合曾經項目上出現過的安全問題以及對于業務領域的深入了解，嘗試總結屬于我們自己的安全問題項目并且和OWASP TOP 10進行關聯，比如我們討論后的成果是這樣的：

可以看到，我們總結出來的這十項并不是將OWASP TOP 10調換順序這么簡單，我們是針對業務需求，有針對性地進行了重新整理和組織，比如其中的Sensitive Data Exposure，我們就結合項目將它劃分成了四類（1.Authentication，2.Error Handling，3.Code Leak，4.Cookie Management），之所以會劃分的這么具體，是因為我們自己的TOP10更貼近實現。另外我們還針對每一項添加了項目上的例子作為參考，讓團隊每一個人都清楚地知道我們自己的TOP 10都是什么樣的以及業務場景下可能出現的安全問題。

然后我們將項目專屬TOP 10作為模板加入到了每個用戶故事中，這么做有兩個好處：

第一，業務分析師在寫用戶故事的時候，可以將其作為參考來編寫安全驗收標準；

第二，如果業務分析師在缺乏安全知識的情況下很難編寫安全需求，我們可以將其直接作為安全需求以防遺漏。

當然這還遠遠不夠，更理想的情況是在需求分析階段、業務分析師和客戶在討論需求的過程中盡量參考一些基本的原則，比如最小權限原則，來確定和編寫更加準確的安全驗收標準。如下圖。還可以讓更多的人參與到需求分析階段，通過威脅建模等手段分析出更全面的安全需求。當然這就需要我們的業務分析師增加安全相關的知識儲備，我們也在向這個方向努力。

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