curl漏洞赏金计划的结束 – 搞英语 → 看世界

简而言之：试图减少恐怖袭击报道。

curl漏洞赏金计划已经结束，将于2026年1月31日正式终止。

在经历了几次不成熟的尝试之后，我们在 2019 年 4 月借助 Hackerone 启动了第一个真正的 curl 漏洞赏金计划，虽然一开始遇到了一些困难，但我认为它已经相当成功了。

我们吸引了众多技术精湛的研究人员，他们报告了大量实际存在的漏洞，我们也为此支付了丰厚的奖金。这无疑直接提升了 curl 的性能：已确认 87 个漏洞，并向研究人员支付了超过 10 万美元的奖金。我对这项成就感到非常高兴和自豪。

我特别想强调一下出色的互联网漏洞赏金项目，多年来他们一直为我们支付漏洞赏金。没有他们的支持，我们根本无法完成这项工作。当然，还要感谢 HackerOne，多年来他们一直热情地为我们提供场地，并成为我们的合作伙伴。

谢谢！

我们是如何走到这一步的

回顾过去，我认为我们可以说漏洞赏金计划的衰落始于 2024 年下半年，但到了 2025 年急剧加速。

我们看到人工智能生成的劣质报告数量激增，同时，即使是那些看起来不像劣质报告的报告质量也下降了——大概是因为它们实际上也被人工智能误导了，只是这一事实隐藏得更好而已。

或许前五年让研究人员能够发现并报告那些容易发现的漏洞。此前几年，提交的漏洞中最终被确认的比例一直高于15%。但从2025年开始，这一比例骤降至5%以下。甚至连五分之一的漏洞都是错误的。

没完没了的垃圾投稿不仅让人精神疲惫，而且有时还需要花费大量时间去驳斥。这些时间和精力完全被浪费了，同时也打击了我们的生存意志。

我也开始觉得很多安全报告提交者都抱有恶意。这些所谓的“热心人士”极力把他们发现的任何问题都渲染成极其严重的漏洞，但他们很少真正为改进curl 做出贡献。他们会不遗余力地争论和坚持自己当前的发现，却不愿编写修复程序，也不愿与团队合作，从长远角度改进 curl 等等。我认为我们不需要更多这样的人。

促使我们采取这一步骤的三大不良趋势是：令人麻木的人工智能粗制滥造、人类表现比以往任何时候都更糟糕，以及人们似乎更倾向于挑毛病而不是提供帮助。

行动

为了改善 curl 安全报告糟糕的现状，我们采取了以下措施：

我们不再为安全举报提供任何金钱奖励——无论举报的严重程度如何。这是为了消除提交虚假举报信息的动机。
我们不再使用 HackerOne 作为报告安全问题的推荐渠道。这样做是为了让这一变化立即显现出来，而且由于没有漏洞赏金计划，我们也不再需要它了。
我们建议大家使用 GitHub 的私有漏洞报告功能，在 GitHub 上提交疑似 curl 安全问题。
我们将继续立即禁止并公开嘲笑所有向该项目提交人工智能垃圾代码的人。

维护 curl 安全性

我们相信，即便面临这一变化，我们也能维持并持续改进卷曲安全性。或许还能因此有所提升，因为希望这一举措能帮助防止更多人误将沙子倒入机器。理想情况下，我们希望减少浪费的时间和精力。

我相信，最优秀、最受我们重视的安全报告员仍然会在发现安全漏洞时及时告知我们。

反而

如果您怀疑 curl 存在安全问题，我们建议您前往 GitHub 并在那里提交问题报告。

或者，您可以将完整报告通过电子邮件发送至security @ curl.se 。

这两种情况下，报告都会由curl安全团队私下接收和处理，但不会提供任何金钱奖励。

离开 HackerOne

HackerOne 对我们很好，多年来他们一直慷慨地允许我们免费在他们的平台上运行我们的程序。我们感谢他们提供的这项服务。

取消奖励后，我们认为这能更清晰地表明立场，并向所有相关人员传递更明确的信息，同时也意味着我们将不再使用 HackerOne 作为漏洞报告平台。这使得这一改变更加显而易见。

未来披露

我们可能很难像过去一年在 HackerOne 上那样，公开披露每一份收到的安全报告。我们需要找到一些方法，确保至少能够以不完美的方式继续这样做，因为我相信这种透明度的好处。

我们继续使用 GitHub。

我想强调的是，此次变更不会影响我们对 curl 代码库及其在 GitHub 上的托管的维护和运营模式。我们也听说过一些项目在 GitHub 上提交低质量的 AI 代码（以 issues 和 pull request 的形式出现）时遇到问题，但 curl 目前还没有出现这种情况——坦白说，我认为切换到 GitHub 的替代方案也无法避免这个问题。

其他项目做得更好。

与其他项目相比，我们似乎更容易受到漏洞百出的安全报告的影响，这比一般的开源项目要严重得多。

借助 HackerOne 的数据，我们对比了 curl 漏洞赏金计划过去一年与其他计划的对比情况。结果显示，curl 的漏洞赏金计划比同类其他开源漏洞赏金计划的参与度更高，参与人数也更多。过去四个季度，curl 的漏洞报告数量显著增长，而同类其他开源漏洞赏金计划（例如 Ruby、Node 和 Rails）的参与度则没有显著提升，大多保持平稳或略有下降。图中，粉色线代表 curl 的漏洞报告数量，灰色线则代表同类计划的整体情况。

HackerOne上的入站报告量：curl与开源软件同行的比较

我们怀疑，从中获利的想法是造成这种情况的主要原因。它确实能带来真实的举报，但也使得恶意举报变得过于容易，用户几乎不会受到任何惩罚。信誉系统和现有的程序设置不足以阻止沙子进入机器。

我们比其他人更容易遭受这种虐待的确切原因，仍有待进一步推测和研究。

如果音量持续

我们的猜测有误，即使这些变化生效后，交易量和安全报告频率仍有可能保持不变，这种风险并非为零。

如果这种情况发生，我们会到时处理并采取进一步的适当措施。我不想现在就为一件最好不要发生的事情过度准备或过度规划。

我们不会收费

人们不断建议，应对漏洞报告海量问题的一种方法是向安全研究人员收取少量费用，作为向我们提交漏洞报告的“特权”。这就好比一个收取入会费的漏洞报告员安全俱乐部。

我认为这不如直接取消赏金来得好。原因包括：

在国际环境下向人们收费是一件复杂且耗费精力的事情。
处理拒付、退货和其他投诉和摩擦会增加工作量。
这将限制哪些人可以或愿意提交问题，甚至包括一些真正能发现合理问题的人。

也许以后我们还是需要做这件事，但现在我们先别管它。

拉取请求的问题不大。

我们看到其他项目和代码库也遇到过类似的 AI 引发的拉取请求问题，但 curl 项目并没有遇到这个问题。我认为，对于拉取请求，我们有更好的自动化方法来筛选掉不合格的内容，因为我们有工具、测试和扫描器来验证这些贡献。在拉取请求的质量达到 200 个持续集成 (CI) 作业都通过验证之前，我们无需浪费任何人工时间。