security.wwwww.us

Bybit Safe 黑客拆解

dfnsaptthreat-inteltranslationbybit

Bybit Safe 黑客拆解

原文标题： The Bybit Safe Hack
原文副标题： How one compromised laptop led to the largest crypto heist in history.
原文链接： https://dfns.co/article/the-bybit-safe-hack
作者： Thibault de Lacheze-Murel, Christopher Grilhault des Fontaines
原文发布日期： 2025-03-10（约 23 分钟阅读）
译文说明： 全文简体中文翻译（非摘要）。IOC、哈希、合约地址、交易哈希、函数名、URL、代码等保持英文原文。
翻译日期： 2026-09-16（Asia/Shanghai）

免责声明： 本译文为非官方简体中文翻译，仅供安全研究与防御学习参考。版权归 DFNS 及原作者所有。如有歧义，以英文原文为准。

封面

图：The Bybit Safe Hack 封面

Thibault de Lacheze-Murel Christopher Grilhault des Fontaines

作者：Thibault de Lacheze-Murel、Christopher Grilhault des Fontaines

近期 Bybit/Safe 黑客事件震动加密世界……理由充分。高达 15 亿美元 ETH 被盗，这次沦陷成为史上最大加密货币盗窃，并暴露数字资产金融核心处令人难堪的脆弱性。最令人不安的是：一切取决于单名开发者电脑被攻陷，使攻击者得以注入恶意 JavaScript 片段，劫持 Bybit 使用的 Safe{Wallet} 基础设施。

尽管采用了所谓多签钱包（multisig wallets）的“最佳实践”，Bybit 仍沦为毁灭性的 delegatecall 利用的受害者。仅仅翻转一个参数——将 “operation=0” 改为 “operation=1”——就足以让攻击者完全控制，替换 Safe 的钱包逻辑，并将 401,000 ETH（约 15 亿美元）转入自有地址。该行动复杂度很高：预先部署两个恶意智能合约，并故意延迟资金在 900+ 钱包、跨链桥与 DEX 之间的转移，以逃避即时检测。这是一场完美风暴，在企业、基础设施、应用、协议乃至 UX 的每一层利用安全缺陷。调查仍在进行，但 SEAL 911 与 FBI 认为实施劫案的是 TraderTraitor（以独特战术黑客交易所而闻名的朝鲜组织）。

本文将解释黑客如何发生：从单名开发者被攻陷的电脑，到一笔交易参数的关键变更。随后审视 Ledger、Binance、Fireblocks 等参与方的首批建议。其提出的修复（例如消除盲签、采用更强多签、加入 MPC、多级审批、白名单、硬件核验、更好的运营治理等）是防止新灾难的良好步骤。但坦率地说：仅仅因为一台被攻陷的笔记本电脑就让攻击者完全访问 Bybit 的钱包基础设施，从而窃走 15 亿美元，这真正令人愤慨。更糟的是：每个使用 Safe 的公司都曾处于风险之中……Bybit 只是碰巧拥有最大储备。

尽管每项建议都提供宝贵保护，但单独任何一项都不够。它们必须在整体安全框架中协同工作，才能为加密带来银行级安全。若没有对更强、更集成系统的集体推动，这些攻击将持续发生。是时候超越碎片化的“最佳实践”，交付数字资产及其用户真正需要的稳健保护。

Bybit 借助 Safe{Wallet} 的“冷钱包”设置

事件发生于 2025 年 2 月 21 日。令人惊讶的是，攻击并不涉及 Bybit 核心系统或以太坊区块链的漏洞。相反，它瞄准 Bybit 信任的第三方“多签”平台 Safe{Wallet}。本文将考察 Bybit 的“冷钱包”如何设置、单笔交易如何完成利用，以及这对许多人一周前仍相信安全的所谓安全设置意味着什么。我们对“冷钱包”加引号，是因为“冷”意味着完全离线设置，而这与 Safe 智能合约和 Ledger Nano 的情况并不相符。

