Replacing CVE

2025 年 4 月 16 日 技术：职业化

目录

  1. 简介
  2. 问题
  3. 解决方案 1. 用属性代替分数 2. 专业认证和强制报告 3. 准确性
  4. FOSS
  5. 守门
  6. 结论

假定读者: 程序员和网络安全行业的其他人员。 认知状态: 有信心。 tl;dr : 行业需要专业的认证和责任，以针对不报告漏洞的行为。

简介

我不知道你是否看到了新闻，但 MITRE 的 CVE 政府合同今天即将到期（直到 他们得到了喘息之机）。 正如技术人员经常做的那样，并且由于当前政府被大多数技术人员所憎恨，他们对此感到愤怒。 让我首先说明：我不会评论这种情况的政治性。 相反，我可以建议我们有一个机会，即使有了喘息之机？

问题

CVE 系统在保护我们的基础设施方面不如给一些最重要的项目带来麻烦。 Curl 经常收到虚假的 CVE，并且必须花费宝贵的时间来处理它们。 Postgresql 也是如此。 Linux 内核走了另一条路，只是 大量发布 CVE，以至于内核 CVE 本质上变得毫无价值。 毫无价值？这是否意味着 CVE 实际上对人们有价值？ 是的，绝对。那些认为自己是“安全研究人员”的脚本小子试图在大型项目中找到错误，然后将它们标记为 CVE，以便他们可以 将这些 CVE 添加到他们的简历中。正如 Hacker News 上的一位用户所说，“不幸的是，CVE 数据库过于嘈杂，无法使用。” 事实上，情况变得如此糟糕，以至于 Curl 决定做 额外的工作 来 成为 CNA，只是为了拒绝虚假报告并避免 NVD 给出过高的漏洞评分。 因为 Daniel Stenberg，Curl 的负责人，一直在 博客中非常活跃，人们很清楚 Curl 的情况。 lobste.rs 故事的第一个评论说：

终于让 Daniel Stenberg (curl 的原始作者和维护者) 松了一口气

– BenjaminRi

解决方案

作为回复，一位名为 insanitybit 的 lobste.rs 用户 这样说：

两种情况会发生。

  1. 我们最终会得到一个像 CVE 这样的系统，提交者负责数据库中的内容，除非出现非常恶劣的情况。 除非有人成为 CNA，否则这是 MITRE 支持的默认设置，他们最近几年更自由地分发 CNA，以应对公众的审查。
  2. 我们最终会得到一个不像 CVE 的系统，供应商负责什么是漏洞。 这似乎是 Daniel 和其他人想要的。

(1) 并不理想，(2) 历史上一直很糟糕。 我们有 (1) 的原因是，历史上，供应商对漏洞的反应很糟糕，这就是为什么 antisec 和 public 0day drops 是解决问题的方式。 不久前的情况就是这样 - 公开丢弃 0day 以羞辱供应商修复问题。 我认为从 (1) 开始并修复它比从 (2) 开始并修复它容易得多。 事实上，Curl 已经是它自己的 CNA，所以 Daniel 已经拥有了他想要的东西。 – insanitybit 我认为 insanitybit 唯一错误的是提出的解决方案： 我认为从 (1) 开始并修复它比从 (2) 开始并修复它容易得多。 如果您必须从“坏”开始并修复它，至少在网络安全方面，您已经输了。 相反，让我们弄清楚什么 会 起作用，所有的激励措施都对齐，并实现它。

用属性代替分数

首先，像 CVSS 这样的线性“分数”在网络安全中根本无法工作。 相反，我们应该有一个基于漏洞 属性 的系统。 在您说这不可能之前，我认为我们作为一个行业已经有足够的经验来获得一个好的 开始。 例如，两个属性类别怎么样：漏洞 需要 才能被利用，以及利用漏洞时 会发生什么。 在第一类中，我们可能有这样的属性：

在第二类中，我们可能有这样的属性：

我认为我们可以从这些属性 开始，并在以后发现什么重要时添加更多属性。 “但是 Gavin！如果属性列表无限增长怎么办？” 这是有可能的，我确实希望列表会变得很大。 但是，虽然网络安全是一个很大的领域，但即使在我们这个竞争激烈、速度超快的行业中，OWASP Top Ten 的变化也很缓慢。 我只是认为漏洞的变体不足以担心属性列表的增长。 但即使它确实增长了，存储这些属性而不是分数也会使自动工具（例如当前使用 CVSS 的工具）在标记内容时更加复杂。 也许一家公司的服务器都与外部 Internet 隔离，并且它们不托管客户端。 他们不会关心必须在同一台机器上运行软件的漏洞，因此他们可以过滤掉这些漏洞。 另一方面，一家托管公司在具有网络访问权限的 VM 中运行客户端代码，可能会关心几乎所有内容。 每家公司和项目都可以自定义他们关心的漏洞。

