向Microsoft Team Foundation Server 2010中添加安全錯誤評級

軟件開發團隊在其產品生命周期過程中面臨的一項最有爭議的任務就是會審錯 誤。對於產品開發中涉及的每個人來說，確定任何給定錯誤的相對重要性級別（ 進而確定該錯誤在發布之前無法及時修復的可能性）都是一件嚴肅的事情。

編程人員、測試人員、架構師和項目經理都有不同觀點，並且其各自的會審決 策以下面一些分散的因素為基礎：

修復後，有多少代碼必須進行回歸測試。

距離發布項目有多長時間。

多少用戶會受到更改的影響。

錯誤是否阻止了其他問題的測試或修復。

我承認，在會審產品功能中的功能錯誤時，這些都是重要的考慮因素。不過， 在確定是否修復安全錯誤（也就是可能導致產品中出現安全漏洞的錯誤）時，這 些不應作為考慮因素。安全錯誤的分類必須客觀一致。對於一名攻擊者來說，您 是否是在代碼完成裡程碑的前一周發現的漏洞無關緊要，因為攻擊者會同樣地利 用這個漏洞。

本專欄介紹由 Microsoft 內部產品和在線服務團隊使用的客觀安全錯誤分類 系統（“錯誤評級”），這是安全開發生命周期 (SDL) 所需要的。本文還介紹您 如何可將此分類系統納入自己的使用 Microsoft Team Foundation Server 2010 的開發環境中。

DREAD

在我討論 Microsoft 內部現在存在的錯誤評級之前，有必要介紹一下 Microsoft 早期的安全錯誤分類舉措：DREAD。DREAD 是一個助記手段，代表：

潛在破壞性

可再現性

可利用性

受影響的用戶

可發現性

記錄新安全錯誤的任何人都將為每個 DREAD 參數分配一個從 1 到 10 的值， 10 表示程度最嚴重，1 表示程度最不嚴重。然後對這些值取平均值形成一個總體 DREAD 評級。例如，假設一位名叫 Doug 的開發人員在其團隊的新 Web 應用程序 管理門戶頁發現了一個 SQL 盲注攻擊漏洞。Doug 可能會如圖 1 所示對該漏洞進 行分類。

圖 1 一位開發人員的安全漏洞分類

DREAD 參數 評級 基本原理 潛在破壞性 5 攻擊者可以讀取和更改產品數據庫中的數據。 可再現性 10 每次都可再現。 可利用性 2 需要專業知識和大量的時間投入。 受影響的用戶 1 僅影響一小部分用戶群。 可發現性 1 所有用戶頁面都無法鏈接到受影響頁面。 總計評分 3.8  

圖 1 所示的分類看似頗為簡單、有效。但是考慮一下，Doug 的測試人員同事 Tina 可能會以一種完全不同的方式看待同一漏洞，如圖 2 所示。

圖 2 一位測試人員對同一錯誤的分類

DREAD 參數 評級 基本原理 潛在破壞性 10 攻擊者可以讀取和更改產品數據庫中的數據。 可再現性 10 每次都可再現。 可利用性 10 通過使用 Internet 上找到的自動化工具可輕松利用。 受影響的用戶 10 影響關鍵的管理用戶。 可發現性 10 攻擊者可輕松猜出受影響頁面“admin.aspx”。 總計評分 10.0  

由於 Tina 知道有工具可自動進行 SQL 盲注攻擊，因此將“可利用性”評級 為 10，而 Doug 將其視為困難的手動攻擊，因此將“可利用性”評級為 2。Doug 將“受影響的用戶”評級為 1，因為只影響一小部分系統用戶，但 Tina 將其評 級為 10，因為受影響的用戶具有管理權限。可能最令人關注的參數就是“潛在破 壞性”：Doug 和 Tina 給出的基本原理完全相同，但評分值卻大不相同！

