3.7.2　SDL落地率低的原因

1. DevOps的交付模式

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

2. 歷史問題

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

3. 業(yè)務(wù)模式

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

4. SDL的門檻

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。