专业认证和强制报告

问题的另一方面是围绕报告的激励措施。 公司不想报告漏洞，因为这会让他们看起来很糟糕。这可能会达到荒谬的程度。 所以是的，我明白了：我们不应该信任公司，甚至 FOSS 项目，进行自我报告。 除非……如果我们对不报告和弄错的处罚如此之大，以至于他们会竭尽全力这样做呢？ “但是 Gavin，我们该怎么做呢？欧盟 GDPR 和 DMA 的罚款还不足以阻止公司到目前为止！” 是的，对公司的罚款是不够的。 我同意。 那么，如果我们这样做，这些公司 根本无法开展业务 怎么办？ 这是方法：

  1. 我们为专业软件工程师 (PSWE) 创建一个专业认证。 如果 PSWE 行为不当或疏忽，则此认证必须可以撤销。
  2. 在其他事情 中，我们将疏忽定义为未在特定时间窗口（90 天？）内准确报告漏洞。 这将确保 PSWE 会 绝对报告，因为他们不想失去他们的认证。
  3. 我们使某些类型的软件 需要 PSWE 作为 记录工程师。 请注意，我们 不应 特别要求该项目上的 每个人 都获得认证，只需负责人即可。 这是为了防止整个行业被把关。

这有一个很好的副作用，如果一家公司“解雇”或以其他方式摆脱了报告漏洞的 PSWE，他们雇用另一个人的能力可能会受到严重阻碍，因为其他 PSWE 会将该公司视为一个问题。 此外，此类“解雇”的 PSWE 可能会很容易在其他地方找到工作，因为获得认证对于很多事情都是必需的。 所有这些事情加在一起，虽然不 要求 漏洞报告，但会产生这种效果。 PSWE 可能的损失，这将阻止公司与该项目开展业务，这意味着不报告的 事实上的 惩罚将是业务的立即损失。 这比罚款 高得多。 如果企业可以开展业务，它就可以支付罚款。 如果它无法开展业务，它就会死亡。 因此，虽然它不像监禁高管那样严重，但我敢打赌它会使高管采取大致相同的行动。

准确性

另一方面是：报告需要多么准确？ 我认为属性系统会有所帮助。 每个属性都将是客观的，而不是主观的分数，我认为这应该是属性的 要求。 但是如果属性是客观的，并且纯粹描述 事实，那么 PSWE 必须 能够正确理解它们。 我认为这应该只在特定的时间窗口内适用，可能为 90 天。 如果没有人对报告的准确性提出异议，或者在该时间内发现报告是正确的，则应保持不变。 这应该可以防止未来的研究在事后更改报告，这意味着 PSWE 会失去许可证； 准确性应仅使用 当时 已知的事实来判断。 我个人会允许 PSWE 在一个属性上出错。 没有人是完美的。

FOSS

“但是 Gavin，FOSS 项目怎么样？他们需要 PSWE 吗？” 不需要，因为他们没有做生意。 我认为我们应该这样定义它：如果没有金钱交易，则不承担责任。 “但是这仅仅意味着公司只会对他们自己的东西承担责任，并尽可能多地使用 FOSS 来避免责任！” 仔细阅读上面的链接；它不会做任何这样的事情。 公司仍然要对其 整个 软件堆栈承担责任。 “但是这意味着公司将对他们不控制的东西（例如 Curl）承担责任。” 是的，但是这里的重点是：这些公司可以与这些项目达成交易，让这些项目承担责任，作为回报，这些项目会获得资金。 当然，这些项目需要在顶部有一个 PSWE，但我认为这是可行的。 然后，因为这些项目有一个付费的 PSWE，他们 将被要求准确报告漏洞。 换句话说，这不仅可以解决漏洞报告问题，还可以解决 FOSS 资金问题。

守门

“但是 Gavin！认证仍然是守门，会不公平地伤害那些处于不利地位的人。” 不一定。 我认为 专业机构 可以以这样一种方式建立，即要求当前的 PSWE 资助 想要 获得认证的人的教育、培训和认证：

现在，还会存在一些守门吗？ 是的。 可能有些 PSWE 不会适当地帮助或培训某些或所有学徒，但我们也可以解决这些问题：

很难找到平衡，但我认为如果我们从正确的角度出发，随着时间的推移，可以找到平衡。

结论

所以你明白了：我对当前 CVE 闹剧的解决方案。 主题是改变激励措施，我着迷于改变激励措施实际上如何一次性解决多个问题！ 如果您要问我，“以其之道，还治其身” 在于使某些事情对社会有益，也使该事情对所涉及的个人有益。 你可以说 “水涨船高。” 让我们在这里应用它。