此時，我們要問的問題不是“哪個團隊成員的 DREAD 評級更好？”，而是“ 我們怎麼能依賴於一個產生這樣主觀、可變結果的系統？”。如果 Tina 第一個 發現該錯誤，則在發布前確實可以修復該錯誤，但如果 Doug 第一個發現，則很 可能會將其延誤，導致應用程序帶著該漏洞發布。SDL 團隊得出我們不能依賴這 此類系統的結論，因此 Microsoft 開發了一個更加一致的方法：安全錯誤評級。

Microsoft 安全錯誤評級

Microsoft 安全錯誤評級基於漏洞的影響對其進行分類。記錄錯誤的人員首先 會給錯誤分配一個來自 STRIDE 值列表的安全影響值。STRIDE 是另一個助記手段 ，在本示例中用於對威脅進行分類。與 DREAD 不同，STRIDE 仍被 SDL 經常使用 ，並且是多個 SDL 工具的核心組件（包括 SDL 威脅建模工具）。STRIDE 值為：

假冒

篡改

否認

信息洩露

拒絕服務 (DoS)

特權提升 (EoP)

不過，僅靠較大的 STRIDE 威脅類別不足以對一個錯誤進行分類和會審。在大 多數情況下，我們需要知道該錯誤是影響客戶端代碼還是服務器端代碼。例如， 我們不會將涉及一個目標用戶的拒絕服務攻擊與涉及整個服務器的拒絕服務攻擊 視為具有相同的嚴重性。我們還需要知道該錯誤的一些特定范圍信息，具體取決 於 STRIDE 和客戶端/服務器分類。

繼續以拒絕服務漏洞為例，我們需要知道誰可以執行攻擊（例如，什麼權限級 別）以及影響將持續多久。匿名用戶可利用的漏洞比只有通過身份驗證的用戶方 可利用的漏洞要糟糕，將受影響服務器鎖定以致只能進行物理重新啟動的漏洞比 僅造成服務器在幾秒時間內不能訪問的漏洞要糟糕。

借助主要 STRIDE 分類和一些附加范圍特性，會審錯誤的人員現在可以使用此 信息來查找該錯誤在錯誤評級上的嚴重程度。圖 3 顯示了一個已在安全開發生命 周期過程指南文檔 4.1a 版中發布的示例安全錯誤評級。此錯誤評級定義了四種 級別的安全性：關鍵、重要、一般和低。

圖 3 示例安全錯誤評級

