軟件安全開發主要是從生命周期的角度，對安全設計原則、安全開發方法、最佳實踐和安全專家經驗等進行總結，通過采取各種安全活動來保證盡可能得到安全的軟件。但是，能否將安全開發的概念整合到企業原有的開發過程中，通常取決于企業規模、資源（時間、人才和預算），以及管理層支持等各種因素。如果方式不當，很可能造成高昂的成本甚至整合失敗。

建立軟件安全構建成熟度模型能夠幫助企業理解安全開發舉措的關鍵要素，根據開發團隊的成熟度水平確定各種安全舉措的優先級，從而控制上述因素的影響。

本文介紹了BSIMM、SAMM、SDL優化模型、CMMI+SAFE等四款軟件安全構建成熟度模型，分析了這些模型近年來的演變及其產生的原因。

一、軟件安全構建成熟度模型概述

該部分介紹各軟件安全構建成熟度模型的由來、概念和基本組成。

1、內建安全成熟度模型BSIMM

內建安全成熟度模型（BuildingSecurity In Maturity Model，簡稱BSIMM），是2009年3月正式提出的。BSIMM的核心目的就是對組織所實施的“軟件安全舉措”進行量化。

軟件安全框架(SoftwareSecurity Framework，以下簡稱為SSF)是BSIMM賴以成型的基本結構，如上圖所示，它為各種安全活動提供了一個通用的詞匯表，來解釋”軟件安全舉措”中的主要要素。

從2013年開始，BSIMM經歷了3個版本的變動：2013年10月的BSIMM5、2015年10月的BSIMM6和2016年8月的BSIMM7。在這三個版本的變動中，其基礎的SSF框架并沒有任何的變動。

2、軟件保障成熟度模型SAMM

軟件保障成熟度模型(SoftwareAssurance Maturity Model，簡稱SAMM)是一個開放式的框架，用于幫助組織制定并實施所面臨來自軟件安全的特定風險的策略。在2009年3月發布正式版之后，它成為OWASP的項目之一。

SAMM的框架頂層定義了四種關鍵業務功能，而每種關鍵業務功能下又包含了三類安全措施，共計12種安全措施，如上圖所示。

自2009年SAMM1.0發布之后，SAMM共更新過兩次，分別是2016年3月的SAMM1.1和2017年4月的SAMM1.5。

3、安全開發生命周期SDL優化模型

SDL優化模型圍繞5個功能領域構建，這些領域大致與軟件開發生命周期的各個階段相對應：培訓以及政策、組織功能、要求和設計、實施、驗證、發布和響應。針對這些領域中的實踐和功能，SDL優化模型還定義了四個成熟度水平——基本、標準、高級和動態。其結構如下圖所示。

從SDL優化模型2008年發布以來，它的內容未更新過。而且現在微軟的官方網站上也找不到相關材料，只是在“安全自評估”的頁面中提到：“使用SDL優化模型能夠幫助組織評估產品在開發過程中的安全狀態，隨后組織可以利用SDL優化模型為漸進地、經濟地創建更安全、可靠的軟件提供愿景和實施路線”。

4、CMMI+SAFE

+SAFE模型是由澳大利亞國防部和美國卡內基梅隆大學共同研制開發的，并且針對CMMI開發模型（CMMI-DEV）增加了兩個額外的過程域，涵蓋安全管理和安全工程的內容。

+SAFE旨在識別安全關鍵產品的安全性強項和弱項，并且意圖在產品采購過程的早期識別出的安全漏洞。

從2007年3月發布以來，+SAFE的內容也未更新過。

二、軟件安全構建成熟度模型的演變

本節，我們對近年來模型的演變情況進行分析，因為只有BSIMM和SAMM存在內容的更新，所以主要聚焦在這兩個模型上。

1、BSIMM的演變

（1）模型演變

BSIMM模型基礎框架SSF近年來并沒有變化，而只是對各種安全活動的變更。具體情況如下表：

其中，紫色框表示該活動為該版本BSIMM新增加內容；綠色框表示該活動的成熟度級別進行了上調，即考慮的優先級有較明顯的降低；橙色框表示該活動的成熟度級別進行了下調，即考慮的優先級有較明顯提升。

安全活動增加

從上表中可以看到，在BSIMM5和BSIMM 7中分別新增了一項安全活動，為“運營漏洞獎勵計劃”和“使用應用程序容器”。“運營漏洞獎勵計劃”是為了借助更多的外部技術力量來保障軟件安全，而“使用應用程序容器”則明顯是順應了目前大量使用Docker等容器進行開發的趨勢。

安全活動級別調整

另外，在版本演變的過程中，對部分安全活動的成熟度級別進行了調整。在3次版本更新的所有13項變化中，只有3項的成熟度級別進行了下調，也就是說這3項活動的應用趨勢有較明顯的增加，分別是：“使用自動化工具檢測自定義規則”、“將安全測試包括在QA自動化中”和“執行為應用程序API定制的模糊測試”。

