审计仅审查局部代码，不能为整个 DeFi 项目安全背书。

撰文：Liam 'Akiba' Wright

编译：Chopper，Foresight News

在去中心化金融领域，「已审计」 往往被视作对整个项目的安全背书。但实际上，审计通常只覆盖特定时间点、指定的代码、组件与版本。任何在此范围之外添加、删除或操作的内容，其审计结果可能完全不同。

一份新的预印本论文给出了这一差距的具体数字。安全公司 ack3 与布拉格捷克理工大学的相关研究人员分析了 2026 年上半年报告的 135 起安全事件，这些事件造成的损失高达 9.3986 亿美元。他们发现其中 68 起事件有可识别的公开事前审计记录。

在这 68 起事件样本中，研究人员将 46 条攻击路径归类为完全不在任何可查审计范围内；20 起事件至少在一项审计覆盖范围内；剩余 2 起无法判定。审计范围外的事件占总事件数量的 67.6%，对应损失金额却占到报告损失总额的 94.4%。

这个惊人的比例并非对审计有效性的评估，也不是审计范围限制导致损失的证据。它仅代表所选公开安全事件样本里的损失分布。两起特大事件对数据影响极大：剔除 Kelp DAO 2.92 亿美元损失与 Drift Protocol 2.85 亿美元损失之后，同组已审计样本中，审计范围外攻击造成的损失占比降至 72.1%。

即便存在上述局限，这项研究揭示了一个基础安全信任问题：一个项目声称已经过审计，但用户却无法得知实际运行的系统、资金流向以及相关的控制措施是否经过审查。

数据的真实含义

ack3 的这份研究覆盖 2026 年 1 月 1 日至 6 月 29 日，一共 122 起确认攻击事件、13 起疑似事件。全部样本里，35 起事件没有找到审计记录，32 起审计历史未知，这两类均不计入上面 68 起事件的统计范围。

在 68 起事件样本中，审计范围外事件对应损失 6.8097 亿美元，总损失 7.2124 亿美元，由此得出 94.4% 这一数据。剔除 Kelp DAO 和 Drift Protocol 之后，审计范围外损失为 1.0397 亿美元，总损失 1.4424 亿美元，占比 72.1%。数据集 json 文件可以复现事件分类数量与损失金额。

「审计范围内 / 外」 标签，是研究人员基于公开证据做出的判断。研究团队查阅项目与审计机构存档，找到攻击发生前的审计报告，对比最终攻击路径与被审查代码、版本以及审计排除项。该研究是一份 6 页预印本论文，与数据集发布方联合产出，两名作者隶属于安全审计公司 ack3。

该研究缺少未遭受攻击的对照组，也没有统计各系统暴露风险的时长。因此无法证明经过审计的协议整体更安全，不能估算事件发生概率，也无法证实 「超出审计范围」 是每一笔损失的直接诱因。部分未公开的审计和私人事故可能缺失，而已报告的损失数据也不完全具有可比性。

因此该研究仅能得出有限结论：审计记录和审计覆盖范围是两个独立指标。一份经过审查的智能合约，并不代表合约升级、特权密钥、前端、中继器、预言机、云服务或是应急响应流程，能获得同等安全保障。

8 月发生的两起事件，从不同角度印证了这种区别。ICON Network 案例直观展示，两段审查过的代码在两个校验环节的边界处出现故障；而 8 月 aelf 安全事件则是另一种情况，现有审计证据尚无法将攻击运行路径对应到事前审计范围。

ICON Network：审查边界处的失效样本

在 8 月 27 日 ICON Network 重放攻击中，提现链路的两个模块对同一条消息的解读出现分歧。

根据 ICON 基金会事后复盘报告：迁移合约依靠提现消息序列号的高位比特判断消息是否唯一；但加密签名仅覆盖序列号低 256 位。攻击者通过修改未纳入签名校验的高位比特，在约 20 分钟内，将两条合法签名的提现消息重复提交 1492 次，其中 1490 次调用执行成功。