与大多数 web3 公司一样，Bybit 将其大部分资金存放在“冷钱包”中，与“热钱包”分离，旨在保护资产免受黑客攻击。该冷钱包运行于位于 0x1Db92e2EeBC8E0c075a02BeA49a2935BcD2dFCF4 的 Safe{Wallet} 智能合约。

Safe{Wallet} 是流行的多签平台（换言之：链上交易执行与批准平台）。Bybit 的版本使用标准代理合约，其唯一工作是将函数调用转发到承载真实交易逻辑的实现合约。在 Bybit 的案例中，这一最终存储在代理 “slot 0” 中的关键实现合约，最初位于 0x34CfAC646f301356fAa8B21e94227e3583Fe3F5F。Bybit 将其视为“冷钱包”，亦即其 ETH 储备的最后防线。

Bybit 以其多签安排保护“冷钱包”，要求多名员工批准每笔提款——这本身是好事。通常，资金从冷钱包转到热钱包（例如 0xf89d7b9c864f589bbF53a82105107622B35EaA40）用于日常运营。每位签名者会：(1) 使用 Ledger 硬件钱包，(2) 登录 Safe{Wallet} UI，(3) 审查交易，(4) 连接 Ledger 签名，(5) 提交。收集到足够签名后，Safe 将交易广播到以太坊 (6)。代理合约随后调用实现合约 (7)、验证签名 (8)，并释放资金 (9)。

图 1：冷钱包多签流程示意

图 1：Bybit 借助 Safe{Wallet} 的冷钱包签名与广播流程示意

例如，2025 年 2 月 3 日，交易 0x3e10310c05bb87269bfd60f67e13fd9dff4da80b4e47a541af1835f15fd96071 从冷钱包向热钱包转移 30,000 ETH。它在代理合约（0x1Db92e2EeBC8E0c075a02BeA49a2935BcD2dFCF4）上调用 execTransaction 函数，参数如下：

to: 0xf89d7b9c864f589bbF53a82105107622B35EaA40 (hot wallet)
value: 30,000 ETH (30,000,000,000,000,000,000,000 wei)
data: (empty)
operation: 0 (direct call)
safeTxGas: 45,745
dataGas: 0
gasPrice: 0
gasToken: 0x000...000
refundReceiver: 0x000...000
signatures: (multisig signatures from Bybit employees)

这是教科书式的转账：代理随后将该调用转发到实现合约，后者验证签名并将 30,000 ETH 发送到热钱包。因为 operation 字段设为 0，这是一次直接调用，没有额外复杂性。该流程安全且可重复，依赖 Safe{Wallet} 所谓久经考验的多签逻辑——直到不再如此。

一场精心编排的零日利用解剖

2025 年 2 月 21 日，Bybit 需要从冷钱包向热钱包转移 30,000 ETH——例行公事。员工遵循标准流程：登录 Safe UI，查看交易细节，连接 Ledger 设备，签名，并提交给 Safe。系统如预期广播交易：0x46deef0f52e3a983b67abf4714448a41dd7ffd6d32d32da69d62081c68ad7882。乍一看，它像是对代理合约（0x1Db92e2EeBC8E0c075a02BeA49a2935BcD2dFCF4）的又一次 execTransaction 调用。但参数讲述了不同的故事：

to: 0x96221423681A6d52E184D440a8eFCEbB105C7242
value: 0
data: 0xa9059cbb000000000000000000000000bdd077f651ebe7f7b3ce16fe5f2b025be29695160000000000000000000000000000000000000000000000000000000000000000
operation: 1 (delegatecall)
safeTxGas: 45,746
dataGas: 0
gasPrice: 0
gasToken: 0x000...000
refundReceiver: 0x000...000
signatures: (multisig)

有些不对劲。交易的 value 设为 0，因此没有 ETH 在转移。此外，operation 字段从 0 变为 1，并出现了新的 data 字段，涉及 delegatecall。让我们拆解。

