CVSS 是通用漏洞评分系统 (Common Vulnerability Scoring System)的缩写，根据维基百科，CVSS 是用于评估计算系统漏洞严重性的技术标准。
通常，您使用在线 CVSS 计算器，单击几个复选框和单选按钮，然后您会神奇地得到 0 到 10 之间的数字。CVSS 也有不同版本。
提交给 MITRE 的每个 CVE 都应该有一个 CVSS 分数集。注册的 CVE 缺乏此信息，ADP（授权数据发布者）将对其进行“修改”，并将其视为自己的工作。 NVD过去就是这样做的。现在CISA已经做到了。下面详细介绍这一点。
问题
假设您编写了一个进行互联网传输的工具和库。它们几乎无处不在，在无数的环境中使用，并且具有几乎不可能数量的不同构建组合、目标操作系统和 CPU 架构。我们称之为卷曲。
当您在该产品中发现理论上的安全问题（理论上是因为大多数问题实际上从未被发现被利用）时，它有多严重？ CVSS 计算具有一组有限的输入因子，这些因子往往会导致网络产品的数字相当高。如果我们可以猜测该问题仅由少数人使用或仅影响不寻常的平台怎么办？不包括在内。
CVSS 评分实际上是为您准确了解产品的使用时间和方式以及缺陷的利用如何影响产品而设计的。那么它至少可能有效。对于在超过 200 亿个安装中运行的 tarball 中提供的通用代码库来说，这样做的效果要少一些。
如果您环顾四周，您可以轻松找到许多其他（更长）关于 CVSS 问题和挑战的文章。我们并不是唯一有这种想法的人。
使用CVSS
与此同时，安全扫描仪的受欢迎程度在过去几年中似乎显着增加。这种产品会扫描您的系统，检查是否存在易受攻击的产品，并在出现问题时向您显示重要警报和警告。
此类程序会查找产品，计算出版本号，然后在找到该产品的已注册 CVE 以及 CVSS 分数高于特定阈值的版本时发出警报。
此类产品间接诱骗用户删除操作系统组件以消除这些警报。我们甚至听说有合同协议的人说他们必须在 N 个工作日内解决这些警报，否则将面临后果。
就在几天前，macOS 用户联系了我，他们担心他们的扫描仪在 Apple 发布的 libcurl 版本中发现了一个 curl CVE。他们的工具是对还是错？您认为参与该过程的任何人实际上都能知道吗？你认为苹果在乎吗？
卷曲跳过 CVSS
在curl项目中，我们已经放弃尝试使用CVSS来获取严重性分数和相关的严重性。
相反，在curl 安全团队中，我们努力将所有知识整合在一起，并通过将其分为四个级别之一来粗略地指示严重性：低、中、高、严重。
我们相信，因为我们不受任何（有缺陷和有限的）计算器的束缚，并且因为我们非常熟悉代码库及其使用方式，所以我们可以通过这种方式评估和设置更好的安全严重性。它更好地为我们的用户服务。
我们仍然使用这四个级别的部分原因是我们的bug 赏金的奖励级别是基于级别的。
作为比较，Linux 内核甚至没有提供课程粒度的指示，基于与我们不提供数字分数类似的推理。
这没有得到很好的对待
curl 项目是一个CNA ，这意味着我们保留自己的 CVE Id 并将其发布到 CVE 数据库。没有中间人干扰，事实上，在我们不知情且没有发言权的情况下，其他人都无法再提交curl CVE 条目。那挺好的。
然而，CVE 系统本身建立在每个缺陷都有 CVSS 分数的理念之上。当像我们这样的人创建没有分数的 CVE 条目时，就会留下一些显然被认为是系统中需要“修复”的裂口疮。
谁来“解决”这个问题？
授权数据发布者
不久前，这个新角色被添加到 CVE 生态系统中，称为 ADP。这项工作以前是由 NVD 临时完成的，但方式大致相同，NVD 会获取所有 CVE，对其进行编辑，然后将其连同添加内容一起发布到全世界。全世界都非常喜欢这一点并使用了 NVD 数据库。
然而，NVD 却被这项繁重的工作淹没了，取而代之的是 CISA，CISA 是一个“ADP”，因此可以丰富数据库中他们认为需要“改进”的 CVE 条目。
他们似乎检测并帮助“修复”的主要问题是已发布的 CVE 条目中缺少 CVSS。就像每一个卷曲 CVE 一样，因为我们不参加 CVSS 舞蹈。
没有任何线索，但必须得到一个分数
与之前 NVD 这样做时该系统被破坏的方式完全相同，当 CISA 这样做时，这个新系统也被破坏。
我不知道他们对多少 CVE 条目进行了这种“丰富”（去年有超过 40,000 个 CVE，但其中一定数量的 CVE 已由其 CNA 提交了 CVSS）。我认为可以安全地假设数量很大，而且由于它们是针对各种类别的产品提交的，因此 CISA 肯定不可能拥有每个 CVE 描述和影响的许多产品和技术的专家。
因此：在时间有限且不真正了解问题是什么的情况下，该团队中的个人单击 CVSS 计算器中的一些按钮，获得分数、严重性，然后（大概）快速处理下一个问题。还有下一个。还有下一个。在源源不断的安全问题中。
到底怎么会有人指望他们能做到这一点呢？我的意思是，在某些甚至很多情况下，他们可能会因为运气、技能或其他原因而接近，但系统的构建方式肯定会令人尖叫：这最终会经常出现疯狂的错误。
最近的一个例子
2024 年底，我从朋友那里得知，几个与 infosec 相关的网站发布了一个新的与 curl 相关的严重安全问题。由于自 2013 年以来我们没有宣布任何严重的安全问题，这当然引起了我的兴趣，所以我看了一下。
事实证明，CISA 决定CVE-2024-11053应该获得 CVSS 9.1 评分：“严重”，现在扫描仪和新闻媒体已经弄清楚了这一点。或者很快就会。
由于低风险和特殊情况是问题发生的先决条件，curl 安全团队已将严重性设置为“低”。你自己去读一下——开源产品的 CVE 的好处是，源代码、修复程序和所有内容都可供我们随意阅读和检查。
知道这段代码并完全理解安全问题的实际专家团队表示“低”。 CISA 团队推翻了这一观点，坚持认为这些都是错误的，而且这个问题有可能破坏互联网。因为我们显然不惜一切代价需要 CVSS。
一个 git 存储库
从 NVD 切换到 CISA 带来的一项积极变化是，他们现在将附加数据托管在GitHub 存储库中。当我意识到这个疯狂的 9.1 分数后，我利用周日下午的时间与家人在一起，并在那里提出了一个 Pull 请求，敦促他们至少将分数降低到 5.3。这是我可以让计算器告诉我的分数。
我希望尽快对这个问题进行分类和解决，如果可能的话，降低各地的安全扫描仪很快就开始对此问题发出警报的风险，而我们会因为来自忧心忡忡的用户的查询而不堪重负。
当用户这样做时，忧心忡忡的用户不会让 CISA 超负荷。他们的无能只会给curl 项目带来负担。但可以肯定的是，他们添加了 CVSS。
在我发出拉取请求后，他们花了不到九十分钟的时间来 更新卷曲记录。在没有解释、没有参考我的 PR 的情况下，他们现在显然认为该问题是 CVSS 3.4。
我当然很高兴它不再被标记为关键。我想你们都清楚这种评分方法是多么随意和随机。
当然，发布初始不良分数的一个问题是，某些网站和系统在最初了解关键分数后确实很慢或在更新信息方面表现不佳。很长一段时间以来，都会有一些网站在谈论这个“关键”的卷曲错误。感谢中西协！
我们能避免这种情况吗？
在curl安全团队中，我们讨论了在我们的CVE条目上设置“固定”（假）分数，只是为了防止CISA或其他任何人破坏它们，但我们决定不这样做，因为这接近于对它们撒谎，我们实际上，我们非常努力地工作，以确保我们的一切都正确且细致地描述。
所以不，由于我们不进行 CVSS 舞蹈，不幸的是，我们将继续让 CISA 对我们这样做。
停止强制 CVSS？
当然，我在 CNA 生态系统中强烈主张我们应该能够阻止 CISA 这样做，但我只是一台非常大的机器上的一个小齿轮。似乎很喜欢CVSS的大型机器。我预计短期内不会在这一领域取得太大成功。
不，我认为切换到 CVSS 4.0 或更新该系统最终不会对我们有帮助。问题的根源在于单个一维分数太有限了。项目的每个用户或分发者都应该为其不同的用例设置分数。对于不同的情况甚至可能有不同的。那么它也许可以发挥作用。
但我参加这场比赛并不是为了快速获胜。我正在为更好的（开源）安全信息而努力，并阻止安全错误信息。对于更广泛的生态系统来说是理想的选择，因为我认为我们在这种情况下并不孤单。
对 CVSS 的热爱是强烈的，并且基于此并依赖于此涉及大量资金。
原文： https://daniel.haxx.se/blog/2025/01/23/cvss-is-dead-to-us/