當下，軟件開發安全的理念很火，各行各業都已認識到保障應用系統開發安全的重要性，但是要真正實現起來，結果卻不是那么理想。開發安全難深入、難落地已成為常態。

很多時候，盡管你工作很努力，但就是難以進步，主要原因并不是任務多困難，而是有一些根深蒂固的錯誤觀念一直在阻礙、限制你。目前軟件開發安全技術領域中，這樣根深蒂固的錯誤觀點還不少，需要大家共同努力，把這些觀念找出來，糾正過來，開發安全的應用發展才會更加穩健。

在近8年時間里，筆者親身參與了幾十家企業組織的開發安全應用實踐，其中也走了很多彎路，踩過很多深坑。在本文中，簡單總結了筆者在應用實踐中發現的開發安全常見認知誤區，希望能夠幫助讀者在未來開展開發安全實踐時少走彎路。

誤區1.開發安全不就是應用上線前的安全性測試嗎？

開發安全工作的實現不僅僅依賴于上線前安全測試，正如質量界的一句名言，“質量是建設出來，不是管理出來的”，開發安全的質量同樣如此，建設好的開發安全，應該在三方面下功夫，如下圖：

不考慮“規矩”——管理體系的建立，不考慮“能力”的建設，只強調上線前的檢測，不能從根本上解決問題。

誤區2.開發安全就是做好源代碼審計

源代碼審計確實是開發安全中很重要的一環，畢竟軟件開發項目的本質交付物就是源代碼，但開發安全涵蓋的內容遠遠大于源代碼審計。

開發安全區別于我們常規信息安全工作有兩個關鍵點：

（1）開發安全是威脅驅動而不是評估驅動。

傳統信息安全通常都是評估驅動：安全團隊去做一個風險評估，發現系統的脆弱性，然后有后續的安全整改、復測等等。但開發安全是在系統還沒有建好，甚至還沒有建開始的，它只能從系統建成后將面臨什么風險開始，然后才有后續的安全工作，如降低攻擊面、安全編碼、安全驗證等。

（2）開發安全中，安全是需求而非BUG

傳統信息安全工作中，發現漏洞基本都是當bug流程來處理，bug處理一般是沒有預算（包括資源預算和時間預算）的，這當然會造成開發團隊和安全團隊的對立，真實安全開發需要的資源并不少，只有當需求處理能保證合理的資源，才能保證開發安全活動的順利進行。

顯然，開發安全中，安全需求分析的重要性就遠遠大于源代碼審計，依賴源代碼審計只是安全評估的一環，更何況當下的源代碼審計工具還有種種不足，是不能單一方式來滿足開發安全要求的。

誤區3、應用SDL就可以實現開發安全

SDL是由微軟公司提出的從安全角度規范、指導軟件系統開發流程的管理模式，在國內開發安全應用領域有較大的影響力，甚至一些機構和企業會將SDL錯誤理解成開發安全。但實際上，很多企業實際應用的安全開發管理流程并不是SDL，而是融合SDL、BSI（Building Security IN）、SAMM（Software Assurance Maturity Mode）、CLASP（Comprehensive, Lightweight Application Security Process）等在內的綜合開發安全模式。在筆者的親身實踐中發現，SDL管理理念不太容易落地，按照微軟SDL，先進行威脅建模，然后用STRIDE模型分析安全需求。采用這種方式，盡管看起來不復雜，但實際執行時卻有很多挑戰，開發人員要找到所有的數據交互，才能進行完整的威脅建模。而對于應用系統開發，一些數據交互是完全想不到的。比如java反序列化漏洞，發生威脅時的數據流是客戶端瀏覽器發請求給WEB中間件，應用程序還沒介入，對于應用開發來說，要怎么威脅建模，怎么STRIDE才能排除這個風險？所以這種方式的成本高得離譜，需要大量人員進行支撐。這也是SDL模型在國內實際軟件開發工作中較少應用的原因。

在實踐中，筆者一直倡議安全需求庫法，就是按照經驗、合規要求，建立起基礎的安全需求庫，針對具體項目具體分析，建立具體安全需求。采用這種方法，雖然理論上無法保證安全需求的完備性，但在可操作層面，實際應用成本會得到很大優化。

誤區4.提出安全問題和解決問題都是安全團隊的事

這個誤區的本質是軟件開發安全的分工與合作問題，安全團隊在開發過程中的能力在于安全知識豐富，但職權有限，對開發過程介入的環節少，因此無法解決所有存在的安全問題。

如果使用一個不合理的分工原則，最終導致的結果就是難以落地的。在當下通常的軟件開發過程中，業務團隊決定功能，開發團隊決定代碼，運維團隊可以負責服務器，而安全團隊的職責呢？

所以，在項目開發的權力鏈中，業務>開發>運維>安全。綜合考慮能力和權力，比較合理的分工建議如下：

誤區5.開發團隊負責架構設計，安全團隊負責安全設計

如果一個機構將安全設計交給安全團隊，這個機構的開發安全工作一定很難真正落地，因為安全團隊是不可能做好安全設計的。因為設計本身就是要在功能與性能、用戶體驗、安全等因素綜合影響下的一個平衡考慮，必須由開發團隊去進行綜合的取舍，統一設計。

為什么明明設計工作不適合安全團隊，還會出現由安全團隊來負責安全設計呢？在這里可能出現了一個假的“安全設計”，這個“安全設計”其實是一個安全需求，比如參照等保三級的“安全設計”，就是提出滿足等保三級要求的一些安全需求。

