本文中的“安全掃描”是指開發團隊在距離產品上線日期比較近的時候，通過公司里的安全團隊或者外部第三方安全公司對產品進行安全掃描，團隊基于安全掃描報告，對產品中存在的安全漏洞進行修復的過程。不同的公司，不同的開發團隊對它的稱呼可能不一樣，有人把它叫做滲透測試，也有人把它叫做安全審查、安全評估、安全檢查等等。
如果不做安全掃描會怎樣？
想象一下，你所在的開發團隊正在開發一款互聯網金融產品，所有的核心業務功能基本開發完畢。此時此刻，離計劃中的上線日期只有不到三周時間。通常而言，這時候安全掃描就會介入進來，掃出一堆問題扔給團隊修復。
不過這次不一樣，如果我提議，不必給產品做安全掃描，就這樣直接上線可好？我想，絕大多數人的反應會是下面這樣的：
“神馬？！不做安全掃描？那我怎么知道產品安不安全？萬一出問題了怎么辦？”
“我知道我們產品中一定會有安全問題，安全掃描正好可以幫助我們把這些問題暴露出來，將其修復之后再上線才是萬無一失的選擇。”
“雖然每次安全掃描都會掃出一堆問題來，搞得團隊壓力山大，但如果不做掃描，我們到是輕松了，可產品的安全性卻又是個問題。”
“安全掃描可是我們安全團隊的殺手锏，不讓我們給開發團隊做掃描，那我們的價值怎么體現出來？”
“公司規范里說了，不做安全掃描不準上線。”
“年少輕狂的年輕人，我以過來人的經驗告訴你，這么做是要付出代價的。”
反應越是激烈，說明團隊越是依賴安全掃描。甚至可以說，安全掃描在你的團隊里，是保證產品安全的最后一道屏障，也是唯一的手段。
安全掃描是陳舊落后的手段
有人會說，最后一道屏障又怎樣，唯一的手段又如何，不管紅貓黑貓，抓到耗子的都是好貓。
先不談這樣做是好是壞，我們先來換個角度思考一下，如果把“安全問題”這幾個字換成“功能缺陷”或者“Bug”，你還會認同這種在臨近產品上線之前做一次性的、運動式的大檢查，然后期待著開發團隊在所剩無幾的時間里快速修復掉所有Bug，還不能引入新Bug的做法嗎？
答案顯然是否定的。大家都明白，功能缺陷越早發現越好，否則修復成本將會非常高，越往后拖越對團隊不利。
現如今，還有哪個開發團隊敢說，在開發過程中不需要對軟件做測試，等到最后上線前做一次集中式的測試就夠了？開發團隊也是極盡所能的快速響應軟件質量問題，例如進行測試驅動開發，編寫大量的自動化測試并且通過CI持續的對軟件質量進行監控。
安全問題是如此的重要，它也是軟件質量的一部分，只不過換了個名字，變了種表現形式而已，而我們卻用如此落后的方式來對待它，顯然不合理。
提前做安全掃描可能是空中樓閣
又有人說，安全掃描不就是太晚了一點嘛，我們把掃描時間點往前提一些不就好了嗎？
思路是對的，但很可惜，要做到這一點卻幾乎是不可能的。因為安全掃描有一定前提條件，它只能對已經開發完成了的功能進行掃描，這也就意味著，那些還處于開發過程中的功能是覆蓋不到的。而且隨著開發的進行，軟件功能會有所調整，之前做過的安全掃描很可能會失去意義，最終還是得等到所有功能都開發完畢了，在上線之前再做一次最終的安全掃描。于是這又回到了上面那個問題。
安全掃描的短板不止一處
安全掃描除了上面講到的時間太晚的問題之外，還有不少短板。首當其沖的就是速度太慢，跟不上開發團隊的節奏。盡管有自動化工具的幫助，但是一次全面、細致、深入的安全掃描，往往需要好幾天，甚至更長時間。在如今追求快速開發上線，迅速調整以響應市場變化的環境下，開發團隊沒有這么多時間和耐心來等待掃描結果。
某些采用敏捷或者精益開發方式的團隊，每個迭代甚至每天都有新功能上線和舊功能調整、問題修復等等，而等到幾天甚至幾周后，團隊拿到安全掃描報告的時候，被掃描的功能可能早就被廢棄了，這么做簡直是在浪費資源。
其次，留給安全掃描的時間窗口十分有限，它往往只能在產品功能完成之后，最終上線之前才能進行，在這種情況下，往往只有一次機會進行掃描，也只能給團隊提供一次性的安全反饋。但實際情況卻是，業務需求在不斷發展和變化，開發團隊也在持續對產品功能做出調整，除非每次產品功能發生變化之后立即進行一次安全掃描，否則以現有的模式，是沒有辦法及時給開發團隊提供安全性反饋的。
最后，安全掃描的成本也是不得不考慮的因素。購買外部安全公司的安全掃描服務到是很方便，可是動不動就是幾十萬的支出不是任何團隊都能承受得起的。通過自有安全團隊做安全掃描看上去可能更加經濟實惠，畢竟是公司內部資源，但是別忘了，自建安全團隊也是有成本的，而且要招到杰出的安全工程師也不是件容易的事情。
既然安全掃描有這么多缺點，那為什么還有如此多的團隊在用它？
拋開安全問題暴露出來之后，解決起來是如何痛苦這件事情不談，其實安全掃描也并非一無是處。
盡管安全掃描在時間上晚了一些，速度上慢了一點，還不可持續，但由于軟件開發本身是個復雜的過程，開發團隊在產品安全性上總有疏忽大意的時候，只要進行安全掃描，大多數時候都會有所“收獲”。這樣的話，一方面安全掃描幫開發團隊發現了問題，另一方面安全團隊也體現出了自身價值，正是在這樣的背景下，安全掃描無論是對于開發團隊還是安全團隊而言，都具有難以抗拒的誘惑力。
此外，有時候做安全掃描也是一種無奈之舉，因為有些開發團隊不見黃河不死心，除非你把安全問題明確的擺在他們面前，否則他們意識不到問題的嚴重性，不會輕易的主動去關注安全問題。
除了安全掃描，還有別的什么辦法？
既然安全問題這么重要，安全掃描又是如此的低效，那我們該怎么做才能更好的解決這個問題呢？答案其實早就擺在眼前了，軟件的安全性是軟件質量的一部分，為何不嘗試一下把它和功能需求一樣，都當做頭等公民來看待呢？那些用于保證軟件質量的最佳實踐對于軟件安全性同樣適用。
更具效率的做法是，在產品開發的全生命周期里，直接植入安全最佳實踐，我們把它叫做Build Security In（簡稱BSI）。例如，在分析業務需求的時候，主動去分析安全需求，給用戶故事建立安全驗收標準；在開發過程中時刻關注安全，通過自動化的安全測試持續性的關注產品安全；在測試過程中，不僅測試產品看其是否滿足了業務需求，還基于安全驗收標準設計并執行安全測試用例。
傳統的安全掃描是從后外前推，倒逼著開發團隊做改變，而BSI的做法則是從前往后梳理，融入到日常的開發過程中。正是因為提前并且持續性的關注產品安全，所以在后續的開發中，團隊才會有意識的去做安全防御，使得最后開發出來的軟件默認就已經具備了不錯的安全性，給團隊帶來的沖擊和壓力也是最小的。
邁出改變的第一步
安全掃描已經深深的烙在了很多開發團隊的骨髓里，突然之間要改變這一切勢必不容易，但是我們還是可以做很多嘗試來逐漸改變這個現狀。在這里我推薦一些比較好的切入點，開發團隊可以作為參考，邁出改變的第一步。
每當在創建用戶故事的時候，多問幾個和安全相關的問題，比如：
這個業務需求面臨著哪些威脅？
和這個業務需求相關聯的安全需求是什么？
有沒有什么東西是應該被保護起來的？
應該提前做些什么以應對可能的黑客攻擊？
然后，團隊共同給這個用戶故事設定安全相關的驗收標準。
開發人員在每日代碼審查的時候，多問一下：“這樣設計，或者代碼這么寫，有沒有什么安全風險？安全驗收標準滿足了嗎？”
每當測試人員拿到一張用戶故事對其進行測試的時候，也問問自己：“除了測試產品看其是否正確實現了業務需求之外，還需要基于安全驗收標準設計并執行哪些安全測試用例？”
上面這些提問看似簡單，但是當你在團隊里問出這些問題的時候，你一定會驚訝于它們帶來的影響力。試試唄。
京公網安備 11010502049343號