Tony Cox 和 Jeff Lowder 对CVSS提供了一些出色的评论（事实上​​ SIRA 包含很多很好的讨论）。他们的目标比您的目标更广泛，但我认为引用的文章提供了关于 CVSS 评论的索引。@Metahuman 的帖子指出可以补充 CVSS。

美国国务院的iPost 系统 发现 CVSS 评分高估了不重要风险的价值；如果我没记错的话，他们只是简单地将这些值乘以强调严肃的东西。State 的 iPost 是 DHS CAESARS的模型（尽管根据国务院监察长的说法是一个有缺陷的模型）-但这两者都比您的目标更具架构性。

CVSS 是一个有缺陷的标准——我知道人们正在积极努力对其进行修订/改革。评级中存在相当大的主观性——我目前找不到参考，但有人进行了一项测试，他们向几位专家提供了有关漏洞的相同信息，他们使用了 CVSS 流程，但得出的答案却大相径庭。但这是一个标准。对于像您这样正在寻找参考标准而无需创建自己的方法论的项目来说，这是一个很好的起点。您可以使用 CVSS（和 CWE）作为起点，然后执行 @Colin Cassidy 所说的“魔法数学”。

CVSS 以系统为中心；它忽略了架构安全功能，并且可能低估了以网络/云为交付媒介的漏洞。我想查看OWASP和Veris，以获取有关现实世界漏洞利用而非理论模型的更多统计信息。

我可能不会忽略环境指标；实际上，从中期来看，我会使用 CVSS 的组件来开始滚动您自己的漏洞评分，该评分更符合您的需求。

我们使用基于 DREAD 的评分系统，我们对 5 个元素进行评分

• 伤害，漏洞有多严重
• 可靠性，漏洞是一直有效还是仅在某些时候有效
• 可利用性，利用漏洞需要付出多少努力
• 受影响的用户，受影响的人数
• 可发现性，发现这个漏洞有多容易

满分 5 分，我们已经大致定义了 1 到 5 分对我们的产品和这些类别的意义。然后我们做一些神奇的数学运算来得出漏洞的严重性和优先级。有关详细信息，请参阅David LeBlanc 的帖子。我们发现这种方法有几个优点，首先我们可以说明分数对我们的产品意味着什么，其次它非常容易让经理理解:)

根据您的要求，您可能需要查看常见弱点枚举 (CWE)。http://cwe.mitre.org/about/index.html。

它是一个社区支持的解决方案，用于描述软件安全漏洞，并作为漏洞修复活动的基准。

CVSS 是评估漏洞的合理系统，也是确定可能的技术影响的良好框架，但它只是故事的一部分。对企业而言，重要的是如果漏洞被利用或系统出现故障，它可能会损失多少钱。如果可以引入可用于创建轻微拒绝服务条件的漏洞，那么它对公司造成的损失将小于可用于创建虚假订单的漏洞。

管理层以货币单位进行思考，因此您必须以货币损失来表达风险。开发需要公司的钱，他们不会修复错误，除非潜在的损失大于修复错误的开发成本。