摘要： 本文介紹可信賴計算安全開發生命周期（或 SDL），即 Microsoft 在開發需要抵御惡意攻擊的軟件時采用的一套流程。 該流程在 Microsoft 軟件開發流程的每個階段添加了一系列關注安全性的活動和交付結果。 這些活動和交付結果包括在軟件設計過程中開發威脅模型、在實施過程中使用靜態分析代碼掃描工具以及在集中進行的“安全推動”過程中進行代碼審核和安全測試。 應用 SDL 的軟件在發布之前，必須由獨立于開發小組的另一個小組執行最終安全審核。 與未應用 SDL 的軟件相比，應用了 SDL 的軟件從外部發現其安全漏洞的機率顯著降低。 本文介紹 SDL 并討論了在 Microsoft 軟件開發過程中實施該流程的經驗。
注意 本文是 2004 計算機安全應用年會上發表的”可信賴計算安全開發生命周期“一文的更新版本，這次大會由 IEEE 主辦，已于 2004 年 12 月在亞利桑那州圖森市舉行。
1. 簡介
所有軟件供應商都有必要解決安全威脅方面的問題。 對軟件供應商來說，安全性是其核心要求，這是由市場力量所驅動，也是由保護關鍵基礎結構及建立和保持計算的廣泛信任的需要所決定的。 所有軟件供應商面對的一個主要挑戰就是創建更加安全的軟件，使其不需要頻繁地通過修補程序進行更新，且需要進行的安全管理工作也更少。
對于軟件行業來說，要滿足當今提升安全性的需要，關鍵在于實施可重復的流程，通過這些流程可靠地實現可測量的安全性提升。 因此，軟件供應商必須轉為采用一種更嚴格的、更加關注安全性的軟件開發流程。 這種流程旨在盡量減少設計、編碼和文檔編寫過程中存在的漏洞，并在開發生命周期中盡可能早地檢測到并消除這些漏洞。 用于處理來自 Internet 的輸入、控制可能被攻擊的關鍵系統或處理個人身份信息的企業和消費者軟件最需要實施這種流程。
構建更安全的軟件可從三個方面著手：可重復的流程、工程師教育以及度量標準和可測量性。 本文檔重點介紹 SDL 的可重復流程方面，雖然也討論了工程師教育并提供了反映目前部分應用 SDL 的影響的一些總體指標。
如果參照 Microsoft 的經驗，其他組織采用 SDL 應該不會為軟件開發增加不合理的成本。 根據 Microsoft 的經驗，提供更安全的軟件的益處（例如，更少的補丁和更加滿意的用戶）超過付出的代價。
SDL 會集成一些有助于提升軟件安全性的措施，在此過程中可能需要對軟件開發組織的流程進行調整。 本文檔概述了這些措施，并說明了將其集成到典型的軟件開發生命周期中的方法。 進行這些調整的目的不是要完全改變開發流程，而是在開發流程中加入一些精心定義的安全檢查點和安全性交付結果。
本文假定公司（或軟件開發組織）中存在一個中央小組，該小組致力于推動最佳安全做法的制訂與改進和流程優化，為整個組織提供專家意見，并在軟件發布前對其進行審核（最終安全審核或 FSR）。 根據 Microsoft 的經驗，設立這樣一個組織對成功實施 SDL 和提升軟件安全性十分重要。 可能有些組織會考慮由承包商或顧問擔任“中央安全小組”角色。 本文介紹如何將旨在提升軟件安全性的一系列步驟集成到大型軟件開發組織通常使用的軟件開發流程中。 Microsoft 設計并實施了這些步驟，作為其可信賴計算計劃的一部分。 這些流程改進的目標是減少用戶使用的軟件中安全漏洞的數量并降低安全漏洞的嚴重程度。 在本文中，這種經過調整的軟件開發流程，即當前在 Microsoft 實施的流程被稱為可信賴計算軟件開發生命周期（或簡稱為 SDL）。
Microsoft 的經驗是在軟件設計和開發過程中必須經常與安全小組進行互動，并必須與其共享敏感的技術和商業信息。 由于以上原因，最好的解決方案是在軟件開發組織內部建立一個安全小組（雖然可能有必要請顧問人員幫助建立小組和培訓小組的成員）。
1.1 基本流程
在 Microsoft 普遍采用的軟件開發流程大致如圖 1 所示。 從更高層面上看，這也是行業內的典型流程。
圖 1. 標準的 Microsoft 開發流程
盡管圖 1 顯示了五個里程碑，看起來開發流程好像是“瀑布式”的，實際上該流程是螺旋形的。 為了對市場需求的變化和軟件實施中遇到的實際情況做出反應，在實施階段可能經常需要重新考慮需求和設計問題。 并且，該開發流程強調在幾乎每個點都要提供運行代碼，這樣每個主要里程碑實際上分解為交付一系列構件，從而可以不斷向前地測試和操作使用這些構件（由開發小組進行）。
1.2 安全開發生命周期概述
現實世界中的軟件安全性方面的經驗已經為構建更安全的軟件建立了一套高標準的原則。 Microsoft 將這些原則稱作 SD3+C – 設計安全、默認安全、部署安全和通信。 這些原則的簡要定義如下：
•設計安全：在架構、設計和實現軟件時，應使它在運行時能保護自身及其處理的信息，并能抵御攻擊。
•默認安全：在現實世界中，軟件達不到絕對安全，所以設計者應假定其存在安全缺陷。 為了使攻擊者針對這些缺陷發起攻擊時造成的損失最小，軟件在默認狀態下應具有較高的安全性。 例如，軟件應在最低的必要權限下運行，非廣泛需要的服務和功能在默認情況下應被禁用或僅可由少數用戶訪問。
•部署安全：軟件應該隨附工具和指導以幫助最終用戶和/或管理員安全地使用它。 此外，更新應該易于部署。
•通信：軟件開發者應為產品漏洞的發現做好準備并坦誠負責地與最終用戶和/或管理員進行通信，以幫助他們采取保護措施（如打補丁或部署變通辦法）。
盡管 SD3+C 的每個要素均對開發流程提出了要求，但前兩個要素（設計安全和默認安全）對提升安全性的作用最大。 設計安全改進流程以防止在第一階段引入漏洞，默認安全則要求軟件默認狀態下暴露的地方，即“攻擊面”達到最小。
在現有開發流程中引入旨在集成 SD3+C 方法的安全措施后形成的總體流程結構如圖 2 所示。
圖 2. SDL 對 Microsoft 開發流程的改進
本文的第 2 節從更高層面介紹了 SDL 的各個組件。 第 3 節簡要概述了 Microsoft 實施 SDL 的特定情況。 本文第 4 節提供了一些說明性的數據，展示了在 Microsoft Windows Server 2003 和其他軟件開發過程中對 SDL 的早期應用在減少安全漏洞數和嚴重性等級方面（與之前的軟件版本相比）起到的作用。 第 5 節根據 Microsoft 應用 SDL 的經驗對流程各要素進行了定性討論。 最后，第 6 節進行了總結。
2. 安全開發生命周期流程
如前所述，工程師教育已超出本文的討論范圍。 但是必須認識到教育計劃對 SDL 的成功實施至關重要。 計算機科學和相關專業的大學應屆畢業生一般缺乏必要的培訓，不能立即加入工作隊伍從事安全軟件的設計、開發或測試工作。 即使是學了安全課程的人員，他們可能對加密算法或訪問控制模型接觸較多，但是對緩沖區溢出或規范化缺陷可能了解不多。 一般情況下，行業內的軟件設計者、工程師和測試人員也缺乏適當的安全技術知識。
在這些情況下，準備開發安全軟件的組織必須負責對其工程人員進行適當教育。 根據組織的規模和可用的資源，應付這種挑戰的方法可能會有所不同。 擁有大批工程人員的組織可建立一個內部計劃對其工程師進行在職安全培訓，而小型組織則可能需要依賴外部培訓。 在 Microsoft，所有從事軟件開發的人員必須參加一年一次的“安全進修課程”培訓。
2.1 需求階段
安全系統開發的一個基本原則就是需要“自下而上”地考慮安全問題。 盡管很多開發項目開發出的“后續版本”是建立在先前發布的版本基礎上，但是新的發行版或版本的需求階段和初始規劃仍然為構建安全軟件提供了極好的機會。
在需求階段中，產品小組與中央安全小組聯系，請求指派安全顧問（在 Microsoft 實施 SDL 時稱為“安全員”），該安全顧問在進行規劃時充當聯絡點，并提供資源和指導。 安全顧問通過審核計劃、提出建議和確保安全小組規劃適當的資源來支持產品小組的日程，為產品小組提供協助。 安全顧問在安全里程碑和出口標準方面向產品小組提出建議，這些安全里程碑和出口標準是由項目的規模、復雜程度和風險決定的。 從項目開始到完成最終安全審核和軟件發布，安全顧問始終充當產品小組與安全小組之間的聯系點。 安全顧問還充當安全小組和產品小組管理人員之間的聯系人，向小組管理人員提供關于項目的安全要素是否正常工作的意見，以避免在流程的晚期出現安全方面的問題。
在需求階段中，產品小組應考慮如何在開發流程中集成安全性，找出關鍵的安全性對象，以及在盡量提升軟件安全性的同時盡量減少對計劃和日程的影響。 在此過程中，產品小組需要考慮如何使軟件的安全功能和保證措施與其他可能與該軟件配合使用的軟件相互集成。 （要滿足用戶將各個產品集成到安全系統的需要，考慮與其他軟件的接口非常關鍵。）產品小組關于安全目標、挑戰和計劃的整體構想必須反映到需求階段中制作的規劃文檔中。 雖然計劃可能會隨著項目的進行而變化，但是較早地明確制訂這些計劃將有助于確保不會忽視任何需求或不會直到最后一刻才發現它們。
每個產品小組都應將安全性要求視為此階段的重要組成部分。 盡管有些安全性要求將在威脅建模過程中確定，但是用戶需求可能要求根據客戶的要求來考慮一些安全性。 符合行業標準或認證過程（如通用標準）的需要也可能提出一些安全性要求。 作為正常規劃流程的一部分，產品小組應認識到并反映這些要求。
2.2 設計階段
設計階段確定軟件的總體需求和結構。 從安全性的角度來看，設計階段的關鍵要素包括：
•定義安全體系結構和設計指導原則：從安全性角度定義軟件的總體結構，并確定對安全性起關鍵作用的組件（“可信賴計算基礎”）。 確定將在軟件中全面應用的設計技巧，如分層、使用強類型語言、應用最低權限和使攻擊面最小化。 （分層 指的是將軟件組織成精心定義的組件以避免組件之間出現循環依賴關系 — 將組件組織為層，高級層可以依賴低級層的服務，且禁止低級層依賴高級層的服務。）體系結構中各要素的特點將在各自的設計規范中詳細說明，而安全體系結構只是確定安全設計的總體構想。
•記錄軟件攻擊面的要素。 由于軟件不可能絕對的安全，所以必須重視的是：默認情況下應僅將大多數用戶需要使用的功能對所有用戶開放，且可以用盡可能最低的權限安裝那些功能。 對攻擊面要素進行度量可為產品小組提供默認安全性的現行度量標準，使產品小組可以檢測到令軟件易受攻擊的情況。 盡管有些增加攻擊面的情況可能是因為增加了產品功能或可用性導致的，但是在設計和實施過程中還是需要對每種這樣的情況進行認真檢測和研究，以確保軟件交付時在默認配置下具有最好的安全性。
•對威脅進行建模。 產品小組逐個組件地對威脅進行建模。 組件小組使用結構化的方法，確定軟件必須管理的模塊以及訪問那些模塊時所使用的接口。 威脅建模過程確定可能對每個模塊造成損害的威脅以及導致損害的可能性（風險評估）。 組件小組然后確定降低風險的對策 — 通過安全功能（如加密）或通過正確使用保護模塊免受損害的軟件。 這樣，威脅建模可以幫助產品小組確定安全性需求，以及需要特別仔細地審核代碼和進行安全測試的領域。 應使用工具來支持威脅建模過程，該工具應可以處理機器可讀格式的威脅模型，并可以對其進行存儲和更新。
•定義補充性交付標準。 盡管應定義組織的基本安全交付標準，但是各個產品小組或軟件版本也可以設立發布軟件前必須符合的特定標準。 例如，正在開發一個準備交付用戶使用并可能面臨高強度攻擊的軟件更新版本的產品小組可以建立這樣的標準：在一段時間內外部沒有發現新版本漏洞時才認為它已做好發布的準備。 （也就是說，開發過程應在漏洞被報告之前找到并消除這些漏洞，而不是在產品小組接到報告之后不得不“修復”這些漏洞。）
2.3 實施階段
在實施階段，產品小組對軟件進行編碼、測試和集成。 在此階段將采取措施消除安全缺陷或防止引入安全缺陷的作用很大 — 這些措施將大大減少安全漏洞遺留到發布給用戶的軟件最終版本中的可能性。
威脅建模的成果為實施階段提供特別重要的指導。 開發者應特別注意確保代碼的正確性以消除高優先級威脅，測試者可集中對這些威脅進行測試以確保將其攔截或消除。
在實施階段中應用的 SDL 要素為：
•應用編碼和測試標準。 編碼標準幫助開發者避免引入導致安全漏洞的缺陷。 例如，使用更安全和更一致的字符串處理和緩沖區操縱結構有助于避免引入緩沖區溢出漏洞。 測試標準和最佳做法有助于確保將測試重點放在檢測潛在的安全漏洞上，而不僅僅是專注于測試軟件功能的正確運行。
•應用包括模糊化工具在內的安全測試工具。 “模糊化”為軟件應用程序編程接口 (API) 和網絡接口提供結構化但無效的輸入，以使檢測到可能導致軟件漏洞的錯誤的可能性最大化。
•應用靜態分析代碼掃描工具。 這些工具可檢測出某些類型的可能導致漏洞的編碼缺陷，包括緩沖區溢出、整數溢出和未初始化變量。 Microsoft 在開發這類工具上已進行了大量的投資（長期使用的兩個工具為 PREfix 和 PREfast），隨著新的編碼缺陷和軟件漏洞的發現，Microsoft 將繼續對這些工具進行改進。
•進行代碼審核。 作為自動化工具和測試的補充，將由接受過培訓的開發人員進行代碼審核，他們將檢查源代碼并檢測和消除潛在的安全漏洞。 這是開發流程中從軟件中消除安全漏洞的關鍵步驟。
2.4 驗證階段
驗證階段是指軟件已具備所有功能并進入用戶試用版測試的階段。 在此階段中，在對軟件進行試用版測試時，產品小組進行“安全推進”，包括進行安全代碼審核（超出實施階段中進行的審核范圍）和集中式安全測試。
早在 2002 年，Microsoft 已在 Windows Server 2003 及其他軟件版本驗證階段引入了安全推進。 在流程中引入安全推進有兩個原因：
•有問題的軟件版本已進入生命周期的驗證階段，此階段最適合進行所需的集中式代碼審核和測試。
•在驗證階段進行安全推進可確保代碼審核和測試針對的是軟件的完成版本，并提供了對實施階段開發或更新的代碼以及未修改的“遺留代碼”進行全部審核的機會。
其中第一個原因反映了歷史上的巧合：在驗證階段進行安全推進的決定。 但是 Microsoft 已證實在驗證階段進行安全推進確實是非常好的做法，既可以確保最終的軟件符合要求又可以對先前軟件版本的舊代碼進行更深入的審核。
特別要注意的是對高優先級代碼（成為軟件“攻擊面”一部分的代碼）進行代碼審核和測試對 SDL 其他部分十分關鍵。 例如，在實施階段需要進行這類審核和測試，以便盡早矯正任何問題，并確定和矯正這類問題的來源。 在驗證階段由于產品已接近完成，所以進行這類審核和測試也十分重要。
2.5 發布階段
在發布階段中，應對軟件進行最終安全審核 (FSR)。 FSR 的目標是要回答下面這個問題。 “從安全的角度看，此軟件是否已準備好交付給客戶？”一般在軟件完成之前 2 到 6 個月進行 FSR，具體時間根據軟件的規模決定。 在進行 FSR 之前，軟件必須已處于穩定狀態，且只剩一些很小的非安全性更改需要在發布前完成。
FSR 是由組織的中央安全小組對軟件進行的獨立審核。 在進行 FSR 之前，來自安全小組的安全顧問向產品小組建議軟件所需進行 FSR 的范圍，并為產品小組提供資源需求列表。 產品小組為安全小組提供完成 FSR 所需的資源和信息。 FSR 開始時，產品小組需要填寫一份問卷并與派來進行 FSR 的安全小組成員進行面談。 所有 FSR 將要求對最初標識為安全漏洞，但后來經過深入分析確定為對安全性沒有影響的缺陷進行審核，以確保分析的正確性。 FSR 還包括審核軟件是否能抵御最新報告的影響類似軟件的漏洞。 對主軟件版本進行 FSR 時需要進行滲透測試，可能還需要利用外面的安全審核承包商來協助安全小組。
FSR 不是簡單的通過/失敗測試，FSR 的目標也不是找出軟件中所有剩余漏洞，因為這顯然不太可行。 實際上，FSR 是為產品小組和組織的高層管理人員提供：軟件的安全水平以及軟件發布給用戶后抵御攻擊的能力的總體狀況。 如果 FSR 發現某類剩余漏洞，正確的反應是不僅要修復發現的漏洞，還要回到之前的階段并采取其他針對性的措施解決根本原因（例如，提高培訓質量和改進工具）。
2.6 支持和服務階段
盡管在開發過程中應用了 SDL，最先進的開發方法還是無法保證發布的軟件完全沒有漏洞，而且有充分的理由證明永遠都做不到。 即使開發流程可以在交付之前從軟件中消除所有漏洞，還是可能會發現新的攻擊方式，這樣過去“安全”的軟件也就不再安全。 因此，產品小組必須準備好對交付給用戶的軟件中新發現的漏洞作出響應。
響應過程包括評估漏洞報告并在適當的時候發布安全建議和更新。 響應過程還包括對已報告的漏洞進行事后檢查以及采取必要的措施。 對漏洞采取的措施的范圍很廣：從為孤立的錯誤發布更新到更新代碼掃描工具以重新對主要的子系統進行代碼審核。 響應階段的目標是從錯誤中吸取教訓，并使用漏洞報告中提供的信息幫助在軟件投入使用前檢測和消除深層漏洞，以免這些漏洞給用戶帶來危害。 響應過程還有助于產品小組和安全小組對流程進行改造，以免將來犯類似錯誤。
3. Microsoft 實施安全開發生命周期的情況
自 2002 年初進行“安全推進”以來，Microsoft 的 SDL 實施不斷發展。 為了啟動該流程并對已進入開發后期的產品產生影響，安全推進將本應分布在 SDL 多個階段的活動壓縮為相對短期的活動。 安全推進對產品小組的計劃、資源和日程產生了重大影響，如果沒有 Microsoft 高層管理人員的積極支持，實施起來就會困難得多。 安全推進將重點放在威脅建模、代碼審核和安全測試（包括滲透測試）上。 在 2002 年末和 2003 年初，在 Windows Server 2003 發布之前引入了最終安全審核 (FSR)，而 FSR 對 Windows Server 2003 交付時的默認配置產生了重大影響。
在進行初步的安全推進和 FSR 之后，Microsoft 啟動了一個項目來使 SDL 流程正式化。 此項目有四個特殊成果值得特別注意：
•SDL 的強制應用策略
•工程人員的強制教育
•產品小組的度量標準
•中央安全小組的角色
以下各節將分別介紹上述領域
3.1 SDL 的強制應用
由于 SDL 產生了顯著的效果（請參閱第 5 節），Microsoft 決定正式要求對廣泛領域內的軟件應用 SDL。 在撰寫本文的時候，SDL 正在成為必須對以下類別的所有軟件強制應用的流程：
•將用于處理個人或敏感信息的軟件
•將在企業或其他組織（包括學術機構、政府或非贏利機構）使用的軟件
•將連接至 Internet 或在網絡環境中使用的軟件
未強制 應用 SDL 的 軟件包括不符合以上標準的獨立應用程序（例如兒童游戲，像“魔法學校巴士”系列）。 但是，SDL 可以顯著地避免這種軟件影響運行該軟件的平臺（操作系統或其他軟件）的安全性。
3.2 強制教育
2002 年初的安全推進的一個關鍵方面就是培訓了產品小組的全部人員，包括所有開發人員、測試人員、程序經理和文檔管理人員。 Microsoft 已正式要求對其軟件必須實施 SDL 流程的部門的工程師進行一年一次的安全教育。 每年需要進行知識更新是因為安全性事實上不是一個靜態的范疇：威脅、攻擊和防御都在不斷的演變。 因此，即使工程師已完全掌握影響其軟件的安全性方面的知識，在威脅發生變化時也必須接受新的培訓。 例如，在過去四年中，整數溢出漏洞的重要性大大增加了，而且最近發現一些加密算法存在以前未知的漏洞。
Microsoft 已開發出一套通用的面向工程師的安全知識簡介和更新教程，以“現場培訓”和數字媒體兩種形式提供。 Microsoft 以該教程作為基礎，然后再按軟件技術和工程師角色進行專門的培訓。 Microsoft 正在編寫一套安全教育課程，這套教程將根據技術、角色和學員的經驗水平進行專業化的細分。
很多 Microsoft 合作伙伴和客戶已經在詢問何時能為他們提供 Microsoft 安全教育和流程。 Microsoft Press 已根據 Microsoft 在安全性設計、編碼和威脅建模方面的內部實踐出版了書籍，Microsoft Learning 也根據 Microsoft 的內部實踐提供了課程。
3.3 產品小組的度量標準
作為一個公司，Microsoft 相信一句名言“您無法管理無法測量的事物。”盡管設計一套能夠可靠測量軟件安全性的度量標準十分困難，還是有一些明顯可視為軟件安全性代表特征的度量標準。 這些度量標準包括工程人員的培訓覆蓋面（在開發生命周期的開始階段）到在已向用戶發布的軟件中發現的漏洞數。
Microsoft 已設計出一套安全性度量標準，產品小組可將其用于監控 SDL 的實施情況。 這些度量標準監控 SDL 在小組內的實施，從威脅建模到代碼審核和安全測試，再到提交 FSR 時軟件需具備的安全性。 隨著這些度量標準的持續實施，既允許小組追蹤自身的表現（提高、不變或下降），也允許將其表現與其他小組進行對比。 這些度量標準將定期報告給高級產品小組管理人員和 Microsoft 主管人員。
3.4 中央安全小組
在 2002 年實施安全推進之前，Microsoft 已建立了 Secure Windows Initiative (SWI) 小組，該小組的任務是提升軟件安全性并減少 Windows 的漏洞，并為負責開發 Windows 以外產品的產品小組提供安全支持。 SWI 小組在組織和管理 Windows Server 2003 安全推進活動中起中心作用，并為自 2002 年開始進行的所有安全推進活動提供了培訓和咨詢支持。 SWI 小組還對 Windows Server 2003 進行了 FSR，開創了 FSR 流程。
在 Microsoft，隨著 SDL 的正式推行，SWI 小組已取代中央安全小組的作用。 SWI 小組的責任包括：
•SDL 的開發、維護和改進，包括定義流程的強制部分。
•工程師教育課程的開發、改進和推行。
•指派“安全顧問”，這些顧問在流程中對產品小組進行指導，為產品小組執行審核并確保產品小組的問題得到及時、準確和權威性的解答。
•擔任廣泛的安全主題事務方面的專家，確保提交給安全顧問或通過其提交的問題得到及時、準確的解答。
•在軟件發布之前執行最終安全審核。
•對已發布給用戶的軟件中報告的漏洞進行技術調查，以確保找到問題的根本原因并作出適當的響應。
在 Microsoft，SWI 小組的存在及其有效性已證實它是實施 SDL 過程中的關鍵因素。 Microsoft 的目標是建立一個開發更安全軟件的可伸縮流程，要實現此目標就需要在所有產品小組內廣泛實施安全性要求。 然而，擁有一個高水平的中央安全小組還是對以下工作非常關鍵：提高公司內產品小組的工作效率，并在其創建更安全的軟件方面提供支持。 中央安全小組還可以確保由產品小組之外的人員執行 FSR。
4. Microsoft 實施安全開發生命周期的成果
現在 Microsoft 就得出結論宣布 SDL 提升了 Microsoft 軟件的安全性還為時過早，但是到目前為止所取得的成果令人鼓舞。
Windows Server 2003 是 Microsoft 實施 SDL 大部分流程的第一個操作系統。 圖 3 顯示了兩個最新的 Microsoft 服務器操作系統（Windows 2000 和 Windows Server 2003）發布后一年內頒布的安全公告數。 （在發布 Windows 2000 的時候，Microsoft 還沒有正式的安全公告嚴重性分級系統。 Microsoft 已參照當前的嚴重性分級系統對應用于 Windows 2000 的每個安全公告進行了評估。）正如本文前面所述，Windows Server 2003 開發時實施了大部分（但不是全部）SDL 流程，Windows 2000 開發時還沒有實施這些流程。
圖 3. Windows 實施 SDL 之前和之后的嚴重和重要安全公告數
有關嚴重性類別的定義，請參閱http://www.microsoft.com/technet/security/bulletin/rating.mspx。
其他 Microsoft 軟件發行版也應用了 SDL 的一些要素。 SQL Server 和 Exchange Server 產品小組在發布 Service Pack（一種聚合安全性漏洞和其他問題的修復程序的軟件發行版）之前分別進行了安全推進（包括威脅建模、代碼審核和安全測試）。 SQL Server 安全推進的成果主要體現在 SQL Server 2000 Service Pack 3 中，Exchange Server 安全推進的成果主要體現在 Exchange 2000 Server Service Pack 3 中。 圖 4 和 5 顯示了發布各自的 Service Pack 之前和之后相同期限內頒布的安全公告數（SQL Server 2000 的期限為 24 個月；Exchange 2000 Server 的期限為 18 個月）。
圖 4. SQL Server 2000 實施 SDL 之前和之后的安全公告數
圖 5. Exchange Server 2000 實施 SDL 之前和之后的安全公告數
另一個鼓舞人心的例子是 Windows Server 2003 的 Internet 信息服務器組件 (IIS 6)，在發布之后兩年內，Microsoft 只頒布了一個影響 Web 服務器的安全公告，并且這個公告所針對的還是在默認情況下不會安裝的組件 (WebDAV)。
盡管安全性漏洞的例子比較少而且研究的時間段也有限，但是這些結果還是為 SDL 的有效性提供了有力的證據。 Microsoft 將繼續監控 Windows Server 2003 以及 Exchange Server 和 SQL Server Service Pack 中出現的漏洞數，以觀察這種早期的趨勢是否會繼續下去。 Microsoft 還將分析其他在全面實施了 SDL 之后交付了新版本的 Microsoft 軟件，以確定安全漏洞的數量和嚴重性是否繼續下降
5. 應用安全開發生命周期的觀察
前一節展示的數據提供了希望 SDL 達成的“目標”的概況。 本節將嘗試回答一些關于該流程“如何”工作的問題。 前一節建立在強有力的數字基礎上（Microsoft 在跟蹤漏洞報告和安全公告方面非常嚴格），本節則建立在 SWI 小組人員所經歷的事實基礎上（根據他們的觀察和意見）。
5.1 SDL 各要素的有效性
SDL 由 大量的子流程組成，這些子流程分布整個軟件開發生命周期內。 已要求 SDL 小組按照有效性區分這些子流程的優先級 — 哪些子流程效果最顯著，哪些子流程已試驗過卻效果不明顯。
SWI 小組的共識是威脅建模是 SDL 中最高優先級的子流程。 顯然，威脅建模不能孤立地應用：威脅建模促進設計、代碼審核和測試，一個流程如果只實施威脅建模但對模型不采取任何響應措施（例如未對緩解措施的有效性進行測試），則將不會有任何效果。 缺陷數形式的統計數據不能很好地說明威脅建模的作用，因為威脅建模的主要作用在于確保不產生導致安全漏洞的缺陷。 然而，由于威脅建模在開發安全軟件流程中的作用極其關鍵，因此它顯然應該排在最前面。
SDL 在 Microsoft 還是一個相對較新的流程，還沒有出現過刪除該流程中的子流程的情況。 但是，對長期研究安全的人員來說，有一個發現不會令人感到驚訝，即滲透測試不是獲得安全性的好方法。 滲透測試是對主軟件發行版進行的最終安全審核 (FSR) 的要素之一，但是產品小組在整個生命周期中的活動主要集中在威脅建模、代碼審核、自動化工具的使用以及模糊化測試，而不是滲透測試。后面的這些措施在防止或消除安全缺陷方面比經典的特定滲透測試更加全面有效。 FSR 的滲透測試要素有助于判斷軟件是否已準備好可以發布，而不適合作為發現和修復安全缺陷的方法。 如果在 FSR 階段進行的滲透測試發現了大量的安全缺陷，則是因為早期階段不夠有效，正確的處理方法是重新檢查那些階段中所謂已完成的活動，而不是僅僅修復滲透測試缺陷就發布軟件。
5.2 工具、測試和代碼審核
靜態分析工具、模糊化測試和代碼審核的作用是互補性的。 Microsoft 已在靜態分析代碼掃描工具方面進行了大量的投資，這些工具的使用已成為 SDL 必不可少的一部分。 這些工具在發現許多會導致安全漏洞的編碼錯誤（特別是緩沖區溢出）方面很有效。 然而，當前最先進的工具也不能發現所有錯誤。 SDL 仍然需要進行手動代碼審核，一方面是為了檢測到工具未發現的錯誤，另一方面也是為了確定可以在哪些方面改進這些工具。 參考文獻中引用的由 Michael Howard 發表的 Microsoft Developer Network (MSDN) 文章概述了 Microsoft 要求其工程師在進行代碼安全審核時使用的常用方法。
高度重視模糊化測試是最近才對 SDL 進行的改進，但是到目前為止所取得的成果非常令人鼓舞。 與靜態代碼掃描工具不同，必須為要測試的每種文件格式和/或網絡協議分別構建（或至少分別配置）模糊化測試工具；因此，它們通常可以發現靜態分析工具遺漏的錯誤。 威脅模型有助于產品小組劃分要測試的接口和格式的優先級。 模糊化測試的結果不是完全確定性的（這些工具只運行有限的循環次數，不保證能發現每個缺陷），但是經驗表明進行適當級別的模糊化測試可以發現一些“感興趣”的缺陷，這此缺陷可能作為安全漏洞處理。
5.3 投資
強制安全培訓對 Microsoft 這樣一個擁有大量工程人員的公司來說需要一筆巨額投資。 培訓的推行結合了現場（導師引導）培訓班和在線學習資料兩種方法。 在線學習資料對工作地址遠離 Microsoft 總部的小型工程小組來說是特別有價值的辦法。 已證明現場培訓在對準備進行安全推進或其他關鍵活動的小組進行全員培訓時特別有效，在這些情況下，Microsoft 的經驗表明小組培訓的成果不僅可以在課堂培訓上有所收獲，還可以在安全推進的過程中得到體現。 每個工作組成員都要關注安全性這個事實使安全培訓（通常為半天制）顯得更加重要。
最近幾年隨著 Microsoft 越來越重視安全性，中央安全小組（SWI 小組）得到了迅速成長。 通過精心設計，該小組相對于 Microsoft 工程人員總數來說相當小，且重視“規模適當”的方法，以確保開發更安全軟件的責任和資源植根于產品小組內部。 反映這種對規模適當的重視的一些策略包括：重視培訓和工具，設置安全顧問幫助產品小組解決其自身問題（而不是代替其解決問題），以及通過進行審核（包括 FSR）為產品小組就軟件是否已做好發布準備提供反饋。
5.4 收益
SDL 的最終檢驗標準是在消除和減少 Microsoft 軟件中的漏洞方面的有效程度。 第 4 節中總結的經驗表明 SDL 達到了這個檢驗標準。 Microsoft 還會評估外部報告的漏洞對正在開發的軟件版本的影響。 最近的經驗表明，在新版本中規劃或實施的安全措施成功地阻止過去對舊版本有效的攻擊的情況越來越多。 最近發布的 Windows XP Service Pack 2 就通過了這樣的審核，并發現已規劃但尚未實施或公開討論的安全更改消除了大量過去對 Windows 先前版本報告的漏洞（由外部安全研究人員向 Microsoft 報告的）。
6. 結論
Microsoft 的經驗表明 SDL 在減少安全漏洞出現方面十分有效。 SDL 的初步實施（在 Windows Server 2003、SQL Server 2000 Service Pack 3 和 Exchange 2000 Server Service Pack 3 中）使軟件安全性得到了顯著提升，而且后續的軟件版本，更顯示出對 SDL 進行改進后，軟件安全性得到進一步提升。
實施組成 SDL 的要素越多，對安全性的提升也就越多，這也是視為有效流程的一個特征。 該流程尚不完美，還在發展之中，而且在可以預見的將來也不會達到完美或停止發展。
安全開發生命周期的開發和實施對 Microsoft 來說意味著一筆重大投資，也是對軟件設計、開發和測試方法的重大變革。 軟件對社會的重要性在不斷增加，對 Microsoft 和整個軟件行業提升軟件安全性的要求也在不斷提高；因此發表這篇關于 SDL 的文章和有關特定技術的書籍（請參閱參考文獻）就是為了讓整個軟件行業分享 Microsoft 的經驗。
7. 感謝
本文最初由現有作者從 2002 年末共同努力開始撰寫。 本文草稿隨著 SDL 的發展不斷進行更新，當前的版本在 2004 年夏季和秋季完成。 作者向在定義和改進 SDL 方面做出貢獻的 Matt Thomlinson、Matt Lyons、Jamil Villani 和 Eric Bidstrup（Microsoft Secure Windows Initiative 小組全體成員）表示衷心的感謝。 除了上述對本文做出貢獻的人士，Microsoft 的 Scott Charney 和 Phil Reitinger 以及卡耐基梅隆大學的 Jeannette Wing 也對草稿提出了特別有幫助的意見。 作者還要感謝 Martin Abadi、Virgil Gligor、Dick Kemmerer、Chris Mitchell、Fred Schneider、Neeraj Suri 和 James Whittaker 為本文提出寶貴的意見和建議。
8. 參考文獻
Mundie, Craig, Trustworthy Computing White Paper
Howard, Michael, Attack Surface: Mitigate Security Risks by Minimizing the Code You Expose to Untrusted Users, MSDN Magazine, November 2004
Howard, Michael, Expert Tips for Finding Security Defects in Your Code, MSDN Magazine, November 2004
Howard, Michael and David LeBlanc, Writing Secure Code, Second Edition, Microsoft Press, Redmond, Washington, 2003
Swiderski, Frank and Window Snyder, Threat Modeling, Second Edition, Microsoft Press, Redmond, Washington, 2004
9. 注意事項
本文檔包含的信息代表 Microsoft Corporation 截至發布日期就所討論的問題發表的最新觀點。 由于 Microsoft 必須對不斷變化的市場狀況作出反應，因此這些觀點不應被解釋為 Microsoft 的承諾，并且 Microsoft 不保證所示任何信息在發布日期之后仍準確。
本白皮書僅供參考。 對本文檔中的信息，MICROSOFT 不做任何明示、默示或法定保證。
遵守所有適用的版權法是每個用戶的責任。 在不限制版權法所規定的權利的情況下，未經 Microsoft Corporation 明確的書面許可，不得出于任何目的、以任何形式或手段（電子的、機械的、影印、錄制等等）復制、傳播本文檔的任何部分，也不得將其存儲或引入到檢索系統中。
Microsoft 可能具有涉及本文檔中主題的專利、專利申請、商標、版權或其他知識產權。 除非 Microsoft 的書面許可協議明確規定，否則提供本文檔并不意味著賦予您這些專利、商標、版權或其他知識產權的任何許可。
© 2005 Microsoft Corporation. 保留所有權利。 本白皮書部分內容為電氣與電子工程師協會 2004 年版權所有。 保留所有權利。
Microsoft、MSDN、Windows 和 Windows Server 是 Microsoft Corporation 在美國和/或其他國家或地區的注冊商標或商標。