该操作带有 1 标志，意味着它是 delegatecall 而非常规 call。在以太坊中，delegatecall 让目标合约（0x96221423681A6d52E184D440a8eFCEbB105C7242）使用代理的存储运行其代码。这至关重要，因为对目标存储的任何更改都会影响代理的存储，包括保存实现合约地址的槽位。

目标合约（0x96221423681A6d52E184D440a8eFCEbB105C7242）简单但危险。用伪代码写出来如下：

storage:
 stor0: uint256 at storage 0

def _fallback() payable:
 revert

def transfer(address _to, uint256 _value) payable:
 require calldata.size - 4 >= 64
 require _to == _to
 stor0 = _to

data 字段（0xa9059cbb…）触发 transfer 函数。前四个字节（0xa9059cbb）是 “transfer(address,uint256)” 的 Keccak-256 哈希，告诉以太坊虚拟机（EVM）执行 transfer。接下来的 32 字节（0xbDd077f651EBe7f7b3cE16fe5F2b025BE2969516）表示 _to 地址。_value 为 0，但此处无关紧要。执行时，transfer 将 stor0 更新为 0xbDd077f651EBe7f7b3cE16fe5F2b025BE2969516。但由于这是 delegatecall，stor0 并不属于目标合约；它属于代理在 slot 0 的存储。交易前，slot 0 持有 0x34CfAC646f301356fAa8B21e94227e3583Fe3F5F，即 Safe 的合法实现。执行后，它被覆写为攻击者控制的合约：0xbDd077f651EBe7f7b3cE16fe5F2b025BE2969516。在单笔已签名交易中，Bybit 的冷钱包代理从 Safe 的安全逻辑被重定向到攻击者合约。员工以为自己在批准向热钱包转移 30,000 ETH，但数日前遭供应链攻击沦陷的 Safe UI 掩盖了真实载荷。我们很快会讲到那一部分。

图 2：delegatecall 覆写实现示意

图 2：通过 operation=1 的 delegatecall 覆写代理 slot 0 实现

代理现在指向恶意实现后，攻击者立即行动。（原文亦提到地址 0x47666fab8bd0ac7003bce3f5c3585383f09486e2 作为攻击者控制地址。）同一天，他们广播交易 0xb61413c495fdad6114a7aa863a00b2e3c28945979a10885b12b30316ea9f072c。他们没有调用 execTransaction，而是在代理上使用 sweepETH，后者将调用转发到新实现。攻击合约包含如下函数：

def sweepETH(address _param1) payable:
 [...]
 call _param1 with:
 value self.balance
 [...]

残酷地简单：将合约中全部 ETH 转到 _param1。在本例中，_param1 是 0x47666fab8bd0ac7003bce3f5c3585383f09486e2——攻击者控制的地址。冷钱包持有 401,000 ETH（15 亿美元）。一次调用，攻击者全部抽干。无需多签批准。他们现在完全控制了钱包。

拆解 Safe{Wallet} 如何被沦陷

Bybit 黑客并非始于 2025 年 2 月 21 日。它始于数日前对 Safe{Wallet} 基础设施的隐藏沦陷。尽管细节仍在浮现，Sygnia 与 Verichains 的取证报告暗示对 Safe UI（Bybit 签名者使用的 Web 界面）的供应链攻击。入口点？一台被攻陷的开发者机器，使用与朝鲜 Lazarus Group 相关的战术被黑客。以下是攻击如何从初始沦陷展开，到欺骗 Bybit 团队的被篡改 UI。

首先，黑客开发者

在 Safe 开发团队这样的高风险环境中黑客一台机器，不是快速打砸抢。这是缓慢、刻意的过程。以高级网络行动著称的 Lazarus Group 擅长此类攻击。他们不强闯；他们利用信任。取证证据表明他们使用熟悉战术瞄准 Safe UI 开发者：社会工程。