可以簡單對比一下兩種安全設計。

通過對比，大家能理解真正的安全設計是什么，它是設計在安全方面的體現，是針對一個設計的安全說明。所以，安全團隊是不適合負責安全設計的，最多可以協助安全設計。那讓安全團隊做一個假的“安全設計”也不行嗎？這個“安全設計”頂著安全設計的帽子，真實的安全設計就會缺失，安全設計的管控就更不可能了。

誤區6.開發安全應用太虛，沒法實際落地

軟件開發安全是開發項目管理的一個部分，跟開發一樣是無法完美的，所以開發的管理有CMMI，成熟度模型，開發安全也有開發安全的成熟度模型。實施開發安全管理會很大層面改變開發團隊的安全動作和安全習慣，安全意識的提高也毋庸置疑，肯定會對項目成功發揮極大作用。

但客觀上，在開發安全動作中有形式主義的部分，就跟開發管理這么多年仍然是一邊編碼、一邊設計評審一樣，沒有做到100%，既不能算虛，也不能算理想的落地。

從最終效果來說，做了開發安全的項目也不能保證100%的安全。安全的應用效果最終還是依靠投入來保證的，現在的開發安全都是追求有限投入下的最好結果，從來不追求100%的安全，所以也不能從這個結果來評估價值。

如果一方面用一個極高的標準來要求開發過程中的安全工作，另一方面又不認可開發安全的投入價值，那么這種觀點顯然是不準確的，不利于應用安全的長期發展。

誤區7.源代碼審計的用處不大

當前源代碼審計工具確實存在一些不如人意地方，一方面審計報告給出的漏洞數量會很多，另一方面存在大量無法直接利用的漏洞被當做高危/嚴重漏洞報出，導致源代碼審計產品的實用價值面臨挑戰。此外，還有一些非常常見且重要的邏輯類漏洞，如：甲可以查乙的交易記錄（橫向越權/數據越權漏洞）等，通用源代碼審計工具也難以發揮作用。

雖然存在不足，但并不能否認源代碼審計的價值。一方面源代碼審計能夠發現很多重要的代碼缺陷；另一方面，源代碼審計也能大幅加強開發團隊的安全意識，具備重要價值。

同時，源代碼工具的不足，可以隨著時間的深入，團隊熟悉，得到相當的控制，有些機構具備源代碼審計工具的高級運營能力，通過不斷調優規則，減少源代碼審計工具的報告漏洞數量，建立黑白名單機制，減少必須整改的漏洞數量，大幅提升源代碼審計工具的可用性。

總之，源代碼審計工具有不足，但仍然是很重要的開發安全輔助工具。

誤區8.做好開發安全必須依靠工具

軟件工程從來不是完全依靠工具發展的，現在CMMI軟件成熟度即便是5級，里面對工具的依賴度也是有限的，開發安全更不能僅靠工具。“開發安全必須靠工具”這一說法來源于兩個原因：一、不愿意在開發安全方面投入資源，在這種情況下只能靠工具了；二、錯誤理解開發安全，還是把開發安全理解為漏洞管理，而人工檢測漏洞成本太高，就只能靠工具了。

誤區9.IAST可以有效避免誤報

交互式應用安全測試（Interactive application security testing IAST）的核心技術是插樁（Instrumented），就是利用WEB中間件，接觸到運行代碼，可以對運行代碼進行審計，也可以在運行代碼中插入收集數據流的代碼，實現對運行的數據流檢測。IAST可以持續地從內部監控你應用中的代碼和數據流，發現應用中存在的漏洞。

顯然IAST對比DAST獲得信息更多，具備漏洞報告更加精準的可能性。但一個檢測工具有沒有誤報，取決于檢測策略，如果應用的檢測策略是寧缺勿濫，自然準確率高，但漏報率也高；如果檢測策略是寧濫勿缺，自然漏報率低，但準確率自然也低。

早期IAST產品只需要檢測較少漏洞，因此漏報率高，準確率很高；但現在國內IAST產品發展的方向是檢測漏洞種類越來越多、越來越復雜，很多漏洞種類不是IAST擅長的，導致現在IAST誤報率也比較高，實用性反而變差。

誤區10.軟件供應鏈安全就是SCA

供應鏈安全是一個大課題，必須從國家、行業角度來徹底解決，一個機構能做的非常有限。軟件供應鏈復雜程度甚至超過硬件，各種開源軟件的應用是導致軟件供應鏈復雜的重要原因之一。但目前很多廠商提到軟件供應鏈安全就會推薦軟件成分分析系統（SCA software composition analysis），讓一些用戶將軟件供應鏈安全誤解為SCA。

SCA工具功能分成三個部分：

• 分析軟件結構，判斷包含哪些開源組件，形成一份軟件結構清單，列出軟件包含的所有開源組件。
• 根據開源組件清單，根據CVE、CNVD、CNNVD等各種漏洞庫，判斷開源組件包含的漏洞情況。
• 根據開源組件清單，根據其許可協議，判斷開源組件的許可協議方面的風險。

顯然SCA系統只解決軟件供應鏈環節中一個環節問題，就是在上線前檢測軟件包含的開源軟件組件，并根據組件信息分析漏洞和許可協議風險。對比軟件供應鏈的主要威脅：惡意篡改、假冒偽劣、供應中斷、信息泄露、違規操作以及其他威脅等，能解決的問題實在有限。