• 發行項

本文章是由機器翻譯。

安全性簡報

在 Microsoft Team Foundation Server 2010 中新增安全性錯誤基線

Bryan Sullivan

軟體開發團隊面臨其產品 ’ 週期期間的最爭論工作之一就是分級的 Bug。 決定相對的任何給定的 Bug 的重要性層級 — 因此判斷該 Bug 可能不會修正在所有發行的時間內的機會和 — 是參與產品 ’s 開發的每一個人的嚴重問題。

程式設計人員、 軟體測試人員、 架構設計人員和程式經理都有不同的觀點，例如基礎上不同因素其個別的分級決策：

  • 多少程式碼就必須進行迴歸-測試修正程式之後。
  • 如何關閉以釋放專案是]。
  • 多少使用者會受變更所影響。
  • 是否 Bug 封鎖從被其他問題，測試或固定的。

我會承認這些是分類中產品功能的功能性錯誤時要考慮的所有重要因素。 不過，這些因素都不應該播放任何角色在決定是否要修復安全性錯誤 — 也就是在產品中的安全性弱點會導致潛在的錯誤。 安全性錯誤的分類必須客觀且一致。 它 doesn’t 使攻擊任何差異你找到了弱點之前您的程式碼完成階段性目標 ； 每週他利用它只是具有相同。

此資料行描述客觀的安全性 Bug 分類系統 — 「 Bug 列 」 — Microsoft 內部產品和使用線上服務團隊所需安全性開發生命週期 (SDL)。 它也會顯示如何您可以將這個分類系統，併入使用 Microsoft Team Foundation Server 2010年自己開發環境。

DREAD

當它存在於 Microsoft 之內今天，我會討論 Bug 列之前它 ’s 值得描述來分類安全性 Bug 的舊版 Microsoft 精神就：DREAD。 DREAD 是代表的助憶鍵：

  • 傷害潛力
  • 重現性
  • exploitability
  • 受影響的使用者
  • 可測知性

歸檔新的安全性 Bug 的任何人都會指派每個 DREAD 參數值從 1 到以 10 正在最嚴重的 10] 及 [1 最少。 值已然後平均來形成一個整體 DREAD 分級。 比方說說稱為 Doug 為開發人員會發現他的小組 ’s 新 Web 應用程式管理入口網頁中的盲人 SQL 注入弱點。 Doug 可能分類弱點 的 圖 1 所示。

圖 1 的 A 開發人員 ’s 安全性弱點分類

DREAD 參數 評分 基本原理
傷害潛力 5 攻擊者可以閱讀，並改變產品資料庫中的資料。
重現性 10 可以重新產生每一次。
exploitability 2 需要專業知識和大型時間投資。
受影響的使用者 1 只會影響使用者基底的小型子集。
可測知性 1 受影響未連結的所有使用者] 頁面的頁面。
整體評分 3.8  

 

的 圖 1 所示分類似乎相當直接而且有效。 但是請考慮陳，Doug ’s 軟體測試人員同事可能會看到完全相同的弱點，以完全不同的方式，如 的 圖 2 所示。

圖 2 為分類由某個軟體測試人員的相同錯誤

DREAD 參數 評分 基本原理
傷害潛力 10 攻擊者可以閱讀，並改變產品資料庫中的資料。
重現性 10 可以重新產生每一次。
exploitability 10 可輕鬆地利用由在網際網路上找到的自動化工具。
受影響的使用者 10 會影響關鍵的系統管理使用者。
可測知性 10 受影響的頁面 「 admin.aspx 」 輕鬆地猜到的攻擊。
整體評分 10.0  

 

