一、SDL簡介

SDL security development lifecycle（安全開發(fā)生命周期），是微軟提出的從安全角度指導軟件開發(fā)過程的管理模式。SDL是一個安全保證的過程，起重點是軟件開發(fā)，它在開發(fā)的所有階段都引入了安全和隱私的原則。自2004年起，SDL一直都是微軟在全公司實施的強制性策略。

二、SDL步驟圖

SDL中的方法，試圖從安全漏洞產(chǎn)生的根源上解決問題，通過對軟件工程的控制，保證產(chǎn)品的安全性。

美國國家標準與技術研究所（NIST）估計，如果是在項目發(fā)布后在執(zhí)行漏洞修復計劃，其修復成本相當于在設計階段執(zhí)行修復的30倍

三、SDL的步驟包括：

階段1：培訓

開發(fā)團隊的所有成員都必須接受適當?shù)陌踩嘤?#xff0c;了解相關的安全知識，培訓對象包括開發(fā)人員、測試人員、項目經(jīng)理、產(chǎn)品經(jīng)理等。

階段2：安全要求

在項目確立之前，需要提前與項目經(jīng)理或者產(chǎn)品owner進行溝通，確定安全的要求和需要做的事情。確認項目計劃和里程碑，盡量避免因為安全問題而導致項目延期發(fā)布。

階段3：質(zhì)量門/bug欄

質(zhì)量門和bug欄用于確定安全和隱私質(zhì)量的最低可接受級別。

Bug欄是應用于整個開發(fā)項目的質(zhì)量門，用于定義安全漏洞的嚴重性閾值。例如，應用程序在發(fā)布時不得包含具有“關鍵”或“重要”評級的已知漏洞。Bug欄一經(jīng)設定，便絕不能放松。

階段4：安全和隱私風險評估

安全風險評估（SRA）和隱私風險評估(PRA)是一個必需的過程，必須包括以下信息：

1、（安全）項目的哪些部分在發(fā)布前需要威脅模型？

2、（安全）項目的哪些部分在發(fā)布前需要進行安全設計評析？

3、（安全）項目的哪些部分需要并不食欲項目團隊且雙方認可的小組進行滲透測試？

4、（安全）是否存在安全顧問認為有必要增加的測試或分析要求已緩解安全風險？

5、（安全）模糊測試要求的具體范圍是什么？

6、（安全）隱私影響評級如何？

階段5：設計要求

在設計階段應仔細考慮安全和隱私問題，在項目初期確定好安全需求，盡可能避免安全引起的需求變更。

階段6：減小攻擊面

減小攻擊面與威脅建模緊密相關，不過它解決安全問題的角度稍有不同。減小攻擊面通過減小攻擊者利用潛在弱點或漏洞的機會來降低風險，減小攻擊面包括：關閉或限制對系統(tǒng)服務的訪問，應用“最小權限原則”，以及盡可能進行分層防御。

階段7：威脅建模

為項目或產(chǎn)品面臨的威脅建立模型，明確可能來自的攻擊有哪些方面。

階段8：使用指定的工具

開發(fā)團隊使用的編輯器、鏈接器等相關工具，可能會涉及一些安全相關的環(huán)節(jié)，因此在使用工具的版本上，需要提前與安全團隊進行溝通。

階段9：棄用不安全函數(shù)

許多常用函數(shù)可能存在安全隱患，應當禁用不安全的函數(shù)和API，使用安全團隊推薦的函數(shù)。

階段10：靜態(tài)分析

代碼靜態(tài)分析可以由相關工具輔助完成，其結(jié)果與人工分析相結(jié)合。

階段11：動態(tài)程序分析

動態(tài)分析是靜態(tài)分析的補充，用于測試環(huán)節(jié)驗證程序的安全性。

階段12：模糊測試（Fuzzing Test）

模糊測試是一種專門形式的動態(tài)分析，它通過故意向應用程序引入不良格式或隨機數(shù)據(jù)誘發(fā)程序故障。模糊測試策略的制定，以應用程序的預期用途，以及應用程序的功能和設計規(guī)范為基礎。安全顧問可能要求進行額外的模糊測試，或者擴大模糊測試的范圍和增加持續(xù)時間。

階段13：威脅模型和攻擊面評析

項目經(jīng)常會因為需求等因素導致最終的產(chǎn)出偏離原本設定的目標，因此在項目后期對威脅模型和攻擊面進行評析是有必要的，能夠及時發(fā)現(xiàn)問題并修正。

階段14：事件響應計劃

受SDL要求約束的每個軟件在發(fā)布時都必須包含事件響應計劃。即使在發(fā)布時不包含任何已知漏洞的產(chǎn)品，也可能在日后面臨新出現(xiàn)的威脅。需要注意的是，如果產(chǎn)品中包含第三方的代碼，也需要留下第三方的聯(lián)系方式并加入事件響應計劃，以便在發(fā)生問題時能夠找到對應的人。

階段15：最終安全評析

最終安全評析（FSR）是在發(fā)布之前仔細檢查對軟件執(zhí)行的所有安全活動。通過FSR將得出以下三種不同不同結(jié)果。

1、??通過FSR。在FSR過程中確定所有安全和隱私問題都已得到修復或緩解。

2、??通過FSR但有異常。在FSR過程中確定所有安全和隱私問題都已得到修復或緩解，并且/或者所有異常都已得到圓滿解決。無法解決的問題將記錄下來，在下次發(fā)布時更正。

3、??需上報問題的FSR。如果團隊未滿足所有SDL要求，并且安全顧問和產(chǎn)品團隊無法達成可接受的折中，則安全顧問不能批準項目，項目不能發(fā)布。團隊必須在發(fā)布之前解決所有可解決的問題，或者上報高級管理層進行抉擇。

階段16：發(fā)布/存檔

在通過FSR或者雖有問題但達成一致后，可以完成產(chǎn)品的發(fā)布。但發(fā)布的同時仍需對各種問題和文檔進行存檔，為緊急響應和產(chǎn)品升級提供幫助。

從以上的過程可以看出，微軟的SDL的過程實施非常細致。微軟這些年來也一直幫助公司的所有產(chǎn)品團隊，以及合作伙伴實施SDL，效果相當顯著。

相對于微軟的SDL，OWASP推出了SAMM（Software Assurance Maturity Model），幫助開發(fā)者在軟件工程的過程中實施安全。

SAMM與SDL的主要區(qū)別在于，SDL適用于軟件開發(fā)商，他們以販售軟件為主要業(yè)務；而SAMM更適用于自主開發(fā)軟件的使用者，如銀行或在線服務提供商。軟件開發(fā)商的軟件工程往往較為成熟，有著嚴格的質(zhì)量控制；而自主開發(fā)軟件的企業(yè)組織，則更強調(diào)高效，因此在軟件工程的做法上也存在差異。

四、SDL實戰(zhàn)經(jīng)驗準則：

準則一：與項目經(jīng)理進行充分溝通，排除足夠的時間

準則二：規(guī)范公司的立項流程，確保所有項目都能通知到安全團隊，避免遺漏

準則三：樹立安全部門的權威，項目必須由安全部門審核完成后才能發(fā)布

準則四：將技術方案寫入開發(fā)、測試的工作手冊中

準則五：給工程師培訓安全方案

準則六：記錄所有的安全bug，激勵程序員編寫安全的代碼

總結(jié)

以上是生活随笔為你收集整理的安全开发流程（SDL、微软）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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