为什么审计代码已经不够了：加密货币被盗方式的结构性转变

多年来，加密货币安全的主流叙事围绕着智能合约展开：找到漏洞、修复代码、通过审计。合约没问题，协议就安全。当大多数重大攻击确实针对链上逻辑时，这套思路是合理的。但它已经无法描述现在大部分资金流失的方式了。

2025 年，基础设施攻击占所有加密货币被盗资金的 76%，在 28.7 亿美元的年度总损失中约为 22 亿美元。这个趋势延续到了 2026 年。2026 年第一季损失的 4.82 亿美元中，仅钓鱼与社会工程攻击就占了 3.06 亿美元。其中一月份的一起事件，攻击者通过长期社会工程操控硬件钱包签署流程，单笔就造成了 2.82 亿美元损失。

相比之下，智能合约漏洞在整个 2025 年造成的损失约为 3.5 亿美元，分散在 52 起独立事件中。它们发生频率更高，但单次损失规模远低于现在主导威胁格局的那类攻击。

所谓基础设施攻击，涵盖多种不同方式，但它们有一个共同特征：漏洞不在区块链代码里，而在围绕它运作的系统、人员与流程中。

私钥与助记词泄露是一种形式。员工设备通过钓鱼邮件或假冒招聘感染恶意软件，恶意程序进一步获取凭证或 session token。攻击者再利用这些权限进入内部系统，找到环境变量或密钥存储位置，最终转移资金。智能合约完全按设计运行，所有审计也都通过。真正被攻破的，是持有权限的人。

前端入侵则是另一种形式。区块链协议本身没有问题，但用户互动的网站已经被修改。可能是主机服务商遭入侵、域名被劫持，或部署流程被篡改。用户以为自己正在连接真实界面，实际上却连进了一个提款器。2026 年 4 月的 CoW Swap 域名劫持就是典型案例。同月的 Vercel 事件，则让这类风险被放大到更高层级，因为大量 Web3 前端都部署在 Vercel 上。

供应链入侵则是第三种形式。攻击目标不是协议本身，而是开发与部署过程中使用的某个程序库、依赖包或工具。2026 年 4 月，Axios npm 套件遭到入侵，一个远程访问木马被推送到未知数量的开发者设备。任何在受影响期间使用该套件的项目，都可能在不知情的情况下暴露了自己的构建环境。

审计的设计目的，是检查智能合约是否存在已知漏洞模式，确认链上逻辑是否按预期运行。它不会审查开发者是否使用安全设备，不会检查环境变量存放方式，也不会评估团队是否能够识别社会工程攻击，更不会持续监控部署流程中的依赖是否遭到污染。

Resolv 接受了 18 次审计，这不是审计师失败的故事，而是审计覆盖范围与现实攻击位置之间出现错位的故事。Venus Protocol 在遭攻击前也有五家公司审查过代码，但攻击利用的是一种早已公开记录多年的 donation attack 模式。代码本身没有问题，问题出在协议在特定外部条件下的互动方式，而那超出了审计通常假设的范围。

在 2026 年第一季，拥有大量 TVL 与广泛审计历史的协议，平均损失甚至高于未审计的同类项目。成熟攻击者会追逐价值集中之处。一个锁仓数亿美元、拥有完整审计记录的协议，可能比一个已知存在代码问题的小型项目更具吸引力，尤其当它的运营安全没有跟上代码安全的提升时。

对于普通用户而言，这些风险大多是不可见的。大部分人从来不会阅读智能合约，他们通过网站互动、连接钱包、批准交易。他们所依赖的安全模型，其实大量存在于界面层。

而这正是问题所在。一个看起来正常的网站，可能并不正常；一笔看似例行的交易，可能已经被遭入侵的前端修改；一个通过多次审计的协议，也可能被完全绕过智能合约本身的攻击所击穿。

这并不意味着加密货币应用全面不安全，而是意味着“安全”这件事，早已比一张审计证书复杂得多。攻击面已经远远超出了代码审查能够覆盖的范围。

理解这件事，并不需要精通每一层技术。真正需要理解的是：你与区块链之间的界面并不是中立的，而维护那个界面的人与基础设施，本身就是安全模型的一部分。

大多数关于黑客事件的报道，只聚焦于单一事件本身。但真正值得理解的，往往是事件背后反复出现的模式。