STRIDE 值 客戶端/
服務器 范圍 嚴重程度 假冒 客戶端 攻擊者能夠提供一個不同的 UI，但該 UI 與用戶在默認/常見方案中 必須依賴其做出有效信任決策的 UI 在外觀上相同。信任決策定義為任何時候用 戶在采取操作時相信某些信息是由特定實體（系統或某個特定的本地或遠程源） 提供的。 重要     攻擊者能夠提供一個不同的 UI，但該 UI 與用戶在特定方案中習慣於 信任的 UI 在外觀上相同。“習慣於信任”定義為用戶通常根據與操作系統或應 用程序的正常互動而熟悉、但通常不將其視為“信任決策”的任何內容。 一般     攻擊者能夠提供一個不同的 UI，但該 UI 與屬於較大攻擊方案的一部 分的 UI 在外觀上相同。 低   服務器 連接到服務器的計算機能夠使用設計為提供強身份驗證的協議偽裝成 攻擊者選擇的其他用戶或計算機。 重要     客戶端用戶或計算機能夠使用設計為提供強身份驗證的協議偽裝成其 他隨機的用戶或計算機。 一般 篡改/ 否認 客戶端 永久修改在常見或默認方案中做出信任決策時所用的任何用戶數據或 數據，所做修改在重新啟動操作系統/應用程序後繼續保持。 重要     臨時修改任何數據，所做修改在重新啟動操作系統/應用程序後不會繼 續保持。 低   服務器 永久修改在常見或默認方案中做出信任決策時所用的任何用戶數據或 數據，所做修改在重新啟動操作系統/應用程序後繼續保持。 重要     永久修改在特定方案中做出信任決策時所用的任何用戶數據或數據， 所做修改在重新啟動操作系統/應用程序後繼續保持。 一般     臨時修改常見或默認方案中的數據，所做修改在重新啟動操作系統/應 用程序後不會繼續保持。 一般     臨時修改特定方案中的數據，所做修改在重新啟動操作系統/應用程序 後不會繼續保持。 低 信息洩露 客戶端 攻擊者可以找到並讀取系統上信息（包括不打算或未設計進行公開的 系統信息）。 重要     攻擊者可以從系統上的已知位置讀取信息（包括不打算或未設計進行 公開的系統信息）。 一般     任何無目標的信息洩露（即隨機洩露數據）。 低   服務器 攻擊者可以從系統上的任何位置找到並讀取信息（包括不打算或未設 計進行公開的系統信息）。 重要     攻擊者可以從系統上的已知位置輕松讀取信息（包括不打算或未設計 進行公開的系統信息）。 一般     任何無目標的信息洩露（例如，隨機洩露數據），包括運行時數據。 低 拒絕服務 客戶端 “系統損壞 DoS”：需要重新安裝系統和/或組件。 重要     “永久 DoS”：需要冷重啟或導致藍屏/錯誤檢查。 一般     “臨時 DoS”：需要重新啟動應用程序。 低   服務器 匿名，必須“容易利用”（通過發送少量數據）或通過其他方式快速 引發。 重要     不在默認/常見安裝中擴大的匿名、臨時 DoS。 一般     通過身份驗證的永久 DoS。 一般     通過身份驗證的臨時 DoS，在默認/常見安裝中擴大。 一般 提升權限 客戶端 遠程用戶，能夠執行任意代碼或獲得比預期更多的權限。 關鍵     遠程用戶，通過大量的用戶操作執行任意代碼。 重要     本地的低權限用戶可以將自己的權限提升為其他用戶、管理員或本地 系統。 重要   服務器 遠程匿名用戶，能夠執行任意代碼或獲得比預期更多的權限。 關鍵     通過身份驗證的遠程用戶，能夠執行任意代碼或獲得比預期更多的權 限。 重要     通過身份驗證的本地用戶，能夠執行任意代碼或獲得比預期更多的權 限。 重要

請注意，為了使此系統能夠正常工作，使用的錯誤跟蹤數據庫必須有一個針對 STRIDE 安全影響的字段。這樣，就可以輕松區分安全錯誤與功能錯誤，並確定正 確的錯誤評級分類。跟蹤錯誤的安全影響是如此重要，以至於實際上有一個單獨 的 SDL 要求來做這項工作。幸好，在大多數情況下，這都非常容易。如果您使用 的是 Team Foundation Server (TFS)，下一節將向您說明如何將安全影響字段和 錯誤評級添加到團隊項目中的 Bug 工作項目。

向 Team Foundation Server 中添加錯誤評級功能

要將錯誤評級添加到 TFS 團隊項目，您需要對創建項目所依據的底層過程模 板進行更改。對於本文來說，我們假設項目是根據 TFS 2010 beta 2 附帶的 MSF-Agile for Software Development 5.0 版 (beta) 模板創建的。不過，如果 您主要使用其他過程模板（如 MSF for CMMI Process Improvement 模板）或任 何自定義第三方模板，用於編輯這些模板的方法將相同。

首先為要在其上工作的 TFS 2010 服務器打開過程模板管理器。可通過以下方 法執行此操作：在團隊資源管理器窗口中打開該服務器的上下文菜單，然後導航 至“團隊項目集合設置”|“過程模板管理器”，如圖 4 所示。

圖 4 適用於 TFS 2010 服務器的過程模板管理器

在過程模板管理器中，選擇 MSF for Agile Software Development v5.0，然 後單擊“下載”按鈕將該模板的源文件下載到本地。將它們保存到您自選的文件 夾中。

下載完成後，關閉過程模板管理器。我們希望將錯誤評級添加到 Bug 工作項 目類型，因此，打開保存剛才下載的 MSF-Agile 模板的文件夾，然後在所選 XML 編輯器中打開文件 \WorkItem Tracking\TypeDefinitions\Bug.xml。

