網際網路企業安全進階指南3.7.2 SDL落地率低的原因

<b>3.7.2　sdl落地率低的原因</b>

<b></b>

<b>1. devops的傳遞模式</b>

網際網路頻繁的疊代和釋出，不同于傳統的軟體開發過程。如果一個軟體要一年傳遞，那麼在前期抽出2～4周做安全設計也可以接受，但在網際網路傳遞節奏下，可能一周到一個月就要釋出版本，你可能沒有足夠的時間去思考安全這件事。對于sdl會拖慢整個釋出節奏這個問題上，安全團隊去推動也會直面公司管理層和研發線的挑戰。不過當你有經驗豐富的安全人員和自動化工具支援時，sdl在時間上是可以大大縮短的。

<b>2. 曆史問題</b>

99%的甲方安全團隊的工作都是以救火方式開始，sdl從來都不是安全建設第一個會想到的事情，而且業内心照不宣的一個原因是，“事前用不上力，偏事後風格的安全建設”貫穿于大多數安全團隊的主線。之是以如此，原因是第一有火必救，有的團隊救火上瘾，有的則能抽身轉向系統性建設；第二想在事前用力，需要自己足夠強大，能擺平研發，不夠強大就會變成庸人自擾，自讨沒趣，還不如回避。

<b>3. 業務模式</b>

大多數平台級網際網路公司的開發以web為主，超大型網際網路公司才會進入底層架構造輪子的階段，而對于以web産品為主的安全建設，第一是事後修補的成本比較低，屢試不爽；第二是部分産品的生命周期不長，這兩點一定程度上會讓很多後加入安全行業的新同學認為“救火”=“安全建設”。但是在甲方待久了的人一定會發現，哪怕是web，隻要系統比較大，層層嵌套和不同子系統間的接口調用，會使得某些安全問題的修補成為疑難病症，可能就是設計之初沒有考慮安全，緻使問題不能得到根治。時間一久，技術債越積越多，大家最後一緻預設這個問題沒法解決。

<b>4. sdl的門檻</b>

其實sdl是有門檻的，而且還不低。最重要有兩點：第一點是安全專家少，很多安全工作者懂攻防但未必懂開發，懂漏洞但未必懂設計，是以現實往往是很多安全團隊能指導研發部門修複漏洞，但可能沒意識到其實缺少指導安全設計的積累，因為安全設計是一件比漏洞修複門檻更高的事。看業内很多技術不錯的安全研究者，寫的文章，往往前半篇漏洞分析很給力，但到了安全建議環節好像就覺得少了點什麼。第二點是工具支援少，靜态代碼掃描、動态fuzz等，工欲善其事必先利其器，facebook宣稱其最好的程式員是投入到工具開發的，而對于國内很多安全團隊而言，最好的人都不會用在工具開發上，而是奮鬥在攻防第一線做救火隊長。稍微好一點的情況是這幫人投入在做安全機制建設上，而業務部門也不會來幫助安全團隊開發安全工具。這還跟公司整體上是否重視自動化測試有關，如果公司在測試領域的實踐沒有做到很前沿，那麼安全的黑白盒測試也不會注重工具化建設，代碼覆寫率和路徑深度等更加不會有人去關注了。實際上不一定要在這個場景下自己去造輪子，用商業工具是不錯的選擇。