curl 把低危漏洞的披露搬到 GitHub 公开进行：一场被报告淹没的自救

curl 项目改了漏洞披露流程：从这次调整开始，被判定为 LOW 或 MEDIUM 的漏洞报告不再走私密渠道，而是要求提交到项目的 GitHub 仓库，公开讨论、公开修复。只有 HIGH 和 CRITICAL 级别的报告继续留在 HackerOne 的私密跟踪系统里。

这个决定和"更开放"的技术理想关系不大，起因是**撑不住了**。

发生了什么

作者 Daniel Stenberg 给出的理由很直接：报告像雪崩一样涌进来，看不到头，也不认为未来几个月会减少。核心维护者普遍处于过载状态，项目必须做点什么才能活下去。他的原话大意是：这不是最后一次调整，我们只想不被淹死。

一个关键数字：过去几年里，提交上来的报告有 **90% 以上**能很快被判定为低于 HIGH。也就是说，绝大多数工单走完了完整私密流程，消耗的却是维护者最紧张的注意力。

新流程下，如果研究者不确定严重程度，仍然可以先提到 HackerOne，由维护者判断；被判为 LOW / MEDIUM 的，会被要求在 GitHub 重新提交，原工单按"信息性"关闭并公开。

作者也提到一个当下很明显的变化：每次公布一批 CVE 和补丁，就会有一批用 AI 的研究者把补丁丢给模型，去找相似或遗漏的错误。把流程搬到公开场合，理论上能让这种"众包式复核"更有效。

公开意味着漏洞细节对所有人同时可见，恶意一方也会多出一段可利用的窗口。作者承认这是无法回避的损失，并把范围限制在"低于 HIGH"——至少这些问题不算灾难级。

有人担心研究者会误判，把 HIGH 级别的报告提交到公开仓库。作者认为这种场景基本没出现过：真实的高危问题，提交者自己通常也不会有把握当成低危处理；而且公开提交漏洞的风险本来就存在，不是新引入的。

也有人提议干脆不再受理 LOW 级别。这条路走不通：CVE 体系里有申诉机制，curl 不发的 CVE，别人照样会发，问题最终还是回来。

文章里最有信息量的一段，是对报告质量变化的观察。现在大量新报告是 AI 模型折腾出来的：把 libcurl 的各种选项、协议组合和宽松的 API 拼出人意料的序列，跑出"没文档写过的行为"，然后被当成漏洞提交。

但这些组合在真实世界里几乎不会被用到，真有人这么用，应用自己早就炸了。作者的判断是：为这类问题走完 CVE 流程，救不了任何用户，只是给维护者和整个下游增加工作量。libcurl 的选项与协议组合近乎无限，模型可以一直试下去，而人的精力是有限的。

所以除了改流程，他也表态会更硬地拒绝那些"确实不构成实际危害"的报告，并给出更清晰的严重程度判定指引。

依赖 curl 的项目要习惯一件事：以后部分安全问题会先出现在 GitHub issue 里，而不是某天突然收到一份带 CVE 编号的公告。想第一时间跟进，盯 issue 比等公告更快。

对做安全工具的人来说，这篇文章也是一面镜子：自动化能把"发现异常"的成本降到接近零，但**判断异常是否构成风险**的成本并没有下降，最后全都压在维护者身上。开源项目迟早都要面对这道算术题。