Curl 调整漏洞披露政策：低危中危漏洞改为公开报告

开源开发者的脆弱性披露政策刚刚发生了一件非常重要的事。不，不是PHP那一周的烂摊子。

我说的是Curl刚刚做的一件事，这件事可能不会在任何地方上新闻，因为对大多数人来说它并不太容易理解。Curl刚刚宣布，所有低危和中危的安全报告都应提交到公开的问题追踪器中，而不是私下报告。

curl漏洞披露政策的基本思路是，对于被评定为低危和中危的漏洞，将像普通bug一样处理，而不是当作需要额外关注的特殊bug。我认为这是个好主意，我们应该鼓励开源项目采纳类似的政策。开源项目正被漏洞报告淹没，这应该有助于减轻一些压力。

首先，什么是embargo（禁运期）？在安全漏洞的世界里，有一个我们称之为embargo的概念。如果有人发现了某个东西的安全漏洞——开源的、闭源的，什么都无所谓——你会私下向供应商/项目报告，给他们一些时间来修复漏洞。这对安全bug来说是合理的，目的是在漏洞公开、攻击者开始弹shell之前有时间准备好修复。

我们几乎对所有漏洞都这么做。即使是那些非常无聊的漏洞。每个项目、每个供应商、所有东西。一直以来都是这么做的，所以我们就继续这么做。当每年只报告几百个漏洞的时候，这是合理的。而现在我们每天都有几百个CVE被报告。已经不是2005年了，我们不能再假装还是。

你的第一反应可能是“私下报告不是更好吗？”——而这里就进入了“真相远比小说离奇”的部分。

为什么一切都不合理 你知道那种情况吗——你去听演讲，演讲者问一个问题，屏幕上有3个答案，而正确答案总是最不可能的那个？这基本上就是这里发生的情况。

私下报告所有安全bug似乎是件好事。它给项目时间去理解bug、创建修复、然后发布修复，这一切都在坏人知道发生了什么之前完成。大家都赢！

但实际发生的情况并非如此。私下处理安全禁运期真的很难。你必须注意你告诉了谁，你必须记住谁知道哪个bug的哪些细节，因为你可能同时有多个事情在进行中。你不能使用公开的git仓库，因为那会泄露修复。这也意味着没有CI测试。你不能请社区审查者做review，也不能让社区做测试，因为这是秘密修复。也许邮件是加密的，所以你得记住你的PGP密码和密钥放在哪里。你懂我的意思。常规流程分崩离析，对任何做这件事的人来说都是精神上的消耗。大公司有专门团队只做这类工作是有原因的（即使如此他们也经常搞砸）。

大多数禁运期泄露不是因为谁蠢，而是因为有人忘记了这个300步流程中的某一步。

现在，免费做这件事，一个月做100次。这就是今天的开源。每一个。单独的。项目。

开源正被安全漏洞狂轰滥炸 我们需要交代的另一个重要背景是，每一个软件厂商都在被漏洞报告猛烈冲击。所有的。开源开发者收到的漏洞报告数量在大幅增加。闭源供应商现在一个月发布的安全修复比过去一年发布的还多。

还要记住，在开源中这些人是志愿者。很多人并没有因为做项目而获得报酬。他们利用晚上和周末做这些事。他们最初想构建一个有趣的简单库来做表情包，而现在他们只处理漏洞报告。

过去找到安全漏洞真的很难，修复漏洞也真的很难，所以规模是平衡的。现在找到漏洞非常便宜，但修复漏洞仍然非常昂贵，所以天平完全失衡了。不仅仅是热门项目或大公司。是字面意义上的每个人都在经历这个。

为什么公开的安全bug更好？ 我不想误导任何人。公开的安全漏洞会带来一些新的、不同的问题，尤其是在初期。从现在开始的一切都是基于我个人经验的推测。我们得看看这篇文章是会像葡萄酒一样越陈越香，还是像牛奶一样变质。

目前在安全领域有一种观点，认为我们必须修复所有的漏洞。不过情况正在改善。CISA有一份叫BoD 26-04的文件。它基本上是说，你应该根据实际风险而不是通用严重等级来打补丁。这样做有助于避免当前漏洞海啸带来的补丁噩梦。

然而，如果你是一个开源项目，并且你有公开的未修复安全漏洞，你就会听到哀嚎和咬牙切齿的声音，要求你想想那些可怜的财富500强公司，他们需要安全修复 ASAP 以便通过审计。尽管BoD 26-04说不要盲目修补一切，但仍然有大量政策和合规标准在很多年内不会跟上，也许永远不会。

现在，非常非常非常重要的一点是，要记住开源对安全修复或任何修复承诺了什么：

软件按“原样”提供

就这样。你，作为一个开源开发者，不欠任何人任何东西。我知道有时候这很难相信。每个开源开发者对其社区都有着惊人的关怀和责任感，他们竭尽全力帮助任何能帮的人。但在这种情况下，说不是可以的。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）