本次重放攻击释放 1.19866 亿枚 ICX 以及 531600 枚 bnUSD。复盘发布时，ICON 确认净损失约 150.2 枚 ETH 外加 31204 枚 USDC。基金会称 531600 枚 bnUSD 和 136.6 万枚 SODA 资产已追回，用户存款、账户余额与头寸未受影响。

ICON 表示，这份迁移合约已经完成外部审计，并且落实了审计建议，包括同一模块区域的相关修改；对应的中继逻辑也单独接受过专项审查。Sodax 开发文档审计列表中包含 8 份覆盖不同组件的报告，其中包含 2025 年 11 月的 Sodax 中继审计报告。

但复盘报告写明，唯一性校验逻辑与签名校验值之间这一处精确错配，不在上述审计的发现范围内。一个简单的 「已审计」 项目标签，无法让用户知晓提现链路两端对于 「消息唯一性」 的判定标准是否保持一致。

响应时间线还暴露另一类边界问题。ICON 第一条自动化告警在 UTC 时间 02:08 触发，距离攻击启动约 7 分钟。工作人员在 03:40 左右启动调查，03:53 暂停受影响合约，06:18:54 暂停整条网络。

从首次告警到完整应急处置，中间存在约 90 分钟间隔。ICON 归因于警报机制的调整，该告警规则在过往网络连通故障中产生大量误报，因此没有以高优先级通知值班人员。基金会计划部署自动关停触发机制、降低熔断阈值，并针对消息唯一性与重放防护开展专项复审。

这类风控机制不能替代审计，但它回答另一个关键问题：当预防措施失效，系统能否快速检测并隔离风险？

用户仍需要明确回答的安全问题

aelf：安全保障需要持续更新

aelf 在 8 月的安全事件，从另一个角度印证上述观点。公开资料描述出现运行时入侵与可控恢复，但现有证据不足以判定攻击路径落在事前特定审计范围之内。

项目官方公告说明：存在一份未授权智能合约，能够借助交易参数，将编码后的.NET 程序集与指令注入节点执行链路。

初步调查报告将事件归因于运行时反射与动态加载校验存在缺陷，同时合约执行环境和敏感节点、基础设施资源之间隔离不足。aelf 一共识别 155 笔相关交易，5 个独立载荷程序集，载荷具备执行主机命令、尝试对外通信、访问节点密钥、基础设施侦察等能力。

具备能力不等于确认全部载荷执行成功，也不代表攻击者拿到全部目标凭证、敏感数据外泄。aelf 表示，已按照潜在泄露标准轮换签名密钥与基础设施凭证。

截至 9 月 11 日，该结论仍为阶段性判断。aelf 官网博客在 8 月 26 日后没有发布针对本次事件的专项更新。8 月 26 日公告承诺后续发布更新与最终复盘。

aelf 技术安全文档写明，其区块链与 ELF 代币合约经过多轮审计，未发现安全问题。但现有公开页面，无法将 8 月攻击对应的运行时路径与事发前某一份审计报告对应起来。因此，将事件定性为审计疏漏或是审计范围外故障，都缺少足够证据支撑。

这种不确定性本身就具备参考意义。一份有时间戳的审计报告，会逐渐和当前系统代码、依赖库、实际运维状态脱节。用户需要一份带版本的安全记录来体现这种差异。

这份安全记录应当写明：被审查仓库与代码提交版本、部署合约地址、被排除组件、特权角色、依赖库；同时记录审计完成后的合约升级、密钥托管与轮换机制、运行时隔离策略、告警和熔断机制，以及带时间戳的资产恢复状态，区分确认损失、冻结资产与尚未解决的风险敞口。

这并不是否定审计的价值，而是让审计宣传和实际工作内容匹配，并且关联当前正在运行的系统。

一枚审计徽章无法回答：被审查的组件、已部署的系统和应对故障的机制，是否还处在同一个安全边界内。