第一個任務是為安全影響、安全影響范圍和錯誤評級嚴重程度添加相應的字段 。（用於錯誤評級嚴重程度的字段應有別於固有的 Severity 字段，稍後我將解 釋原因。）在 witd:WITD/WORKITEMTYPE/FIELDS 元素下，添加圖 5 所示的 XML 塊。

圖 5 為安全影響、安全影響范圍和錯誤評級嚴重程度添加相應的字段

<FIELD
reportable="dimension"
type="String"
name="Effect"
refname="MSDN.SDL.Security.Effect">
<HELPTEXT>The　effect　of　the　security　 bug</HELPTEXT>
</FIELD>
<FIELD
reportable="dimension"
type="String"
name="EffectScope"
refname="MSDN.SDL.Security.Effect.Scope">
<HELPTEXT>The　scope　of　the　effect　of　the　security　bug.　 This　value　is　used　to　determine　the　default　bug　bar　 severity</HELPTEXT>
</FIELD>
<FIELD
reportable="dimension"
type="String"
name="BugBarSeverity"
refname="MSDN.SDL.Security.Severity.BugBar">
<HELPTEXT>The　suggested　severity　of　the　bug　as　determined 　by　the　security　bug　bar</HELPTEXT>
</FIELD>

此代碼定義了三個新字段（包括其名稱、類型和幫助文本），但仍未實現邏輯 。通過添加鎖定該字段可能值的允許值約束，開始添加邏輯。

對於 Effect，允許值為每個 STRIDE 值：“Spoofing”、“Tampering”、“ Repudiation”、“Information Disclosure”、“Denial of Service”和 “Elevation of Privilege”。對於自身沒有漏洞但可借此機會減少以後的潛在 漏洞的情況，最好將“Attack Surface Reduction”也添加為允許值。最後，對 於錯誤只是普通的功能錯誤而沒有安全影響的情況，將“Not a Security Bug” 添加為允許值（請參見圖 6）。

圖 6 添加 Effect 的允許值

<FIELD
reportable="dimension"
type="String"
name="Effect"
refname="MSDN.SDL.Security.Effect">
<HELPTEXT>The　effect　of　the　security　 bug</HELPTEXT>
<ALLOWEDVALUES>
<LISTITEM　value="Not　a　Security　Bug"　/>
<LISTITEM　value="Spoofing"　/>
<LISTITEM　value="Tampering"　/>
<LISTITEM　value="Repudiation"　/>
<LISTITEM　value="Information　Disclosure"　/>
<LISTITEM　value="Denial　of　Service"　/>
<LISTITEM　value="Elevation　of　Privilege"　/>
<LISTITEM　value="Attack　Surface　Reduction"　/>
</ALLOWEDVALUES>
<DEFAULT　from="value"　value="Not　a　Security　Bug"　/>
</FIELD>

對於 EffectScope，匯總錯誤評級中每個可能的范圍項目，並將這些匯總添加 為 EffectScope 字段的允許值（請參見圖 7）。

圖 7 添加 EffectScope 的允許值

<FIELD
reportable="dimension"
type="String"
name="EffectScope"
refname="MSDN.SDL.Security.Effect.Scope">
<HELPTEXT>The　scope　of　the　effect　of　the　security　bug.　 This　value　is　used　to　determine　the　default　bug　bar　 severity</HELPTEXT>
<ALLOWEDVALUES>
<LISTITEM　value="Not　Applicable"　/>
<LISTITEM　value="Client　-　Spoofed　trusted　UI　in　 common/default　scenario"　/>
<LISTITEM　value="Client　-　Spoofed　trusted　UI　in　specific　 other　scenario"　/>
<LISTITEM　value="Client　-　Spoofed　UI　as　part　of　a　larger　 attack　scenario"　/>
<LISTITEM　value="Server　-　Spoofed　specific　user　or　computer　 over　secure　protocol"　/>
<LISTITEM　value="Server　-　Spoofed　random　user　or　computer　 over　secure　protocol"　/>
<LISTITEM　value="Client　-　Tampered　trusted　data　that　persists 　after　restart"　/>
<LISTITEM　value="Client　-　Tampered　data　that　does　not　 persist　after　restart"　/>
<!--　additional　allowed　values　omitted　for　brevity　-->
</ALLOWEDVALUES>
<DEFAULT　from="value"　value="Not　Applicable"　/>
</FIELD>

