AI时代下，以太坊责任披露流程的重塑

liumuhui 3小时前阅读数 1 #区块链

随着 AI 的出现，责任披露变得更加重要和关键。AI 让问题的复现和发现更加迅速，也缩短了 bug 能够被隐藏的时间。它还使有动机的攻击者能够轻松监控关键软件及其依赖项的发布，以寻找隐藏的 bug 修复并抢先部署。因此，我们必须调整我们的披露和补丁流程，尤其是在以太坊主网方面。

以太坊的特殊挑战

以太坊生态系统的特殊之处在于，我们有多种用不同语言编写的实现，而且都是开源的。我们有在同一层被多个客户端共享的库（所有 CL 客户端都需要一个 BLS 库），也有跨层共享的库（例如 Prysm 和 Geth 都用 golang 编写，共享标准库）。以太坊保障着数千亿美元的价值，这为攻击者创造了直接的激励。

有许多下游项目基于客户端的 fork 进行开发。这些项目也依赖客户端团队提供安全更新和披露协调。而且我们与用户之间没有直接关系。由于这是一个无需许可的系统，我们不知道需要提醒谁关注发布的更新。

此外，客户端是非常复杂的软件，依赖许多不同的库和依赖项，其中一些可能非常关键。

过去的披露流程

过去，我们经常私下修复 bug，并将补丁隐藏在无关的重构中，以迷惑攻击者。这一做法效果不错：我们会在发布前的最后一刻偷偷加入补丁，并建议用户尽快更新。

后来，我们意识到需要与下游依赖方共享补丁。分叉了 go-ethereum 代码库的 L2 和其他 L1 经常受到与我们相同 bug 的影响。我们不想成为 kingmaker，也不偏袒任何一方，所以预先共享补丁对我们来说行不通。因此，我们决定调整流程：提前向一批可信的下游项目预告，即将有一个包含若干安全关键补丁的版本发布。这能让下游项目提前准备版本，并缩短他们发布所需的时间。

过去我们还认为，单个客户端中的 bug 不会影响使用不同库的其他客户端。因此我们通常逐个修复客户端。而现在，攻击者可以借助 AI，把所有此前发现的 bug 都喂给它，从而也能在其他代码库中发现类似的 bug，因此我们需要更强的协调力度。

我们之前遇到的另一个问题是，一些下游项目在我们的发布禁令解除之前就过早地公开了 bug。幸运的是，据我所知，过去 6 年多的时间里这种情况只发生过两次。更明确的指南和对发布禁令更严格的执行，将有助于我们在未来防止这些问题。

新的流程

我们目前正在制定新的负责任披露流程（这也激发了我撰写这篇文章的想法）。我们希望解决过去流程中的多个挑战：

问题	建议的解决方案
上游和 fork 之间几乎没有知识共享	在上游和 fork 之间建立专门的沟通渠道
用户完成更新的周转时间太长	为客户端设立专门的邮件列表以分享更新，研究（可自愿加入的）自动更新，并改进 CI，缩短从发布到 Docker 镜像/软件包管理器更新之间的时间
客户端与依赖项之间缺乏联系	与依赖项的维护者建立专门的沟通渠道
一个客户端中的 bug 可能影响另一个客户端	改进我们现有的历史 bug 数据库
多个客户端团队之间的协调很困难	制定新的安全团队内部协调指南，例如：在主网中份额较高的客户端将先于较小的客户端获得补丁，以确保主网安全
依赖项与客户端团队之间的发布协调	制定新的安全团队内部协调指南，例如：为依赖项的版本发布设定明确的截止日期，以便客户端团队可以紧随其后发布
客户端与下游依赖方（L2 等）之间的发布协调	制定新的安全团队内部协调指南
发布禁令的执行	内部维护一份违反禁令的依赖项/参与方名单
实时紧急事件发生时的协调	制定新的安全团队内部指南和预案（playbooks）
回归测试未添加到客户端	建立回归测试数据库，并设定将其添加到客户端的时间表
对网络中已更新比例的可见性	向更多用户推广像 Xatu 这样的工具，以获得更好的网络概览
各客户端之间 CVE 政策不一致	制定标准化指南，明确何时以及如何申请 CVE
各客户端的修复时间线差异很大	制定更清晰的 SLA，明确从通过 bug bounty 提交到发布和披露的时间线