因為陳注意有工具來自動化盲人 SQL 注入攻擊所以她而 Doug 看到為困難的手動攻擊而分級為 2 Exploitability 分級為 10，Exploitability。 因為它只會影響系統 ’s 使用者非常小的部份，但是陳分級它為 10 因為受影響的使用者會具有系統管理權限，Doug 將給予受影響的使用者為 1。 或許最關心的參數是殺傷力潛在的：Doug] 和 [陳給予完全相同的基本原理，但具有不同值計分!

我們需要詢問的問題此時是不，「 哪一個小組成員 ’s DREAD 分級是較佳 」? 但而，「 How 可以我們仰賴一個系統，會產生這類主觀的、 可變的結果嗎？ 」如果陳原本第一個人來尋找 Bug，它肯定會已經加以修正之前發行 ； 但如果 Doug 找到它先，有 ’s 良好的機率會有已延期] 和 [發行這項弱點的應用程式。 SDL 團隊認為我們 can’t 仰賴這類系統，因此 Microsoft 開發以更一致的方法：[安全性 Bug] 列中。

Microsoft 安全性 Bug 列

Microsoft 安全性 Bug 列會分類依據其影響的弱點。 藉由將 Bug 安全性效果值指派從 STRIDE 值清單開始歸檔 Bug 的人員。 STRIDE 是另一個助憶鍵，在這種情況下用來分類潛在威脅。 不像 DREAD，STRIDE 仍然十分由 SDL，而是核心元件的幾個的 SDL 工具包括 SDL 威脅模型化工具。 STRIDE 值如下：

  • 假冒
  • 竄改
  • 否認
  • 資訊洩露
  • 拒絕服務 (DoS)
  • 提高權限 (EoP)

不過，廣泛的 STRIDE 威脅分類-[單獨 isn’t 足夠用來分類及分級 Bug。 在大多數情況下，我們需要知道 Bug 影響用戶端程式碼或伺服器端程式碼。 比方說出單一的目標使用者所需的服務阻斷攻擊就不會被視為嚴重，做為採用出整個伺服器的其中一個。 我們也需要知道該 Bug 取決於 STRIDE 和用戶端/伺服器分類一些特定的範圍資訊。

我們需要知道誰可以執行攻擊 (比方說什麼特殊權限層級)，而且效果將持續多久在繼續 DoS 弱點範例。 由匿名使用者可利用來攻擊弱點是可利用來攻擊只能由已驗證的使用者和一種的弱點，受影響的伺服器直到某人實際重新開機的鎖定是比一個更糟的是，只可無法使用幾秒鐘以上糟。

武裝主要 STRIDE 分類加上額外的範圍特性與，分級 Bug 的人現在可以使用這項資訊來查閱 [Bug] 列上的錯誤 ’s 嚴重性。 圖 3 顯示範例安全性 Bug 列在安全性開發生命週期流程指引文件版本 4.1a 發佈。 Bug 列定義四個嚴重性層級：嚴重、 重要、 中度和低。

圖 3 的 範例安全性錯誤列

STRIDE 值 用戶端 /
Server (伺服器)		 範圍 嚴重性
假冒 Client 該使用者 上要產生有效的信任決策，在預設/一般的案例中必須依賴 呈現是不同於但視覺上完全相同 UI 的 UI 的攻擊者的能力。 信任決策定義為任何一次動作相信某些資訊呈現的特定實體的使用者會採用 — 系統或一些特定的本機或遠端來源。 重點
    該使用者 習慣在特定案例中信任 呈現是不同於但視覺上完全相同 UI 的 UI 的攻擊者的能力。 「 習慣信任 」 被指任何使用者是通常熟悉與作業系統或應用程式根據一般的互動，但並不通常想像成 「 信任決策 」。 中型
    呈現不同，但視覺上完全相同之 UI 的是更大的攻擊情境中的單一一部分 的 UI 的攻擊者的能力。 Low
  Server (伺服器) 連線到伺服器的電腦都能偽裝成不同的使用者或電腦他或她選擇 使用通訊協定 ，設計並提供增強式驗證行銷。 重點
    用戶端使用者或電腦都能偽裝成不同的隨機的使用者或電腦使用的設計和行銷來提供增強式驗證通訊協定。 中型
竄改/
Repudiation Client 永久修改的任何使用者或用來進行信任決策中常用的資料或重新啟動 OS/應用程式後仍然存在的預設案例。 重點
    暫時修改之後重新啟動 OS/應用程式已不存在任何資料。 Low
  Server (伺服器) 永久修改任何使用者的資料或資料用來進行信任決策 中一般或預設案例 後重新啟動 OS/應用程式仍然出現相同的。 重點
    永久修改任何使用者的資料或資料用來進行信任決策 在特定案例 後重新啟動 OS/應用程式仍然出現相同的。 中型
    暫存資料 修改 中一般或預設案例 ，不會保留在重新啟動 OS/應用程式之後。 中型
    暫存資料 在特定案例 ，不會保留在 OS/應用程式重新啟動後的修改。 Low
Information
Disclosure Client 攻擊者可以找出並讀取資訊包括系統資訊已不適用或設計來公開系統上的情況。 重點
    其中攻擊者才能讀取存放在系統 從已知的位置 ，包括系統資訊已不適用或設計來公開資訊的情況。 中型
    任何無目標的資訊洩漏 (也就是隨機資料洩漏)。 Low
  Server (伺服器) 攻擊者可以找出並讀取資訊 從任何地方 包括系統資訊已不適用或設計來公開系統上的情況。 重點
    其中攻擊者可以輕鬆地讀取存放在系統 從已知的位置 ，包括系統資訊已不適用或設計來公開資訊的情況。 中型
    任何 untargeted 資訊洩漏 (比方說的隨機資料洩漏) 包括執行階段資料。 Low
拒絕服務 Client 「 系統毀損 DoS 」：需要重新安裝的系統及/或元件。 重點
    「 永久 DoS 」：需要冷重新開機，或導致藍色螢幕/錯誤檢查。 中型
    「 暫時性 DoS 」：需要重新啟動的應用程式。 Low
  Server (伺服器) 匿名，必須是 「 輕鬆地利用 」 藉由傳送少量的資料或否則會迅速導致。 重點
    沒有預設/一般的放大匿名、 暫存 DoS 安裝。 中型
    已驗證、 永久 DoS。 中型
    安裝與預設/一般的放大的已驗證、 暫存 DoS。 中型
提高權限 Client 遠端使用者任一個能夠執行任意程式碼 或 取得比預期更多的權限。 嚴重不足
    遠端使用者執行任意程式碼 以 廣泛的使用者動作。 重點
    本機、 低權限的使用者可以提高親自頒發給另一位使用者的系統管理員或本機系統。 重點
  Server (伺服器) 遠端匿名使用者任一個能夠執行任意程式碼 或 取得比預期更多的權限。 嚴重不足
    遠端驗證使用者可能執行任意程式碼 或 以取得更多的權限比預定能力。 重點
    本機通過驗證的使用者能夠任一個執行任意程式碼 或 以取得更多的權限比預期。 重點

 

請注意這個系統運作以便使用在 Bug 追蹤資料庫必須具有 STRIDE 安全性效果的欄位。 這可讓您更輕鬆區別功能性 Bug 的安全性 Bug，也決定正確的 Bug 列分類。 追蹤 Bug ’ 安全性效果是因此重要的是進行這個工作實際上個別 SDL 需求。 幸好，這是相當簡單，在大多數情況下。 如果您使用 Team Foundation Server (TFS) 下, 一節會顯示如何加入安全性效果欄位，Bug 列評等來 Bug 工作項目小組專案中。

將 Bug 列功能加入至 Team Foundation Server

若要新增錯誤列到 TFS Team 專案，您需要對基礎專案從建立的流程範本進行變更。 基於本文的目的，我們將假設專案已建立從 「 MSF-Agile 軟體開發版本 5.0 船的 (Beta 版) 範本 TFS 2010 Beta 2。 不過，如果您主要是使用這類的 MSF 方法程序改進範本或任何自訂的協力廠商範本的不同的處理程序範本用來編輯這些範本的技術是一樣。

藉由開啟您想要處理的 TFS 2010 伺服器的流程範本管理員來開始。 您可以這樣做，即可在 [Team 總管] 視窗顯示伺服器的內容功能表，然後巡覽至 Team 專案集合設定 | 流程範本管理員， 的 圖 4 所示。


圖 4 的 TFS 2010 Serv 的流程範本管理員

在流程範本管理員，選擇 Agile 軟體開發 v5.0 和按一下 [下載] 按鈕，將範本來源在本機檔案向下 MSF。 將它們儲存到您所選擇的資料夾。

下載完成後關閉流程範本管理員。 我們要將 Bug 列新增到 Bug 工作項目類型，所以開啟的您剛才下載 MSF Agile 範本然後在您選擇的 [XML 編輯器中開啟檔案 \WorkItem Tracking\TypeDefinitions\Bug.xml 資料夾]。

第一項工作是安全性效果、 安全性效果領域和 Bug 列嚴重性新增欄位。 (Bug 列嚴重性應該維持不同於固有的嚴重性欄位我稍後說明的原因)。witd:WITD/WORKITEMTYPE/欄位項目下，新增 的 [圖 5] 所示的 XML 區塊。

圖 5 加入安全性效果、 安全性效果領域和 Bug 列嚴重性欄位

<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>

這個程式碼會定義三個新欄位，包括其名稱、 類型和說明文字 ； 但有 ’s 仍然沒有實作的邏輯。 開始將鎖定可能的值為欄位的允許值條件約束加入邏輯。

效果，為允許的值是每個 STRIDE 值：詐騙竄改否認、 資訊洩漏、 拒絕服務和權限提高。 它 ’s 也是個不錯的想法新增攻擊曲面圖減少為可能不是本身，弱點的情況下的值是允許，但會降低潛在的未來弱點的好機會。 最後，將尚未安全性 Bug 新增為 Bug 所在只是一般功能性 Bug 與沒有安全性含意的情況下的允許值 (請參閱 的 圖 6)。

圖 6 加入允許的值] 效果

<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，摘要每個可能的範圍項目，在列中的 Bug 並加入這些摘要，如允許值為 [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>

我們也想要進一步限制允許的值的 EffectScope 效果的目前值而定。 如果詐騙目前的設定效果，只在欺騙相關 EffectScope 值應是有效。 如果效果設定為 [竄改，只有竄改相關 EffectScope 值應該是有效，等等。 我們可以完成這者時子句項目加入欄位定義 (請參閱 的 [圖 8])。

圖 8 加入一個時子句限制允許 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>

現在它 ’s 實作 BugBarSeverity 欄位的允許的值邏輯的時間。 BugBarSeverity 的邏輯是從效果邏輯稍有不同，因為我們 don’t 想要使用者能夠直接設定 BugBarSeverity 欄位的值。 實作一個 Bug 列，就像這樣的整個的點是最高嚴重性應該會反映這項弱點的特性。 如果使用者只可以設定為 [任何值的最高嚴重性他或她想，它會完全擊敗目的。

而非建立允許的值清單的 BugBarSeverity，我們將使用時機，將適當的值複製到 [BugBarSeverity] 欄位的欄位由我們稍早，已定義的 Bug 列根據目前值的效果。 比方說 Bug 列指定一個偽造信任在一般的使用者介面，或預設案例應該被視為一個重要的 Bug，當 「 用戶端 – 詐騙常見/預設案例中的受信任使用者介面 」 效果，我們到 BugBarSeverity 複製 「 2 – 重要事項 」 (請參閱 的 圖 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 – 要徑 」 和 「 2 – 重要，」 而非只它們定義為 「 重大 」 和 「 重要 」。答案是 TFS 自動 alphabetizes 的允許值和數字的前置詞，該選項就會顯示順序及可能混淆使用者沒有清單。

而且，固有的 MSF Agile 嚴重性欄位 (Microsoft.VSTS.Common.Severity) 值有相同的數字首碼套用到這些，因此將前置詞加入至 BugBarSeverity 欄位能這兩個欄位之間沒有關聯的事實。

它嚴重性和 BugBarSeverity 關係說 ’s 來強制執行範本中的該關聯性的時間。 處理程序中的下一個步驟是限制 [重要性] 欄位的值，以便 ’s 至少為 BugBarSeverity 欄位為嚴重。 如果小組進行實際 「 嚴重性 」 高於由 Bug 列的值的特定商務理由，’s [確定] — 我們剛剛 don’t 要它執行其他的方式。

若要將這項工作中，我們使用相同的 ALLOWEDVALUES 技術我們用來限制該效果的值為基礎的 EffectScope 欄位欄位 (請參閱 的 圖 10)。

圖 10 約束允許嚴重性欄位的值

<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/配置文件的區段。 它您放入新的欄位，但我建議您新增新的 「 安全性 」 索引標籤至主要 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 工作項目定義。但是，才能使用新的 Bug 列功能您必須回 Team Foundation Server匯入已修改的程序範本定義。您有兩個選擇如何執行這項操作。您可以是取代現有 MSF-Agile 為軟體開發範本使用新的範本或您可以新增新範本--並排與舊版本。

如果選擇取代現有的範本開啟流程範本管理員，選取 [MSF-Agile 為軟體開發範本並按一下 [刪除] 按鈕。請注意這是一個無法復原動作。您 won’t 能夠回無須重新安裝 Team Foundation Server取得原始範本。一旦刪除現有的 MSF Agile 範本，按一下 [上載] 按鈕，並選取含有已編輯的流程範本的資料夾。範本會出現在清單中為 「 MSF Agile 為軟體開發 」 只是作為前，但是現在從此範本建立任何未來的專案將會有 Bug 列功能。

如果選擇新增該新範本--並排與現有的 MSF Agile 範本來取代它的需要變更新範本的名稱，讓它 doesn’t 與現有的衝突。若要執行此動作，您需要製作一個編輯的多個檔案。在選擇的您 XML] 編輯器中編輯檔案可在要您原先下載範本資料夾中找到的 ProcessTemplate.xml。儲存檔案並結束] 變更為 「 MSF 的 Agile 軟體開發加上 Bug 列，」 像 ProcessTemplate/中繼資料/名稱元素的值。開啟流程範本管理員，再按 [上載] 按鈕，然後選取 [包含已編輯的範本] 資料夾。新的範本會出現在清單中，其名稱與，給定它，且任何未來從此範本建立的專案會包含 Bug 列。

使用 [Bug] 列來決定允出準則

當然世界中的所有處理程序範本功能仍然 won’t 協助您除非您有組織的原則，以備份起來。在 Microsoft 內部開發小組的標準是 「 低 」 分類的 Bug 列上方落任何安全性 Bug 必須修正發行之前。這項標準是永遠不會放寬，不論如何關閉產品已釋放。這種方法可確保安全性 Bug 分級 objectivity 根據只可能效果和 Bug 的範圍。

這是理由我們定義個別的 BugBarSeverity 欄位，而非只限制根據 EffectScope 常見的嚴重性欄位的值。從嚴格的安全性觀點來看我們 don’t 在意如果產品隨附任何重大 Bug，只要這些 Bug 有沒有安全性影響的嚴重性。所有我們真的在意是 Bug 是否有 BugBarSeverity 高於 「 4 – 低 」。如果是這樣，該 Bug 必須修正發行之前。

即知即行

沒有一個一致、 客觀的程序分級安全性 Bug，您將無法建立安全的應用程式。使用 Microsoft 安全性 Bug 列是一個很好的方法，若要完成這個，程序，它 ’s 的安全性開發生命週期，已證實這樣可以降低的軟體弱點的主要元件。

此外，如果您使用 Microsoft Team Foundation Server，您可以輕易地將 Bug 列功能加入小組專案。這可以您甚至方便您的小組適當分類安全性 Bug 即使開發人員不一定是安全性專家。

最終的想法為我喜歡鼓勵您的 Visual Studio 2010 下載 MSF Agile + SDL 流程範本。這個流程範本將可免費在 microsoft.com/sdl 不久之後發行的 Visual Studio 2010。它結合了這份文件，以及許多其他功能，設計來幫助您建立更安全的軟體所述的 Bug 列。

Bryan Sullivan 是安全性程式管理員為 Microsoft 安全性開發生命週期小組他專門在 Web 應用程式和.NET 安全性問題。他是 「 艾傑克斯安全性 」 (Addison-Wesley，2007年) 作者。

多虧給下列技術專家來檢閱這份文件： Brian Harry