我們還希望根據 Effect 的當前值進一步限制 EffectScope 的允許值。如果 Effect 當前設置為 Spoofing，則僅假冒相關的 EffectScope 值應該有效。如果 Effect 設置為 Tampering，則僅篡改相關的 EffectScope 值應該有效，依此類 推。我們可通過將 WHEN 子句元素添加到 FIELD 定義中來實現這個目的（請參見 圖 8）。

圖 8 添加 WHEN 子句以限制 EffectScope 的允許值

<FIELD
reportable="dimension"
type="String"
name="EffectScope"
refname="MSDN.SDL.Security.Effect.Scope">
<HELPTEXT>The　scope　of　the　effect　of　the　security　bug.　 This　value　is　used　to　determine　the　default　bug　bar　 severity</HELPTEXT>
<ALLOWEDVALUES>
<!--　omitted　for　brevity　-->
</ALLOWEDVALUES>
<DEFAULT　from="value"　value="Not　Applicable"　/>
<WHEN　field="MSDN.SDL.Security.Effect"　value="Not　a　Security　 Bug">
<ALLOWEDVALUES>
<LISTITEM　value="Not　Applicable"　/>
</ALLOWEDVALUES>
</WHEN>
<WHEN　field="MSDN.SDL.Security.Effect"　value="Attack　Surface　 Reduction">
<ALLOWEDVALUES>
<LISTITEM　value="Not　Applicable"　/>
</ALLOWEDVALUES>
</WHEN>
<WHEN　field="MSDN.SDL.Security.Effect"　value="Spoofing">
<ALLOWEDVALUES>
<LISTITEM　value="Client　-　Spoofed　trusted　UI　in　 common/default　scenario"　/>
<LISTITEM　value="Client　-　Spoofed　trusted　UI　in　specific　 other　scenario"　/>
<LISTITEM　value="Client　-　Spoofed　UI　as　part　of　a　larger　 attack　scenario"　/>
<LISTITEM　value="Server　-　Spoofed　specific　user　or　computer　 over　secure　protocol"　/>
<LISTITEM　value="Server　-　Spoofed　random　user　or　computer　 over　secure　protocol"　/>
<LISTITEM　value="Not　Applicable"　/>
</ALLOWEDVALUES>
</WHEN>

<!--　Additional　WHEN　elements　for　the　other　STRIDE　values　 omitted　for　brevity　-->

</FIELD>

現在來為 BugBarSeverity 字段實現允許值邏輯。BugBarSeverity 的邏輯與 Effect 邏輯略有不同，表現在我們不希望用戶能夠直接設置 BugBarSeverity 字 段的值。實現此類錯誤評級的關鍵之處在於嚴重程度應反映漏洞的特性。如果用 戶可以自行將嚴重程度設置為任何值，這將完全違背初衷。

我們不創建 BugBarSeverity 允許值列表，而是使用 WHEN 字段根據 Effect 的當前值將相應的值復制到 BugBarSeverity 字段中（由我們之前定義的錯誤評 級確定）。例如，錯誤評級指定應將常見或默認方案中的假冒信任 UI 視為“重 要”錯誤，因此當 Effect 為“Client – Spoofed trusted UI in common/default scenario”時，我們將“2 – Important”復制到 BugBarSeverity 中（請參見圖 9）。

圖 9 實現 BugBarSeverity 字段的值邏輯