一切从一条简单消息开始。“招聘人员”或“求职者”在 LinkedIn 或电子邮件上联系，花数天或数周建立关系。他们讨论虚假工作机会或协作。然后提出请求：“下载并运行这个示例项目”以评估技能。或者他们发送利用过时阅读器已知漏洞的 PDF。一次点击，后门静默安装。有时甚至更简单：一个需要快速 npm i 的项目，从被沦陷包拉取恶意依赖。在本具体案例中，取证分析揭示了令人不寒而栗的细节：开发者机器被以特权模式运行的 Docker 容器沦陷，危险的 privileged 标志被隐藏——很可能巧妙地——在配置文件中。看似无异。但现在攻击者已获得访问。

进入后，Lazarus Group 不慌不忙。他们扫描开发者机器寻找有价值数据（如 SSH 密钥、VPN 凭据、AWS 令牌）。在本例中，他们撞上金矿：Safe 的 AWS S3 存储桶凭据——Safe UI 的 JavaScript 代码存放之处。这不是运气。这是精心规划，正是 Lazarus 瞄准加密公司时以方法论著称的那种攻击。

其次，布置陷阱

持有窃取的 AWS S3 凭据后，攻击者并不急于上传恶意软件——他们研究战利品。目标是 Safe UI 的代码库，多签工作流的关键部分。他们很可能花数天分析它如何显示交易以及如何与 Ledger 设备交互。目标？修改得恰到好处，把它变成武器而不引起怀疑。

2025 年 2 月 19 日，他们行动了。使用窃取的凭据，他们向 S3 存储桶上传被篡改的 JavaScript 文件。这不是混乱的黑客，而是精确的。修改后的 UI 引入两项关键变更：

该攻击的精妙与恐怖在于其微妙。签名者看到熟悉界面，连接 Ledger 设备，签名他们认为是正常转账的内容。恶意 JavaScript 无需窃取密钥或黑客设备——它只是向他们喂谎言。Ledger 签名了攻击交易（0x46deef0f…），Safe 广播它，攻击者取得冷钱包控制权。

第三，等待收割

上传修改后的代码后，Lazarus Group 玩起等待游戏。他们知道 Bybit 的冷钱包操作不频繁，仅在热钱包需要补充时触发。2 月 21 日，那一刻到来。Bybit 签名者加载 Safe UI，从被沦陷的 S3 存储桶拉取恶意 JavaScript。陷阱触发：他们签名被操纵的交易，攻击者合约接管，数小时后抽干全部 Bybit ETH。

代码揭示了什么

恢复的 JavaScript 代码显示攻击者有多精确。他们没有重写整个 UI，只改了几处关键行。一部分瞄准 Bybit 钱包以保持攻击聚焦。另一部分调整交易显示，展示合法转账，同时把 delegatecall 载荷偷偷塞进签名。这些小而谨慎的更改使攻击难以检测——直到为时已晚。

数十亿美元不能由业余选手来守护

这次沦陷不只是 Bybit 的问题——鉴于 Safe 托管超过 1000 亿美元（！），它本可能轻易导致类似 FTX 的系统性熔断。攻击者能如此轻易渗透其 UI，引出太多问题。请认真想想：每个 Safe 用户都是潜在目标，Bybit 只是口袋最深。

此外，Bybit/Safe 黑客暴露了关于加密安全的根本事实：如果其背后的基础设施脆弱、中心化且管理不善，智能合约再强也无济于事。Safe 尽管将自己定位为领先的去中心化智能合约钱包，却建立在不成熟且不安全的基础之上。与 OpenZeppelin 等维持严格安全协议并持有 SOC 2 与 ISO 27001 认证的领导者不同，Safe 没有此类认证。这意味着没有正式审计、没有结构化合规流程，也无法保证遵循安全最佳实践。我们稍后会深入讨论。

