本文來自微信公眾號(hào)“安全牛”，作者/國舜股份 湯志剛。
當(dāng)下，軟件開發(fā)安全的理念很火，各行各業(yè)都已認(rèn)識(shí)到保障應(yīng)用系統(tǒng)開發(fā)安全的重要性，但是要真正實(shí)現(xiàn)起來，結(jié)果卻不是那么理想。開發(fā)安全難深入、難落地已成為常態(tài)。
很多時(shí)候，盡管你工作很努力，但就是難以進(jìn)步，主要原因并不是任務(wù)多困難，而是有一些根深蒂固的錯(cuò)誤觀念一直在阻礙、限制你。目前軟件開發(fā)安全技術(shù)領(lǐng)域中，這樣根深蒂固的錯(cuò)誤觀點(diǎn)還不少，需要大家共同努力，把這些觀念找出來，糾正過來，開發(fā)安全的應(yīng)用發(fā)展才會(huì)更加穩(wěn)健。
在近8年時(shí)間里，筆者親身參與了幾十家企業(yè)組織的開發(fā)安全應(yīng)用實(shí)踐，其中也走了很多彎路，踩過很多深坑。在本文中，簡單總結(jié)了筆者在應(yīng)用實(shí)踐中發(fā)現(xiàn)的開發(fā)安全常見認(rèn)知誤區(qū)，希望能夠幫助讀者在未來開展開發(fā)安全實(shí)踐時(shí)少走彎路。
誤區(qū)1.開發(fā)安全不就是應(yīng)用上線前的安全性測試嗎？
開發(fā)安全工作的實(shí)現(xiàn)不僅僅依賴于上線前安全測試，正如質(zhì)量界的一句名言，“質(zhì)量是建設(shè)出來，不是管理出來的”，開發(fā)安全的質(zhì)量同樣如此，建設(shè)好的開發(fā)安全，應(yīng)該在三方面下功夫，如下圖：
不考慮“規(guī)矩”——管理體系的建立，不考慮“能力”的建設(shè)，只強(qiáng)調(diào)上線前的檢測，不能從根本上解決問題。
誤區(qū)2.開發(fā)安全就是做好源代碼審計(jì)
源代碼審計(jì)確實(shí)是開發(fā)安全中很重要的一環(huán)，畢竟軟件開發(fā)項(xiàng)目的本質(zhì)交付物就是源代碼，但開發(fā)安全涵蓋的內(nèi)容遠(yuǎn)遠(yuǎn)大于源代碼審計(jì)。
開發(fā)安全區(qū)別于我們常規(guī)信息安全工作有兩個(gè)關(guān)鍵點(diǎn)：
（1）開發(fā)安全是威脅驅(qū)動(dòng)而不是評(píng)估驅(qū)動(dòng)。
傳統(tǒng)信息安全通常都是評(píng)估驅(qū)動(dòng)：安全團(tuán)隊(duì)去做一個(gè)風(fēng)險(xiǎn)評(píng)估，發(fā)現(xiàn)系統(tǒng)的脆弱性，然后有后續(xù)的安全整改、復(fù)測等等。但開發(fā)安全是在系統(tǒng)還沒有建好，甚至還沒有建開始的，它只能從系統(tǒng)建成后將面臨什么風(fēng)險(xiǎn)開始，然后才有后續(xù)的安全工作，如降低攻擊面、安全編碼、安全驗(yàn)證等。
（2）開發(fā)安全中，安全是需求而非BUG
傳統(tǒng)信息安全工作中，發(fā)現(xiàn)漏洞基本都是當(dāng)bug流程來處理，bug處理一般是沒有預(yù)算（包括資源預(yù)算和時(shí)間預(yù)算）的，這當(dāng)然會(huì)造成開發(fā)團(tuán)隊(duì)和安全團(tuán)隊(duì)的對(duì)立，真實(shí)安全開發(fā)需要的資源并不少，只有當(dāng)需求處理能保證合理的資源，才能保證開發(fā)安全活動(dòng)的順利進(jìn)行。
顯然，開發(fā)安全中，安全需求分析的重要性就遠(yuǎn)遠(yuǎn)大于源代碼審計(jì)，依賴源代碼審計(jì)只是安全評(píng)估的一環(huán)，更何況當(dāng)下的源代碼審計(jì)工具還有種種不足，是不能單一方式來滿足開發(fā)安全要求的。
誤區(qū)3、應(yīng)用SDL就可以實(shí)現(xiàn)開發(fā)安全
SDL是由微軟公司提出的從安全角度規(guī)范、指導(dǎo)軟件系統(tǒng)開發(fā)流程的管理模式，在國內(nèi)開發(fā)安全應(yīng)用領(lǐng)域有較大的影響力，甚至一些機(jī)構(gòu)和企業(yè)會(huì)將SDL錯(cuò)誤理解成開發(fā)安全。但實(shí)際上，很多企業(yè)實(shí)際應(yīng)用的安全開發(fā)管理流程并不是SDL，而是融合SDL、BSI（Building Security IN）、SAMM（Software Assurance Maturity Mode）、CLASP（Comprehensive,Lightweight Application Security Process）等在內(nèi)的綜合開發(fā)安全模式。在筆者的親身實(shí)踐中發(fā)現(xiàn)，SDL管理理念不太容易落地，按照微軟SDL，先進(jìn)行威脅建模，然后用STRIDE模型分析安全需求。采用這種方式，盡管看起來不復(fù)雜，但實(shí)際執(zhí)行時(shí)卻有很多挑戰(zhàn)，開發(fā)人員要找到所有的數(shù)據(jù)交互，才能進(jìn)行完整的威脅建模。而對(duì)于應(yīng)用系統(tǒng)開發(fā)，一些數(shù)據(jù)交互是完全想不到的。比如java反序列化漏洞，發(fā)生威脅時(shí)的數(shù)據(jù)流是客戶端瀏覽器發(fā)請(qǐng)求給WEB中間件，應(yīng)用程序還沒介入，對(duì)于應(yīng)用開發(fā)來說，要怎么威脅建模，怎么STRIDE才能排除這個(gè)風(fēng)險(xiǎn)？所以這種方式的成本高得離譜，需要大量人員進(jìn)行支撐。這也是SDL模型在國內(nèi)實(shí)際軟件開發(fā)工作中較少應(yīng)用的原因。
在實(shí)踐中，筆者一直倡議安全需求庫法，就是按照經(jīng)驗(yàn)、合規(guī)要求，建立起基礎(chǔ)的安全需求庫，針對(duì)具體項(xiàng)目具體分析，建立具體安全需求。采用這種方法，雖然理論上無法保證安全需求的完備性，但在可操作層面，實(shí)際應(yīng)用成本會(huì)得到很大優(yōu)化。
誤區(qū)4.提出安全問題和解決問題都是安全團(tuán)隊(duì)的事
這個(gè)誤區(qū)的本質(zhì)是軟件開發(fā)安全的分工與合作問題，安全團(tuán)隊(duì)在開發(fā)過程中的能力在于安全知識(shí)豐富，但職權(quán)有限，對(duì)開發(fā)過程介入的環(huán)節(jié)少，因此無法解決所有存在的安全問題。
如果使用一個(gè)不合理的分工原則，最終導(dǎo)致的結(jié)果就是難以落地的。在當(dāng)下通常的軟件開發(fā)過程中，業(yè)務(wù)團(tuán)隊(duì)決定功能，開發(fā)團(tuán)隊(duì)決定代碼，運(yùn)維團(tuán)隊(duì)可以負(fù)責(zé)服務(wù)器，而安全團(tuán)隊(duì)的職責(zé)呢？
所以，在項(xiàng)目開發(fā)的權(quán)力鏈中，業(yè)務(wù)＞開發(fā)＞運(yùn)維＞安全。綜合考慮能力和權(quán)力，比較合理的分工建議如下：
誤區(qū)5.開發(fā)團(tuán)隊(duì)負(fù)責(zé)架構(gòu)設(shè)計(jì)，安全團(tuán)隊(duì)負(fù)責(zé)安全設(shè)計(jì)
如果一個(gè)機(jī)構(gòu)將安全設(shè)計(jì)交給安全團(tuán)隊(duì)，這個(gè)機(jī)構(gòu)的開發(fā)安全工作一定很難真正落地，因?yàn)榘踩珗F(tuán)隊(duì)是不可能做好安全設(shè)計(jì)的。因?yàn)樵O(shè)計(jì)本身就是要在功能與性能、用戶體驗(yàn)、安全等因素綜合影響下的一個(gè)平衡考慮，必須由開發(fā)團(tuán)隊(duì)去進(jìn)行綜合的取舍，統(tǒng)一設(shè)計(jì)。
為什么明明設(shè)計(jì)工作不適合安全團(tuán)隊(duì)，還會(huì)出現(xiàn)由安全團(tuán)隊(duì)來負(fù)責(zé)安全設(shè)計(jì)呢？在這里可能出現(xiàn)了一個(gè)假的“安全設(shè)計(jì)”，這個(gè)“安全設(shè)計(jì)”其實(shí)是一個(gè)安全需求，比如參照等保三級(jí)的“安全設(shè)計(jì)”，就是提出滿足等保三級(jí)要求的一些安全需求。
可以簡單對(duì)比一下兩種安全設(shè)計(jì)。
通過對(duì)比，大家能理解真正的安全設(shè)計(jì)是什么，它是設(shè)計(jì)在安全方面的體現(xiàn)，是針對(duì)一個(gè)設(shè)計(jì)的安全說明。所以，安全團(tuán)隊(duì)是不適合負(fù)責(zé)安全設(shè)計(jì)的，最多可以協(xié)助安全設(shè)計(jì)。那讓安全團(tuán)隊(duì)做一個(gè)假的“安全設(shè)計(jì)”也不行嗎？這個(gè)“安全設(shè)計(jì)”頂著安全設(shè)計(jì)的帽子，真實(shí)的安全設(shè)計(jì)就會(huì)缺失，安全設(shè)計(jì)的管控就更不可能了。
誤區(qū)6.開發(fā)安全應(yīng)用太虛，沒法實(shí)際落地
軟件開發(fā)安全是開發(fā)項(xiàng)目管理的一個(gè)部分，跟開發(fā)一樣是無法完美的，所以開發(fā)的管理有CMMI，成熟度模型，開發(fā)安全也有開發(fā)安全的成熟度模型。實(shí)施開發(fā)安全管理會(huì)很大層面改變開發(fā)團(tuán)隊(duì)的安全動(dòng)作和安全習(xí)慣，安全意識(shí)的提高也毋庸置疑，肯定會(huì)對(duì)項(xiàng)目成功發(fā)揮極大作用。
但客觀上，在開發(fā)安全動(dòng)作中有形式主義的部分，就跟開發(fā)管理這么多年仍然是一邊編碼、一邊設(shè)計(jì)評(píng)審一樣，沒有做到100%，既不能算虛，也不能算理想的落地。
從最終效果來說，做了開發(fā)安全的項(xiàng)目也不能保證100%的安全。安全的應(yīng)用效果最終還是依靠投入來保證的，現(xiàn)在的開發(fā)安全都是追求有限投入下的最好結(jié)果，從來不追求100%的安全，所以也不能從這個(gè)結(jié)果來評(píng)估價(jià)值。
如果一方面用一個(gè)極高的標(biāo)準(zhǔn)來要求開發(fā)過程中的安全工作，另一方面又不認(rèn)可開發(fā)安全的投入價(jià)值，那么這種觀點(diǎn)顯然是不準(zhǔn)確的，不利于應(yīng)用安全的長期發(fā)展。
誤區(qū)7.源代碼審計(jì)的用處不大
當(dāng)前源代碼審計(jì)工具確實(shí)存在一些不如人意地方，一方面審計(jì)報(bào)告給出的漏洞數(shù)量會(huì)很多，另一方面存在大量無法直接利用的漏洞被當(dāng)做高危/嚴(yán)重漏洞報(bào)出，導(dǎo)致源代碼審計(jì)產(chǎn)品的實(shí)用價(jià)值面臨挑戰(zhàn)。此外，還有一些非常常見且重要的邏輯類漏洞，如：甲可以查乙的交易記錄（橫向越權(quán)/數(shù)據(jù)越權(quán)漏洞）等，通用源代碼審計(jì)工具也難以發(fā)揮作用。
雖然存在不足，但并不能否認(rèn)源代碼審計(jì)的價(jià)值。一方面源代碼審計(jì)能夠發(fā)現(xiàn)很多重要的代碼缺陷；另一方面，源代碼審計(jì)也能大幅加強(qiáng)開發(fā)團(tuán)隊(duì)的安全意識(shí)，具備重要價(jià)值。
同時(shí)，源代碼工具的不足，可以隨著時(shí)間的深入，團(tuán)隊(duì)熟悉，得到相當(dāng)?shù)目刂?，有些機(jī)構(gòu)具備源代碼審計(jì)工具的高級(jí)運(yùn)營能力，通過不斷調(diào)優(yōu)規(guī)則，減少源代碼審計(jì)工具的報(bào)告漏洞數(shù)量，建立黑白名單機(jī)制，減少必須整改的漏洞數(shù)量，大幅提升源代碼審計(jì)工具的可用性。
總之，源代碼審計(jì)工具有不足，但仍然是很重要的開發(fā)安全輔助工具。
誤區(qū)8.做好開發(fā)安全必須依靠工具
軟件工程從來不是完全依靠工具發(fā)展的，現(xiàn)在CMMI軟件成熟度即便是5級(jí)，里面對(duì)工具的依賴度也是有限的，開發(fā)安全更不能僅靠工具。“開發(fā)安全必須靠工具”這一說法來源于兩個(gè)原因：一、不愿意在開發(fā)安全方面投入資源，在這種情況下只能靠工具了；二、錯(cuò)誤理解開發(fā)安全，還是把開發(fā)安全理解為漏洞管理，而人工檢測漏洞成本太高，就只能靠工具了。
誤區(qū)9.IAST可以有效避免誤報(bào)
交互式應(yīng)用安全測試（Interactive application security testing IAST）的核心技術(shù)是插樁（Instrumented），就是利用WEB中間件，接觸到運(yùn)行代碼，可以對(duì)運(yùn)行代碼進(jìn)行審計(jì)，也可以在運(yùn)行代碼中插入收集數(shù)據(jù)流的代碼，實(shí)現(xiàn)對(duì)運(yùn)行的數(shù)據(jù)流檢測。IAST可以持續(xù)地從內(nèi)部監(jiān)控你應(yīng)用中的代碼和數(shù)據(jù)流，發(fā)現(xiàn)應(yīng)用中存在的漏洞。
顯然IAST對(duì)比DAST獲得信息更多，具備漏洞報(bào)告更加精準(zhǔn)的可能性。但一個(gè)檢測工具有沒有誤報(bào)，取決于檢測策略，如果應(yīng)用的檢測策略是寧缺勿濫，自然準(zhǔn)確率高，但漏報(bào)率也高；如果檢測策略是寧濫勿缺，自然漏報(bào)率低，但準(zhǔn)確率自然也低。
早期IAST產(chǎn)品只需要檢測較少漏洞，因此漏報(bào)率高，準(zhǔn)確率很高；但現(xiàn)在國內(nèi)IAST產(chǎn)品發(fā)展的方向是檢測漏洞種類越來越多、越來越復(fù)雜，很多漏洞種類不是IAST擅長的，導(dǎo)致現(xiàn)在IAST誤報(bào)率也比較高，實(shí)用性反而變差。
誤區(qū)10.軟件供應(yīng)鏈安全就是SCA
供應(yīng)鏈安全是一個(gè)大課題，必須從國家、行業(yè)角度來徹底解決，一個(gè)機(jī)構(gòu)能做的非常有限。軟件供應(yīng)鏈復(fù)雜程度甚至超過硬件，各種開源軟件的應(yīng)用是導(dǎo)致軟件供應(yīng)鏈復(fù)雜的重要原因之一。但目前很多廠商提到軟件供應(yīng)鏈安全就會(huì)推薦軟件成分分析系統(tǒng)（SCA software composition analysis），讓一些用戶將軟件供應(yīng)鏈安全誤解為SCA。
SCA工具功能分成三個(gè)部分：
分析軟件結(jié)構(gòu)，判斷包含哪些開源組件，形成一份軟件結(jié)構(gòu)清單，列出軟件包含的所有開源組件。
根據(jù)開源組件清單，根據(jù)CVE、CNVD、CNNVD等各種漏洞庫，判斷開源組件包含的漏洞情況。
根據(jù)開源組件清單，根據(jù)其許可協(xié)議，判斷開源組件的許可協(xié)議方面的風(fēng)險(xiǎn)。
顯然SCA系統(tǒng)只解決軟件供應(yīng)鏈環(huán)節(jié)中一個(gè)環(huán)節(jié)問題，就是在上線前檢測軟件包含的開源軟件組件，并根據(jù)組件信息分析漏洞和許可協(xié)議風(fēng)險(xiǎn)。對(duì)比軟件供應(yīng)鏈的主要威脅：惡意篡改、假冒偽劣、供應(yīng)中斷、信息泄露、違規(guī)操作以及其他威脅等，能解決的問題實(shí)在有限。