<FIELD
reportable="dimension"
type="String"
name="BugBarSeverity"
refname="MSDN.SDL.Security.Severity.BugBar">
<HELPTEXT>The　suggested　severity　of　the　bug　as　determined 　by　the　security　bug　bar</HELPTEXT>
<WHEN　field="MSDN.SDL.Security.Effect.Scope"　value="Not　 Applicable">
<COPY　from="value"　value="4　-　Low"/>
</WHEN>
<WHEN　field="MSDN.SDL.Security.Effect.Scope"　value="Client　-　 Spoofed　trusted　UI　in　common/default　scenario">
<COPY　from="value"　value="2　-　Important"/>
</WHEN>
<WHEN　field="MSDN.SDL.Security.Effect.Scope"　value="Client　-　 Spoofed　trusted　UI　in　specific　other　scenario">
<COPY　from="value"　value="3　-　Moderate"/>
</WHEN>
<WHEN　field="MSDN.SDL.Security.Effect.Scope"　value="Client　-　 Spoofed　UI　as　part　of　a　larger　attack　scenario">
<COPY　from="value"　value="4　-　Low"/>
</WHEN>
<WHEN　field="MSDN.SDL.Security.Effect.Scope"　value="Server　-　 Spoofed　specific　user　or　computer　over　secure　protocol">
<COPY　from="value"　value="2　-　Important"/>
</WHEN>
<WHEN　field="MSDN.SDL.Security.Effect.Scope"　value="Server　-　 Spoofed　random　user　or　computer　over　secure　protocol">
<COPY　from="value"　value="3　-　Moderate"/>
</WHEN>

<!--　additional　WHEN　clauses　omitted　for　brevity　-- >

</FIELD>

您可能會奇怪，為什麼我在值上添加了數字前綴如“1 – Critical”和“2 – Important”，而不是只將其定義為“Critical”和“Important”。答案是 TFS 會自動按字母順序排列允許值列表，因此在沒有數字前綴的情況下，這些選 項將無序顯示，從而可能讓用戶迷惑。

此外，固有 MSF-Agile Severity 字段 (Microsoft.VSTS.Common.Severity) 的值應用了相同的數字前綴，因此將前綴添加到 BugBarSeverity 字段可強調這 兩個字段之間有關系的事實。

談到 Severity 和 BugBarSeverity 之間的關系，是時候在模板中強制實施該 關系了。此過程中的下一步是限制 Severity 字段的值，以使其嚴重程度與 BugBarSeverity 字段至少相同。如果團隊有特定的業務原因要讓實際嚴重程度比 錯誤評級確定的值更高，也沒有關系 — 我們只是不希望出現相反的情況。

為此，我們基於 Effect 字段的值使用用來限制 EffectScope 字段的相同 ALLOWEDVALUES 方法（請參見圖 10）。

圖 10 限制 Severity 字段的允許值

<FIELD
name="Severity"
refname="Microsoft.VSTS.Common.Severity"
type="String"
reportable="dimension">
<HELPTEXT>Assessment　of　the　effect　of　the　bug　on　the　 project</HELPTEXT>
<ALLOWEDVALUES　expanditems="true">
<LISTITEM　value="1　-　Critical"/>
<LISTITEM　value="2　-　High"/>
<LISTITEM　value="3　-　Medium"/>
<LISTITEM　value="4　-　Low"/>
</ALLOWEDVALUES>
<DEFAULT　from="value　"value="3　-　Medium"　/>

<WHEN　field="MSDN.SDL.Security.Severity.BugBar"value="1　-　 Critical">
<ALLOWEDVALUES　expanditems="true">
<LISTITEM　value="1　-　Critical"/>
</ALLOWEDVALUES>
</WHEN>
<WHEN　field="MSDN.SDL.Security.Severity.BugBar"　value="2　-　 Important">
<ALLOWEDVALUES　expanditems="true">
<LISTITEM　value="1　-　Critical"/>
<LISTITEM　value="2　-　High"/>
</ALLOWEDVALUES>
</WHEN>
<WHEN　field="MSDN.SDL.Security.Severity.BugBar"　value="3　-　 Moderate">
<ALLOWEDVALUES　expanditems="true">
<LISTITEM　value="1　-　Critical"/>
<LISTITEM　value="2　-　High"/>
<LISTITEM　value="3　-　Medium"/>
</ALLOWEDVALUES>
</WHEN>
</FIELD>

您需要對 Bug 工作項目做最後一項更改：您需要為我們已添加的新字段添加 UI 控件，如以下代碼段中所示。在此文檔的 witd:WITD/WORKITEMTYPE/FORM/Layout 部分定義了工作項目控件。由您決定新字 段的位置，但我建議將新的“Security”選項卡添加到主要 TabGroup 上，並在 該處添加以下字段：