安全始于治理，而 Safe 缺乏治理。正如一名内部人士所说，团队只是“瑞士和柏林的一帮开发者”，没有托管终端（即工程师在个人机器上工作，而非公司控制、安全加固的设备）。对守护数十亿美元资产的公司而言，这是可想象的最大运营安全失败之一。没有托管终端，一次钓鱼攻击或恶意软件感染就可能危及一切。利用最终发生并不令人惊讶。

Safe 的后端根本不去中心化——它是过度工程、中心化的一团乱麻。其自有 GitHub 仓库 safe-infrastructure 揭示整个系统如何依赖 PostgreSQL 与 Redis 数据库做交易状态与索引、RabbitMQ 队列处理交易请求，以及单一网关 API（safe-client API）处理所有交易广播。这根本不是去中心化协议——它是高度脆弱、平凡正常的系统，却被用作以太坊全球金库管理的骨干。整个基础设施由一支小团队控制、维护与运营，没有正式安全治理。更糟的是，一切配置在单一 Docker Compose 文件上——再次强调，对管理数十亿美元的平台而言，这是脆弱且危险的设置。

Safe 的基础设施如此中心化，以至于一度在无预警情况下关闭核心服务，直接影响依赖其交易中继的项目。一名沮丧的开发者在 GitHub 上指出：“对在这些服务之上构建产品的人来说，这听起来是件大事，或许不该只在 Twitter 线程里沟通。” 对一个自我标榜为“去中心化”的项目而言，单方面暂停关键基础设施的能力是刺眼的矛盾。这不是去信任系统——它是伪装成反面的单点故障。

然而，尽管这场惨败，仍有数十亿美元锁在 Safe 钱包中。虽然一些用户在 Bybit/Safe 沦陷后退出，大多数人要么盲目信任合约层，要么声称没有其他可行替代。Dune Analytics 的链上数据显示 Safe 的 TVL 仍达数十亿，证明市场对关键基础设施失败反应缓慢（或过于不负责任）。

Safe 丑闻是一记警钟：加密安全不只关乎智能合约，而是广义的信息安全，包括运营安全、治理与真正的基础设施韧性。到了某个节点，行业需要停止把去中心化表演与真实安全混为一谈。如果你管理数十亿美元，你需要的不只是好的智能合约。你需要真正的安全、真正的治理与真正的工程纪律。Safe 一样都没有，Bybit/Safe 黑客是不可避免的结果。

如何防止下一个十亿美元黑客案

这次 15 亿美元利用归结为两大主要缺陷：在不安全界面中的盲签（blind signing），以及在高度对抗环境中暴露关键密钥。我们如何防止此事再次发生？我们将拆解 Safe 设计中的弱点，提出更安全的方法，并展示 DFNS 如何将这些原则付诸实践。

“盲签”与用户侧交易伪造

Safe UI 的失败始于一个关键错误：它在用户电脑上暴露原始区块链交易（即发送到以太坊的确切数据）。UI 处理这些数据以显示关键细节（例如，“向热钱包发送 30,000 ETH”），然后将完整交易转发给 Ledger 设备签名。该设置假设 Bybit 员工使用的用户电脑是安全的。事实并非如此。

用户设备是安全风险。员工浏览网页、打开邮件、安装应用，有时甚至玩游戏——其中任何一项都可能引入恶意软件。远程办公使其更糟：你如何保护家中的笔记本电脑免受物理篡改？在 Bybit 的案例中，被沦陷的 Safe UI 将一个晦涩的交易字段从 0 改为 1——对签名者而言是不可见的变更。Ledger 的小屏幕与欠佳 UX 使核验原始交易（像 0xa9059cbb… 这样的长十六进制字符串）几乎不可能。结果？盲签——对 UI 的信任成为致命弱点。

该设计将用户电脑视为创建与签名交易的真相来源。那就是错误。个人设备本质上不可信，关键操作——如锻造控制 15 亿美元的交易——绝不该在那里发生。如果恶意 JavaScript 能在数据到达 Ledger 之前修改它，再多的多签安全也无法保护你。

