微軟自2004年就採用SDL（Security Development Lifecycle），即安全開發生命週期。後面很多安全企業提出S-SDLC（Secure Software Development Lifecycle）。這個概念也是被安全行業的公益組織OWASP所支持。安全中的SDLC就是指將原來集中在軟件開發生命週期後期進行的工作，放到軟件開發生命週期各個階段去，在每個階段做安全該做能做的事，我想這就是軟件內生安全的一部分。所以，我還是借用軟件測試行業那句傳統話：軟件質量是開發出來的，而不是測試出來的。軟件測試工作本身就是軟件開發過程工作的一部分，而不是決然分開的一個過程。
下面我們看一下SDL安全開發生命週期圖：
在第二階段需求這一列中，強調了確定安全需求。需要有專職安全團隊成員參與系統安全分析和需求梳理出；開發團隊和安全團隊識別軟件中關鍵的安全風險，包括軟件必須遵循的標準，例如組織和法律、法規等；確保開發團隊和安全團隊之間的溝通通暢；消除團隊之間的差異，取得共識。
質量門的建立即堅持最低級別的安全可接受指標。例如，可以要求具有中等級別以上的安全漏洞的軟件不能投入生產或進入下一個研發階段。標記中、高風險漏洞的任何代碼都應返回給開發團隊進行修復。一旦建立了質量門，也就是建立了一個質量制度或代碼質量標準，無論應用系統發佈的進程如何緊急，永遠不允許含有中高風險漏洞的軟件投入生產。您可以有理由說服你的上級和老闆，確保通過質量門限後，才能進入下一個階段。
只有質量門建立後，下一步才能分析開發軟件系統的攻擊面。進出軟件的所有命令和數據以及軟件中需要保護的有價值數據。當然您可以採用微軟的邁克爾霍華德設計的相對攻擊面商數方法或採用卡內基梅隆的攻擊面度量方法進行攻擊面分析，確定代碼中最關鍵和最易受攻擊的區域，確保在開發和測試期間關注這些攻擊面。
在攻擊面分析完成後，進行威脅建模，威脅建模可以幫助開發人員瞭解應用程序需要哪些安全控制，從開始就構建安全性。通過建模過程，掌握需要保護哪些資產和資源，獲得這些資產和資源的入口和接入點，建立威脅優先級矩陣併爲每一個威脅制定緩解措施。
不管是進行攻擊面分析還是威脅建模，都是以建立的質量門，當然也可以稱之爲安全門爲基礎。建立Devops或DevSecOps也必然有這個環節。建立安全門，是需要安全人員具有建立安全編碼規範的能力，代碼安全漏洞識別能力以及缺陷識別能力，而傳統的安全人員大多側重於應用安全級別上的能力，建立質量門需要安全人員、測試人員、開發人員等的合作，才能建立起切實可行的質量門。但是現在有一種更簡單、更高效的方法，基於SAST技術的代碼安全檢測工具，都內置了大量的安全檢測器，包括了安全編碼規範、運行時缺陷和安全漏洞的規則檢查器，企業可以在工具本身提供的全量檢測器的基礎上，定製出自己的檢測器集合，這個檢測器集合就可以確定爲安全門或質量門。當然有些企業有一些特定的安全檢測要求，可以在工具中增加定製這些規則，就真正打造出適合企業自己的質量門。而通過自動化的檢測工具，不但高效，而且客觀、公正的保證質量門的落地性，對任何一個團隊或開發人員都是公平的，你的代碼跨越不了質量門，你就不能提交到SVN或Git，無法與團隊的代碼進行集成。
雖然國內外有很多此類工具，但是國內真正自主、可控的檢測工具相對較少，例如北大軟件的CoBOT，可以說是國內最成熟、自主、可控，具有專利技術的代碼安全檢測工具，是企業正值做國產化替換的首選工具。
-------------------------------------------------------------
關注安全 關注作者