每一份 curl 安全报告都始于有人在https://hackerone.com/curl上向我们提交问题。报告者会告诉我们他们怀疑的问题以及他们认为的问题所在。这份报告将保持私密，只有 curl 安全团队和报告者在我们处理报告期间才能看到。
最近几个月，我们每周都会收到3-4份安全报告。该项目已运行六年多，累计报告近600份。
平均而言，团队中的某个人会在第一个小时内对该报告做出第一反应。
评估
目前，curl 安全团队由七名经验丰富的资深维护人员组成。我们会立即开始分析和评估收到的问题及其声明。大多数报告并未指出真正的安全问题，而是被迅速驳回并关闭。其中一些报告指出了并非安全问题的普通 bug，因此我们会将讨论转移到公共 bug 跟踪器上。
这部分可能需要几个小时甚至几天的时间，并且通常需要几名 curl 安全团队成员的参与。
如果我们认为该问题可能有价值，我们会提出后续问题，测试可重现的代码并与报告者讨论。
有效的
收到的报告中，只有一小部分真正被视为有效的安全漏洞。我们会与报告者合作，深入了解触发漏洞的具体条件以及漏洞可能导致的后果。我们会共同设定问题的严重程度（低、中、高、严重），并制定首个补丁——这也有助于确保我们充分理解问题所在。除非问题被认为非常严重，否则我们倾向于将新漏洞的发布与即将发布的下一个版本同步。我们的正常发布周期为八周，因此距离下一个版本发布间隔绝不会超过 56 天。
使固定
对于我们认为严重程度低或中等的安全问题，我们会在公共存储库中为该问题创建一个拉取请求 – 但我们不会在公开交流中提及问题的安全角度。通过这种方式，我们还可以确保修复程序在即将发布的下一个版本之前获得更多的测试曝光和时间进行完善。在过去五年左右的时间里，在大约八十个已确认的安全漏洞中，只有两个被评为高于中等的严重程度。我们认为严重程度高或严重的漏洞的修复程序会在即将发布的版本还剩下大约 48 小时时合并到 git 存储库中 – 以限制在正式发布之前的曝光时间。我们需要在发布之前将其合并到公共中，因为我们的整个测试基础设施和验证系统都基于公共源代码。
咨询
接下来，我们会撰写一份详细的安全公告，解释问题所在，并详细说明错误所在及其可能导致的后果——包括我们能想到的所有相关细节。公告内容包括受影响的 curl 版本的版本范围、引发问题的确切 git 提交以及修复问题的提交，此外还会注明报告者和补丁作者等。我们致力于提供业内最佳的安全公告。（我们也在网站上提供 JSON 格式等，以满足少数关心此类信息的用户的需求。）当然，我们也希望最初的报告者也参与其中，以确保我们能够准确涵盖问题的各个方面。
漏洞漏洞
由于我们是 CNA（CVE 编号机构），我们自己保留和管理我们自己问题的 CVE ID。
预先通知
在我们即将发布 CVE 的版本发布前大约一周，我们会将问题（包括修复方案）及其发布时间通知distros@openwall 邮件列表。这给开源操作系统一些时间来准备其版本并适应我们即将发布的 CVE。
发布
在发布日，我们会发布 CVE 详情并发布版本。之后，我们还会关闭 HackerOne 报告并向全世界公开。为了最大程度地提高透明度和开放性，我们会在关闭后公开所有 HackerOne 报告。我们还会将新的 CVE 通知所有curl 邮件列表和oss-security 邮件列表。当然，有时我们会针对同一版本发布多个 CVE。
赏金
一旦 HackerOne 报告被关闭并向全世界披露，漏洞报告者就可以从Internet Bug Bounty申请漏洞赏金，该赏金将根据 curl 漏洞的严重程度向研究人员支付一定数额的金钱。
（本博文使用的原文是我之前为 Help Net Security 所做的采访中提供的。这里进行了调整和略微扩展。）
团队
通常默默无闻、不费吹灰之力完成所有这些工作的 curl 安全团队中的英雄们目前是（排名不分先后）：
- 马克斯·戴蒙德
- 丹·范德里希
- 丹尼尔·古斯塔夫森
- 詹姆斯·富勒
- 维克托·萨卡特斯
- 斯蒂芬·艾辛
- 丹尼尔·斯坦伯格
原文： https://daniel.haxx.se/blog/2025/09/18/from-suspicion-to-published-curl-cve/