用户托管密钥是定时炸弹

更糟的是，Safe 的设置将关键密钥（即用于那些 Ledger 签名的私钥）留在用户侧。虽然 Ledger 设备可以保护密钥免遭直接盗窃，周围环境却门户大开。丢失设备、在火灾中被毁，或员工突然离职——你就麻烦了。多签通过要求多个签名而非一个来提供帮助，但密钥轮换仍会暴露这些密钥。如果攻击者劫持 UI（如此处发生）或沦陷设备，一旦密钥签名恶意交易就结束了。没有任何策略或访问控制能撤销链上签名。

基于意图的交易与安全基础设施

那么，修复是什么？首先，停止在用户侧伪造原始交易。相反，让用户表达意图（intent）——用通俗语言描述他们想要什么（例如，“从冷钱包向热钱包 XYZ 转移 30,000 ETH”）。该意图被发送到钱包提供商运营的安全服务器。该服务器——运行在机密计算飞地（confidential computing enclave）等受监控、隔离的环境中——将意图翻译为原始区块链交易。为什么这有效？

其次，永远不要向用户暴露私钥。用户不应直接持有密钥，而应获得访问令牌——可撤销的凭据，授权提供商的安全系统代表其签名。实际私钥锁定在硬件安全模块（HSM）或多方计算（MPC）设置中，永不离开提供商控制。丢失令牌？撤销它。没有密钥泄露，没有多签重置。这遵循 NIST 安全最佳实践（见 Recommendation for Key Management, SP 800-57 Part 1 Rev. 5）——在传统信息安全中广泛使用，在区块链金融中急需。在 DFNS，我们称之为“网络托管密钥”或 “NHK 模型”（相对于“用户托管密钥”或 “UHK 模型”）。自 2019 年以来我们一直倡导这种密钥部署方法，尽管行业大多数冲向迎合“DeFi”并与所谓非托管设置（或理想）对齐。

弥合管理体验中的欺骗鸿沟

UI 需要重新思考。Safe 基于 JavaScript 的界面是容易目标。攻击者可以用假交易替换显示的交易。安全 UI 应防篡改，理想情况下内置于浏览器并密码学可验证。这就是 WebAuthn 与通行密钥（passkeys）的用武之地。使用非对称密码学，它们在不暴露密钥的情况下认证用户并签名意图。结合 WebAuthn 最新的 Secure Payment Confirmation（SPC），iOS 等操作系统现在可以在浏览器原生对话框中呈现关键交易细节（如金额、收款人等），JavaScript 无法篡改。这确保用户签名的正是他们所见。

我们比以往任何时候都更需要强大的企业安全

最后，公司必须将用户侧风险视为企业安全问题。强制硬件安全密钥（如 Yubikey）用于认证，强制对员工设备定期审计，并对敏感操作使用机密计算。治理、访问控制、监控与证明必须保护锻造与签名交易的系统——而不仅仅是密钥本身。

图 3：意图与安全基础设施示意

图 3：基于意图的交易与安全服务器侧锻造示意

以太坊智能合约可升级性的代价

既然我们已经覆盖了近乎灾难性事件链中的关键参与方（智能合约提供商、硬件设备与交易所员工），是时候讨论底层协议：以太坊。我们不怕说出来。Bybit/Safe 黑客升级得如此剧烈的核心原因之一，与以太坊基于账户的智能合约模型及其可升级性方法有关。与基于 UTXO 的模型不同，以太坊允许智能合约在单一合约地址下集中存储资金。在 Bybit 的案例中，这意味着巨额——15 亿美元——由单一 Safe 合约控制。

真正的脆弱性，然而，在于该合约如何可被修改。Safe 像许多其他基于以太坊的智能合约钱包一样，通过 delegatecall 支持可升级性——该特性让合约在保持自身存储的同时执行外部逻辑。这意味着获得合约逻辑控制权的攻击者可以执行任意代码，同时保留对所有存储资金的控制。那正是所发生的：一旦恶意升级被部署，它覆盖了合约行为，并允许攻击者立即抽干资金。

