curl 与 MITRE 的 CVE 争议终局
A CVE Dispute
作为 curl 项目的 CNA，我们拥有自主分配 CVE 的权力。面对一个需要本地攻击者配合、且涉及非法 DNS 主机名的极低概率漏洞，我们决定不分配 CVE，以避免引发全球三十亿次安装的无谓更新。然而，报告人坚持认为应分配 CVE 并向 MITRE 发起申诉。经过数月的反复沟通与审核，MITRE TL-Root 最终裁定支持我们的判断：这只是一个已修复的 Bug，而非安全漏洞。这一案例再次提醒我们，在安全生态中，负责任地评估风险比盲目发布警报更为重要。
我们应当负责任地行动，既要绝不忽视真实的问题，也要确保不为那些理论上存在却不会触发任何漏洞的问题拉响警报。
HN 评论区
41- ealready_value
> 每个 CVE 背后都伴随着巨大的成本。这笔成本并未直接落在我们身上，我们也未必能真切感知，但我认为这是整个生态系统必须正视的成本。
我真的很欣赏这种态度，因为它承认了现实中有很多安全团队对 CVE 缺乏 nuanced（细致入微）的理解。举个例子，曾有一次，某安全团队要求我们修复一个默认安装在 Ubuntu 上的 VMware 支持包，但该 CVE 的触发条件是需要运行在 VMware 环境下，而我们当时是在 EC2 上运行。跟他们争论毫无意义，因为他们根本不在乎这个 CVE 是否适用于我们，只在乎必须修复它。
许多本应负责安全的团队从不问“这个 CVE 是否影响我们”，只是简单地将修复的负担向下、向外转移。在某些情况下，比如针对易于更新和集中部署的 SaaS 产品，这种负担更多是令人恼火和沮丧，而非困难重重。但在另一些情况下，比如部署流程复杂或更新由客户控制时，这些强制要求会给那些并未参与决定是否修复每个低优先级 CVE 的团队带来巨大负担。
- Aurornis
如果能公开此人为了对抗这个问题而发给 MITRE 的部分邮件往来，应该会很有启发性。
我们都熟悉有人用 LLM 写代码并提交 PR，但现在出现了一个日益严重的问题：人们开始利用 LLM 不知疲倦地通过邮件等沟通方式去“战斗”，甚至有人建议用 LLM 生成实体纸质文件。
如今，与机构争辩某事的成本已趋近于零，越来越多人开始让他们的 LLM 和工具替他们去“打仗”。这感觉对他们来说成本极低，但只要存在非零的个人获利可能，他们就会去尝试。我听到很多故事，从地方政府到大学行政部门，都被源源不断的请求压得喘不过气，这些请求来自那些锲而不舍的发送者，他们认为只要尝试就值得，哪怕获批的可能性为零。
我想，我们不得不重新审视许多以往依赖“大多数人不会费力去争取自己不该得的东西”这一事实的沟通和请求系统。当争辩的成本趋近于零时，机器就会不断尝试，只为博取那非零的成功几率。
- rwmj
目前的激励机制真的非常糟糕。传统上，你的名字出现在像 curl 这样重要项目的 CVE 上，在社区里会有一定的声望。你甚至可能借此争取加薪或更好的工作机会，所以金钱因素肯定在其中。
现在，很多人把代码扔给 LLM，然后直接把生成的内容复制粘贴成“安全”报告。
我们决定，对于我们的项目，任何由 LLM 生成的安全报告都直接复制到公开列表中。既然大家都能用 LLM，那么如果一个 LLM 实例发现了问题，所有 LLM 用户迟早也会发现。如果问题重要，我们会修复，但目前的信噪比非常差。
我认为，从长远来看，随着那些显而易见的低垂果实被找出并修复，服务的安全性会提高。但不幸的是，我看不出 LLM 生成的废话洪流在短期内会停止。
- woodruffw
这种地狱般的经历是 CVE 系统试图“既要又要”的绝佳例证：在进攻时，它是防御者丰富的信息来源；而在防守时，它只是一个不透明的协调 ID，暗示不了底层报告的质量或正确性。
- cynicalsecurity
肯定有人是铁了心要把这个写进简历里。