Bitcoin Core 已修改其安全披露政策，以加快修复那些大型语言模型几乎不费力就能发现的漏洞，结束了这类漏洞过去通常会经历的数月封锁期。

维护者于周四合并了这项对项目安全政策的修改。Chaincode Labs 开发者 Antoine Poinsot 起草了该提案，并在同一天向 Bitcoin Development Mailing List 发消息宣布了这一变化。

Poinsot 写道：“我们最近经历了安全漏洞报告数量的增加，这些漏洞可以很容易地被（重新）发现。这在很大程度上是因为 LLM 大幅降低了发现某些类别问题或识别隐蔽修复的门槛。”

此前政策如何运作

Bitcoin Core 是运行在比特币网络大多数节点上的软件，它会按严重程度对每个已报告漏洞分级，并据此安排披露时间。低严重性缺陷会在下一个主要版本发布两周后公开。

中高严重性问题则会一直处于封锁状态，直到最后一个受影响版本到达生命周期终点后的两周才会公开，这一过程最长可持续一年。

较长的时间表给节点运营者留出时间将软件升级到已修复版本后，再让细节公开。实际上，这种做法意味着，旧的受维护版本上的修复不会立即发布，而是会随着下一个主要版本一起到来。

Poinsot 认为，对于那些容易被重新发现的漏洞，这种权衡并不成立。政策写道：“封锁期几乎没有起到作用，只是延迟了修复版本的可用时间。”

有哪些变化

在分诊阶段，Bitcoin Core 可以将某个漏洞标记为“容易被发现”，政策将其定义为“只需极少努力即可发现”的问题，例如通过一个简单的 LLM 提示词。该标签也适用于通过其他方式发现的缺陷。

对于这类问题，项目将把修复回补到每一个仍在维护的主要版本，尽快发布点版本，并在发布修复软件的同时公开一份包含部分细节的安全公告。

Poinsot 承认，这类修复在交付给用户前会有更少的测试时间。

不属于该类别的漏洞仍将沿用现有的、基于严重程度的时间表。关键漏洞——即可能在协议层面导致币被盗、扩大供应量或造成永久性链分叉的漏洞——仍不适用标准政策，将按个案处理。

开发者 Antoine Riard 曾推动一种选项，即在不发布公告的情况下先行推出修复，并按个案暂缓披露细节。Poinsot 拒绝了这一建议，并写道，若在没有细节的情况下提醒用户，可能会“无必要地制造更多风险”，因为这会促使原本不受影响的用户仓促迁移。

AI 驱动报告激增的一个夏天

这项变化出现在比特币开源项目数月承压之后。7 月下旬，一个由 16 名开发者组成、名为 Bitcoin Red Team 的志愿小组在大约一天内用 AI 模型扫描了 390 个比特币仓库，并记录了 4,962 项发现，其中 85 项被评为关键级。

几天后，该小组私下报告的一个 BTCPay Server 漏洞在真实商户服务器上被利用，导致 Lightning 节点资金被清空。

8 月，Core Lightning 开发者在 AI 生成的报告被证实准确后，要求运营者升级或断开连接。

Bitcoin Red Team 的行动发生在 7 月 30 日 Coldcard 硬件钱包漏洞被利用之后，当时攻击者在 25 分钟内转走了 594 枚 BTC。四次转移造成的损失接近 1.14 亿美元。