比特币核心（Bitcoin Core）调整安全披露政策：应对AI漏洞发现的新常态

比特币核心（Bitcoin Core）正在终结长达一年的安全补丁等待期。此前，某些漏洞即使被语言模型在单次提示中即可重新发现，仍需遵循漫长的保密期。随着10月22日合并了一项项目安全披露政策的变更，现在创建了一个“易于发现”的漏洞类别，并指示维护者尽快发布版本更新和公开公告——从而绕过了标准的 embargo（保密期），该保密期通常会将中等或高严重性的漏洞保密约一年。

触发机制：语言模型降低了漏洞发现门槛

这一变化的触发原因直白而紧迫：维护者收到了越来越多的报告，指出那些容易被重新发现的漏洞正在频繁出现，因为语言模型极大地降低了发现这些问题的难度。Chaincode Labs 的比特币核心贡献者 Antoine Poinsot 在拉取请求（Pull Request）合并的同一天，在比特币开发邮件列表上宣布了这一变更。

Poinsot 写道：“我们最近经历了可轻易（重新）发现的安全漏洞报告数量的增加。这很大程度上是由于大型语言模型（LLMs）大幅降低了寻找某些类型问题或识别隐蔽修复措施的门槛。”

为何长达一年的保密期不再适用

比特币核心之前的政策将披露时间与漏洞严重程度挂钩。低严重性漏洞将在下一个主要版本发布后两周公开。中等和高严重性漏洞则保持私密，直到最后一个受影响版本结束生命周期后的两周才公开——政策本身将此窗口描述为“包含修复程序的主要版本首次发布后大约一年”。

这一时间表的存在是有原因的。比特币核心是运行大多数比特币节点的参考实现，节点运营商的升级速度较慢。长期的保密期旨在给予网络在细节公开之前进行修补的时间。其权衡在于，修复程序通常不会向后移植（backport），因此使用旧版本的运营商必须等待下一个主要版本，而该项目旨在每六个月左右发布一个主要版本。

这种谨慎是结构性的，而非偶然的。共识更改（如比特币的 Taproot 升级）通过缓慢、保守的路径推进，正是为了让运营商能够按照自己的计划采用它们。

Poinsot 写道：“由于我们项目的性质以及缓慢的升级文化，我们的安全政策倾向于更长的保密期。这通常意味着安全修复无法向后移植，只能随下一个主要版本一起向用户提供。”

然而，人工智能打破了这种权衡。如果一个漏洞可以通过简单的 LLM 扫描被重新发现，那么隐藏它毫无意义，因为任何持有聊天机器人的人都已经触手可及该缺陷。Poinsot 写道：“对于这些容易发现的问题，这是错误的权衡。保密期几乎没有任何作用，反而延迟了修复版本的可用性。”

新的“易于发现”类别究竟改变了什么

根据修订后的政策，披露时钟现在有了第三个设置。在分类期间，漏洞可以被标记为“易于发现”，定义为“可以用最小的努力发现，例如通过简单的 LLM 提示”。该标签不仅限于 AI 发现的漏洞：它取决于重新发现的 effort（努力程度）有多小，而不是由哪个工具发现了它。

对于这类漏洞，响应方式在所有方面都发生了变化。维护者不再仅仅在下一次主要版本中提供一个修复，而是会根据比特币核心支持最新三个版本的原则，将修复向后移植到所有当前维护的主要版本分支中，并尽可能快地推出点版本（point releases）。同时，会发布一份安全公告，与修补后的软件一同公布。

严重性阶梯仍然支配着其他所有内容。低严重性漏洞仍遵循两周的日程。中等和严重性漏洞仍遵循约一年的时钟。关键性漏洞——即在协议层面可能导致硬币被盗、通胀或永久分裂链路的漏洞——仍不在标准政策范围内，将继续个案处理，正如过去一样。

这种例外存在充分理由。在比特币核心的历史中，2018年9月披露的 CVE-2018-17144 通胀漏洞就是那种需要特殊处理的缺陷类型：它本允许在发行计划之外创建硬币。新的“易于发现”途径不触及这一层级——关键性漏洞仍将获得围绕整个网络风险定制的临时响应。

两周、一年，还是“尽快”

这一变化最容易解读为披露窗口的缩短。今天修复的一个中等严重性漏洞，通常会保密约52周，仅在最后一个受影响版本结束生命周期后两周才披露。一旦被标记为“易于发现”，同一漏洞将作为点版本“尽快”发布，并附带安全公告。这就是从一年到“编写、审查和测试针对性补丁所需的时间”之间的区别。

向后移植的承诺是另一半改变。在此之前，修复程序通常不会到达旧维护分支上的用户；它会随下一个主要版本到达。现在，使用旧受支持版本的运营商可以获取针对性的点版本，而无需采用新版本中的所有功能和行为更改。对于一个升级缓慢且深思熟虑的网络来说，这是对补丁实际落地速度的实质性改变。

维护者自身指出的风险

更快的路径是有成本的，Poinsot 在拉取请求中直言不讳地指出了这一点。“这在政策下尤为重要，因为缓解措施在发布给用户之前在开发分支中的‘烘焙时间’（bake time，即测试和稳定时间）会更少。”他写道。几天内发布的修复程序比放置数月的修复程序在审查和测试中花费的时间更少。

讨论还分裂了是否应使披露速度更快。一些贡献者认为，打开修复程序的拉取请求本身就会引起攻击者的注意，因为自动监控代码库成本很低，因此披露可能不能晚于补丁，或者应提前披露缓解指导。另一位贡献者提议随补丁发布可选或延迟的安全公告。Poinsot 拒绝了这一建议，写道：“在没有详细信息的情况下提醒用户可能会引发从未受影响的操作员的仓促迁移。”

这一交流之所以重要，是因为它表明新政策是一条刻意的中间道路，而非显而易见的一条。合并后的文本保持公告与修复同步，并保持完整细节，而不是模糊的警告。

首个“易于发现”漏洞何时降临

目前尚无漏洞被归入新类别，因此这是一次流程变更，而非实时漏洞的披露。真正的考验即将到来，当维护者在分类时将某事标记为“易于发现”，并在维护分支上发布带有同步公告的点版本时。

更广泛的信号是，AI 辅助漏洞挖掘已经迫使比特币生态系统采取行动。今年早些时候，Core Lightning 告诉节点运营商“升级或断开连接”，因为 AI 生成的漏洞报告被证明是正确的。比特币核心的政策变更是参考实现在协议基础层做出相同的计算：当重新发现变得廉价时，秘密几乎无益，而长期保密期只会延迟修复版本的发布。

对于节点运营商而言，今天一切照旧。升级节奏保持不变。差异出现在下一次漏洞被认定为“易于发现”时，届时补丁及其公告将以比以往更少的通知时间共同抵达。