軟件團隊在缺陷分級會議上常陷入主觀爭論:開發覺得「下周發布來不及修」、測試認為「管理員賬號被盜很嚴重」、項目經理權衡「回歸成本」。Microsoft 內部採用的 Security Bug Bar (安全錯誤評級) 以 STRIDE 威脅模型 + 客戶端/服務端範圍 為唯一判斷標準,徹底消除主觀性。本文詳細講解評級體系並指導如何通過修改 MSF-Agile 過程模板將其集成到 TFS 2010。
早期 DREAD 模型 (損壞性/可再現性/可利用性/受影響用戶/可發現性) 打分高度主觀:同一 SQL 注入漏洞,開發打 3.8,測試打 10.0。Bug Bar 改用 STRIDE 分類 + 具體範圍屬性 直接映射到四級嚴重度:Critical (關鍵) / Important (重要) / Moderate (一般) / Low (低)。
| STRIDE | 端點 | 範圍描述 | 嚴重度 |
|---|---|---|---|
| Elevation of Privilege | Server | 遠程匿名用戶可執行任意代碼 | Critical |
| Elevation of Privilege | Client | 遠程用戶可執行任意代碼 | Critical |
| Spoofing | Client | 偽造受信任 UI 用於常見信任決策 | Important |
| Denial of Service | Server | 匿名、易利用、導致永久 DoS | Important |
| Information Disclosure | Server | 攻擊者可從任意位置讀取敏感數據 | Important |
| Tampering | Client | 永久修改常見場景下的信任決策數據 | Important |
| ... | ... | 其他組合映射到 Moderate / Low |
完整評級表含 30+ 種組合,文中附圖完整展示。
MSF for Agile Software Development v5.0\WorkItem Tracking\TypeDefinitions\Bug.xml<FIELD name="Effect" refname="MSDN.SDL.Security.Effect" type="String" reportable="dimension">
<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>
<FIELD name="EffectScope" refname="MSDN.SDL.Security.Effect.Scope" type="String" reportable="dimension">
<ALLOWEDVALUES> ... 30+ 範圍值 ... </ALLOWEDVALUES>
<DEFAULT from="value" value="Not Applicable" />
<!-- WHEN 子句根據 Effect 動態過濾 Scope 值 -->
</FIELD>
<FIELD name="BugBarSeverity" refname="MSDN.SDL.Security.Severity.BugBar" type="String" reportable="dimension">
<!-- 無 ALLOWEDVALUES,完全由 WHEN + COPY 自動賦值 -->
<WHEN field="MSDN.SDL.Security.Effect.Scope" value="Server - Anonymous RCE">
<COPY from="value" value="1 - Critical" />
</WHEN>
<!-- 其他映射 -->
</FIELD>
<FIELD name="Severity" refname="Microsoft.VSTS.Common.Severity">
<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>
<Tab Label="Security">
<Control FieldName="MSDN.SDL.Security.Effect" Type="FieldControl" Label="Effect" LabelPosition="Top" />
<Control FieldName="MSDN.SDL.Security.Effect.Scope" Type="FieldControl" Label="Scope" LabelPosition="Top" />
<Control FieldName="MSDN.SDL.Security.Severity.BugBar" Type="FieldControl" Label="Bug Bar Rating" ReadOnly="True" LabelPosition="Top" />
</Tab>
刪除舊模板並上傳新版,或重命名上傳為 MSF for Agile + Bug Bar 並存。
Microsoft 內部鐵律:任何高於 Low 級別的安全錯誤,無論距離發布多近,必須修復後才能發布。這正是分離 BugBarSeverity 與業務 Severity 的原因——業務可上調嚴重度,但不可下調安全基線。
客觀、可審計、可自動化的安全缺陷分級,是 SDL 落地的關鍵一環。