一方面，這三項活動分別屬于“代碼審計”和“安全測試”這兩項安全實踐，且都屬于“SSDL接觸點”這個領域；另一方面，前兩項都與自動化相關，可見安全測試的自動化趨勢愈加明顯。安全測試自動化的需求應主要來自于DevOps；而對應用API進行模糊測試的需求可能來源于大量WebAPI的使用。

（2）數據演變

由于BSIMM是一種觀察模型，所以BSIMM中也包含了觀察到的各種數據。而這些數據的變化，也揭示了一些安全開發的趨勢。

從數據中可以看到，越來越多的垂直行業開始參與到BSIMM的評估中，從最開始的金融服務、軟件開發，到醫療和物聯網，再到云廠商和保險廠商。

加入BSIMM社區的安全人員和開發人員對比的詳細數據如下表所示：

從上表中可以看出，安全人員與開發人員的比例呈現逐步上升的趨勢（從BSIMM4到BSIMM 5的數據下降，是因為BSIMM5引入了數據新鮮度的概念，數據的計算方式有所變化）。

2、SAMM演變

與BSIMM類似，SAMM的整體框架（業務功能、安全實踐）并沒有變化。但是在形式和內容上，進行了大量的豐富和完善。

SAMM1.1的改進

如上圖所示，在SAMM1.1中，原有的SAMM 1.0模型被劃分成了兩部分：操作指南和核心模型。并新增了快速入門指南、工具箱、OWASP資源和SAMM基準。

SAMM1.5的改進

SAMM1.5通過細化評分模型提升了評估的粒度，并在成熟度基準的評估中允許部分評分。現在，組織將獲得在安全實踐中完成的所有相關工作的評分，而不是將分數保持在最高的成熟度水平。

同時，SAMM1.5通過工作表和指南中的典型案例，幫助組織在理解自身安全狀況定位的同時，也知道類似情況下哪些工作對于別人是有效的。

從兩次SAMM的演變情況中，可以看出SAMM對于評估的可操作性和實用性進行了較大的改進。不難看出，在企業對軟件安全構建成熟度模型一無所知的情況下，如果想對開發安全狀況進行自評估、了解下一步的改進方向，那么SAMM無疑是成本最小、最便捷的方式。

三、分析及展望

通過上述分析可以得出以下結論：

l 軟件安全成熟度模型，仍然以大量安全實踐和統計數據為基礎。本文中分析的軟件安全成熟度模型，近年來并沒有發生大的變動。自2013年來，這四個模型的基礎框架都未發生變化，仍然是以安全實踐和安全活動為主，并未引入新的理論依據。

l 安全構建成熟度模型會根據軟件開發技術的發展而演變。BSIMM新增的安全活動“使用應用程序容器”，以及對“使用自動化工具檢測自定義規則”、“將安全測試包括在QA自動化中”和“執行為應用程序API而定制的模糊測試”的級別調整，都揭示了容器、DevOps、WebAPI等對成熟度模型的影響。

l 安全測試的工具化、自動化，是未來的發展趨勢。為了順應現代軟件開發部署的快節奏，軟件安全測試的工具化、自動化將勢不可擋。例如SAMM的工具化、實用化演變，SDL威脅建模工具、靜態分析工具、二進制驗證工具的持續更新，BSIMM中“使用自動化工具檢測自定義規則”、“將安全測試包括在QA自動化中”這種自動化安全活動的興起，都證實了這一點。

l 軟件安全將受到越來越多的關注與重視。從BSIMM的數據演變中可以發現，無論是加入軟件評估的企業數目，還是各企業內專業從事軟件安全的人員比例，都呈現逐步上升的趨勢。

對于軟件開發安全的未來趨勢，我們認為：隨著DevOps、微服務等軟件開發技術的發展，傳統軟件安全的形態不斷發生著演變。很多測試、評估的技術路線都在持續地演進，但是自動化、高速、與傳統開發流程進行融合的趨勢將愈發明顯。工具化、自動化的安全測試將會成為各家公司保障軟件安全的基礎舉措，而安全從業人員能夠將更多精力投入到過程的改進與管理中。根據目前各軟件安全構建成熟度模型的情況，我們也給出如下建議：

l 對于依托互聯網、云服務等技術演變迅速的高科技公司，應盡可能避免使用SDL優化模型、CMMI+SAFE模型，因為其內容已經較長時間沒有更新，可能有些細節已經無法與現階段的開發過程或技術相匹配；

l 對于資源相對充足、安全關鍵的大型機構，可以采用BSIMM模型來指導安全開發體系的建設，同時引入專業的安全開發咨詢服務，來盡可能保證企業始終處于較高的安全水平；

l 對于資源有限的中小型公司或創業公司，可以考慮引入SAMM模型，從而在控制成本的同時，盡快提升整體的軟件安全水平。