以太坊的灵活性使其成为创新平台，但也引入安全权衡。使 Bybit/Safe 黑客成为可能的 delegatecall 利用，是以太坊合约架构的固有风险——其他链通过不同账户模型或更严格的治理机制加以缓解。但并非所有区块链都这样运作，许多对这类利用本质上更具抵抗力。原因如下：

如果 Bybit 用的是 DFNS 而非 Safe{Wallet}

在 DFNS，我们从零构建了这一模型。它如何工作：

让我们继续设想。假设 Bybit 在 2025 年 2 月 21 日使用的是 DFNS 而非 Safe。其冷钱包会有策略：“仅向热钱包 XYZ 转账，需三名员工批准。”一名员工用 Yubikey 登录，输入 PIN，发起转账：“向 XYZ 转移 30,000 ETH。”出现 WebAuthn 提示，确认：“30,000 ETH 到 XYZ。”他们批准，两名同事同样用 Yubikey 操作。已签名意图到达 DFNS 服务器。策略引擎验证 XYZ，构建原始交易（operation: 0），并用我们的 MPC 签名。交易被广播：30,000 ETH 安全转移。现在，想象黑客篡改 UI，显示“30,000 ETH 到 XYZ”，同时秘密发送不同地址的意图。WebAuthn 会暴露他们——它显示实际目的地，警告签名者。即便溜过，策略引擎也会杀掉它：地址不是 XYZ，因此转账永不发生。没有 delegatecall，没有 15 亿美元损失。原始交易保持干净，因为用户侧从不锻造它。信任用户侧环境进行关键操作，是我们不能承担的风险。解决方案？将交易锻造转移到安全服务器，用令牌保护密钥，并使用像 WebAuthn 这样的防篡改 UI。这就是我们构建不仅能在对抗条件中生存、而且能繁荣的系统的方式。在 DFNS，我们正在证明它有效。下一个 15 亿美元黑客案不必发生。

图 4：DFNS 策略与 WebAuthn 流程示意

图 4：DFNS 意图、策略引擎与 WebAuthn 核验流程示意

企业安全是产品特性

Bybit/Safe 沦陷凸显一个关键问题：在“web3 原生”项目中，基础设施安全常被忽视。Safe 像许多 DeFi 平台一样，依赖智能合约与基于以太坊的逻辑，假设仅这些就能确保安全。但攻击与智能合约漏洞无关——它发生是因为单名开发者被沦陷的笔记本电脑让攻击者获得对 Safe AWS S3 环境的访问。这是企业安全失败，而非区块链安全失败。

Safe 缺乏 SOC 2 或 ISO 认证，意味着持续访问审查、第三方审计与严格云治理等基本保障缺失。相比之下，DFNS 遵循零信任原则、先进合规标准与严格企业安全协议，以消除单点故障。与一名开发者可在无检查情况下部署生产代码的设置不同，我们的流程被持续监控、记录与审计。任何基础设施变更需要同行评审、自动检查与多方批准。如果 Safe 有这些控制，S3 沦陷就不会发生。我们不依赖“多签就够了”的错误信念，而是基于国际标准、外部审计与每一层问责，强制执行安全框架，例如：

安全远不止智能合约

在 DFNS，我们不假设“如果我们的智能合约代码被审计，我们就安全了。”安全延伸到链上逻辑之外——它包括开发者终端、云基础设施与内部策略。我们对每一层应用同样的严谨：

Safe 沦陷提醒我们：安全的智能合约并不意味着安全的基础设施。DFNS 将区块链创新与严谨、合规驱动的安全相结合，以防止导致 Bybit 损失 15 亿美元的那类沦陷。如果行业想避免下一个数十亿美元灾难，它必须超越智能合约审计，采用零信任、可验证合规与整体安全——正如 DFNS 所做。

必读参考文献