<Tab　Label="Security">
<Control　Field　Name="MSDN.SDL.Security.Effect"　 Type="FieldControl"　Label="Effect　"LabelPosition="Top"　/>
<Control　Field　Name="MSDN.SDL.Security.Effect.Scope"　 Type="FieldControl"　Label="Scope"　LabelPosition="Top"　/>
<Control　Field　Name="MSDN.SDL.Security.Severity.BugBar"　 Type="FieldControl"　Label="Bug　Bar　Rating"　ReadOnly="True"　 LabelPosition="Top"　/>
</Tab>

現在您已完成編輯 Bug 工作項定義的工作。不過，必須將修改的過程模板定 義導回到 Team Foundation Server，才能使用新的錯誤評級功能。完成此操作有 兩種方法。可以將現有 MSF-Agile for Software Development 模板替換為新模 板，也可以添加新模板與舊版本模板並存。

如果選擇替換現有模板，請打開過程模板管理器，選擇 MSF-Agile for Software Development 模板，然後單擊“刪除”按鈕。請注意，該操作不可逆。 如果不重新安裝 Team Foundation Server，將無法重新獲得原始模板。刪除現有 MSF-Agile 模板後，單擊“上載”按鈕，然後選擇包含已編輯過程模板的文件夾 。該模板將與以前一樣在列表中顯示為“MSF-Agile for Software Development ”，但此後根據此模板創建的任何項目都將具有錯誤評級功能。

如果選擇添加新模板與現有 MSF-Agile 模板並存而不是將其替換，則需要更 改新模板的名稱，以便它與現有模板無沖突。為此，需要多進行一次文件編輯。 在選擇的 XML 編輯器中，編輯 ProcessTemplate.xml 文件，該文件可以在最初 將模板下載到的文件夾中找到。將 ProcessTemplate/metadata/name 元素的值更 改為“MSF for Agile Software Development plus Bug Bar”之類的內容，保存 文件，然後退出。打開過程模板管理器，單擊“上載”按鈕，選擇包含已編輯模 板的文件夾。新模板在列表中顯示的名稱將為給定的名稱，此後根據此模板創建 的任何項目都將包含錯誤評級。

使用錯誤評級確定退出條件

當然，如果沒有組織策略的支持，世界上的任何過程模板功能都不會對您有幫 助。Microsoft 內部開發團隊的標准是：在錯誤評級“低”類別之上的任何安全 錯誤都必須在發布之前得到修復。此標准從未放松過，不管距離產品發布時間有 多近。此方法完全依據錯誤的可能影響和范圍，因此可保證安全錯誤會審的客觀 性。

這就是為什麼我們定義一個單獨的 BugBarSeverity 字段，而不是僅基於 EffectScope 限制通用 Severity 字段的值的原因。從嚴格的安全角度來看，我 們不關心產品是否附帶任何嚴重程度為“關鍵”錯誤，只要這些錯誤沒有安全影 響即可。我們真正關心的是該錯誤的 BugBarSeverity 是否高於“4 – Low”。 如果是這樣，該錯誤必須在發布之前得到修復。

倡議

如果沒有客觀一致的過程來會審安全錯誤，您將無法創建安全的應用程序。使 用 Microsoft 安全錯誤評級是實現此目標的一個絕佳方式，並且它是安全開發生 命周期的關鍵組件，已證實能夠減少軟件中的漏洞。

此外，如果使用的是 Microsoft Team Foundation Server，您可以輕松將錯 誤評級功能添加到團隊項目。即使開發人員不一定是安全專家，這也可使您的團 隊更加輕松地對安全錯誤進行相應分類。

最後，我建議您下載適用於 Visual Studio 2010 的 MSF-Agile + SDL 過程 模板。此過程模板在發布 Visual Studio 2010 之後不久即在 microsoft.com/sdl 免費提供。它包含了本文中介紹的錯誤評級，以及其他很多 旨在幫助您創建更安全軟件的功能。