在上一篇文章《敏捷精益團隊面臨的三大安全挑戰》中，我們對現如今敏捷精益團隊所面臨的安全挑戰進行了總結和分析，這三大挑戰分別是：
- 一次性的安全檢查無法匹配持續性的交付模式
- 缺乏自動化、自助化的支持，安全實踐落地難
- 高聳的部門墻讓開發和安全團隊難以進行高效的協作
在接下來的幾篇文章中，我們將逐一為你介紹團隊、組織應該如何應對這些挑戰。本篇文章先來講講如何解決第一個挑戰。
原則：采用持續性的、輕量級的，能夠融入到持續交付模式的安全活動
對于絕大多數團隊而言，為了確保開發出來的應用具有足夠的安全性，滲透測試是一個被廣泛采用的手段，也可以說是唯一依賴的手段。然而由于滲透測試比較重量級，通常只能提供一次性的安全反饋，而這在追求快速開發、迅速響應市場變化的敏捷精益開發方式下，它的不足被放大了。
團隊需要的是一個高效的安全質量反饋機制。所謂“高效”是指，這個機制必須能以更快的速度、更高的頻率提供應用的安全質量反饋，并且要足夠輕量級以便于無縫融入到迭代交付過程中。
那么“更快”是多快？多頻繁才算“更高的頻率”？“輕量級”要輕到什么程度？快到“立等可取”，比如只需幾分鐘甚至更少時間，就能知道應用的安全質量如何；頻繁到任意時刻都可以獲取一次安全質量反饋，比如每次代碼提交后，都能知道應用安全質量是否被破壞；輕量級到團隊不認為這些安全活動會帶來多大的額外付出，比如每日代碼審查中，順便從安全的角度對代碼進行評審，就能阻止有安全風險的代碼被提交到代碼倉庫，而整個過程可能只多花費了幾分鐘時間而已。
一些推薦采用的安全活動
在CI中集成自動化安全掃描工具
其實在很早以前大家就已經發現，憑借人工的力量從應用里尋找安全漏洞異常耗時，另外對于某些安全漏洞，完全可以通過特征識別的方式通過腳本來自動進行檢測，于是從那時起就誕生了一系列自動化安全掃描工具，以下簡稱“漏掃工具”。
與此同時，在應用開發這件事情上，持續集成、持續交付的理念也在迅速的被廣泛接納，越來越多的團隊開始使用CI，也體會到了自動化的威力所帶來的好處。
隨著CI的廣泛普及，團隊完全可以把這些漏掃工具集成到CI當中，作為應用構建過程中的一個標準步驟來執行。這樣，團隊既可以借助漏掃工具以節約人工成本，又可以持續性的對應用安全質量進行監控：一旦某次構建發現安全問題，構建流水線就會失敗，引起開發團隊的注意，促使團隊盡快對有問題的代碼進行修復，從而降低漏洞修復成本。
漏掃工具數量眾多，可以說是百家爭鳴，不過可惜的是，易于集成到CI中的卻不多。OWASP ZAP提供了RESTful API，也有Jenkins插件，算是做得比較不錯的漏掃工具，而BurpSuite要做到同樣的效果還需要額外的配置才行。推薦團隊可以先嘗試把ZAP集成到CI中。關于具體的集成細節，我們會通過后續文章進行介紹。
編寫自動化安全功能性測試用例
漏掃工具不是全能的，有些類型的安全漏洞，比如身份認證、訪問控制以及和業務強相關的漏洞，它就很難甚至根本無法掃出來。然而，這些漏掃工具不容易掃出來的安全漏洞，對于人來講卻正好是小菜一碟。
舉個例子，人能夠很好的理解下面這個API應當具備的安全行為，并對其進行有針對性的測試，然而漏掃工具則已經哭暈在廁所：
API：
/api/customers/{customer_id}/orders
期待API的安全行為：
- 若請求未通過身份認證，則拒絕當前請求。
- 在請求通過身份認證的前提下：
(a) 若當前用戶的角色是CUSTOMER，那么如果當前用戶ID和URL中的custoemr_id不匹配，則拒絕當前請求。
(b) 若當前用戶的角色是SALES_MANAGER，那么如果URL中的customer_id所指代的用戶不在該SALES_MANAGER的所管轄范圍內，則拒絕當前請求。
漏掃工具檢查不出來的安全問題，人可以很好的進行測試，并且依然通過自動化來提高效率。團隊可以像平常編寫集成測試，或者端到端功能性測試那樣，對于期望應用應當具備的安全行為，編寫對應的測試用例進行覆蓋。我們把這種做法叫做編寫自動化安全功能性測試用例。
隨著自動化安全功能性測試用例數量的不斷累積，它的威力也將越來越明顯，尤其是在對應用進行回歸測試的時候，更是顯露無疑。通常而言，在團隊每次做應用發布之前，都會進行一次回歸測試，主要目的是為了確認新功能工作正常，與此同時已有功能未被破壞。安全作為應用質量中的重要組成部分，也應該進行一次回歸測試。相比于傳統的滲透測試，自動化安全功能性測試用例再配合上CI中的自動化漏掃工具，在很短的時間里就能對應用進行比較全面的安全檢查，為應用發布提供決策支持。
識別安全需求，并將其作為驗收標準寫入到用戶故事卡
如果說把漏掃工具集成到CI，以及編寫自動化安全功能性測試用例是在“把事情做對”，那么識別安全需求，并把它作為驗收標準寫入到用戶故事卡中則是在“做正確的事情”。
團隊其實是很重視安全的，他們愿意付出努力提升應用的安全性，然而這又和我們實際觀察到的現狀有沖突：安全的事情大家心知肚明，但就是沒人主動去做。為什么？原因是多方面的，其中一個重要的原因是，因為安全需求沒有被明確提出來，它既不在故事卡的驗收標準里，也沒有在給故事卡估點的時候考慮進去。于是安全需求就仿佛變成了“多出來的”工作量，一旦團隊面臨交付壓力，這部分工作自然就會被無限期的往后推遲，最后的歸宿就是不了了之。
因此，團隊除了需要借助漏掃工具以及自動化安全性功能測試用例，還需要把安全需求明確出來，納入到項目交付范圍內。團隊可以用威脅建模、惡意攻擊場景頭腦風暴等活動來梳理安全需求。
此外需要注意的是，安全需求的表現形式不是最重要的，最關鍵的在于把需求在團隊內部明確出來，而不是大家心照不宣。比如，安全需求是寫入到故事卡的驗收標準里，還是單獨創建安全故事卡，這本身并不重要，重要的是安全需求通過這些形式能得到明確，讓團隊能把安全需求和常規的業務需求一起放到Backlog里，統一對它們估點、設置優先級、安排迭代交付計劃。
小結
敏捷精益團隊面臨的第一大安全挑戰就是一次性的安全檢查無法匹配持續性的交付模式。應對這一挑戰，團隊需要采用一系列持續性的、輕量級的，能夠融入到持續交付模式的安全活動，從而使得團隊建立起一個高效獲取應用安全質量反饋的機制。
至于敏捷精益團隊如何應對另外兩大安全挑戰，我們將在后續的文章里一一詳解，敬請期待。
