向Microsoft Team Foundation Server 2010中添加安全错误评级

向Microsoft Team Foundation Server 2010中添加安全错误评级2011-08-29 MSDN Bryan Sullivan软件开发团队在其产品生命周期过程中面临的一项最有争议的任务就是会审错误。对于产品开发中涉及的每个人来说，确定任何给定错误的相对重要性级别（进而确定该错误在发布之前无法及时修复的可能性）都是一件严肃的事情。

编程人员、测试人员、架构师和项目经理都有不同观点，并且其各自的会审决策以下面一些分散的因素为基础：

修复后，有多少代码必须进行回归测试。

距离发布项目有多长时间。

多少用户会受到更改的影响。

错误是否阻止了其他问题的测试或修复。

我承认，在会审产品功能中的功能错误时，这些都是重要的考虑因素。不过，在确定是否修复安全错误（也就是可能导致产品中出现安全漏洞的错误）时，这些不应作为考虑因素。安全错误的分类必须客观一致。对于一名攻击者来说，您是否是在代码完成里程碑的前一周发现的漏洞无关紧要，因为攻击者会同样地利用这个漏洞。

本专栏介绍由 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 所示。