3.7.2　SDL落地率低的原因

1. DevOps的交付模式

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

2. 歷史問題

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

3. 業務模式

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

4. SDL的門檻

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

總結

以上是生活随笔為你收集整理的互联网企业安全高级指南3.7.2　SDL落地率低的原因的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。