一份新发布的预印本论文指出，在 DeFi 项目里，「已审计」并不等于整个系统都经过了安全审查。审计通常只针对特定时间点、指定代码、组件和版本展开，任何超出这一范围的新增、删改或运行环节，结论都可能不同。
这份研究由安全公司 ack3 与布拉格捷克理工大学相关研究人员参与完成。研究团队分析了 2026 年上半年报告的 135 起安全事件，合计损失 9.3986 亿美元，并在其中识别出 68 起带有公开事前审计记录的事件。
已审计样本中，67.6% 事件攻击路径不在审计范围内
在这 68 起样本里，研究人员将 46 条攻击路径归类为完全不在任何可查审计范围内，20 起事件至少有一项审计覆盖到相关范围，另外 2 起无法判定。
按事件数量计算，审计范围外事件占比为 67.6%。按损失金额计算，这部分事件对应损失 6.8097 亿美元，而 68 起已审计样本总损失为 7.2124 亿美元，占比达到 94.4%。
研究同时提醒，这个数字并不是对审计有效性的直接评估，也不能证明审计范围限制本身导致了损失。它反映的只是所选公开安全事件样本中的损失分布。
两起超大额事件对结果影响很大。剔除 Kelp DAO 的 2.92 亿美元损失和 Drift Protocol 的 2.85 亿美元损失后，同一组已审计样本中，审计范围外攻击造成的损失降为 1.0397 亿美元，总损失为 1.4424 亿美元，占比降至 72.1%。
研究覆盖范围与统计口径
ack3 这份研究覆盖的时间区间为 2026 年 1 月 1 日至 6 月 29 日，共纳入 122 起确认攻击事件和 13 起疑似事件。全部样本中，35 起没有找到审计记录，32 起审计历史未知，这两类都没有被计入上述 68 起事件的统计。
研究人员表示，数据集的 json 文件可以复现事件分类数量和损失金额。「审计范围内 / 外」这一标签，也是基于公开证据完成的判断。研究团队查阅了项目方和审计机构存档，在攻击发生前寻找对应审计报告，再将最终攻击路径与被审查代码、版本以及审计排除项进行比对。
论文全文共 6 页，与数据集发布方联合产出，其中两名作者隶属于安全审计公司 ack3。
研究没有证明“审计过的协议整体更安全”
论文也明确写出边界。研究没有纳入未遭受攻击的对照组，也没有统计各系统暴露在风险中的时长，因此无法证明经过审计的协议整体更安全，也不能估算事件发生概率。
同样，现有数据也无法证实「超出审计范围」就是每一笔损失的直接诱因。研究还提到，部分未公开审计和私人事故可能缺失，而已经报告的损失数据之间也不完全可比。
在这个前提下，研究能够支持的结论较为有限：审计记录和审计覆盖范围是两个独立指标。某一份智能合约通过审查，并不意味着合约升级、特权密钥、前端、中继器、预言机、云服务或应急响应流程，也获得了同等程度的保障。
基础安全信任问题：用户看不到实际运行系统是否被审查
研究揭示的核心问题，不是简单地否定审计，而是指出用户常常无法知道一个声称「已经过审计」的项目，实际运行中的系统、资金流向以及控制措施，是否真的在审查范围内。
换句话说，一枚审计徽章不能自动覆盖整个 DeFi 项目的安全边界。被审查的代码仓库、部署后的合约、后续升级、密钥管理、运行时环境和风控机制，未必属于同一套边界。
ICON Network：问题出在两个校验环节的边界处
研究还用 8 月的两起事件，说明审计边界和实际攻击路径之间的差别。第一起是 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 事件中的响应时间线
这次事件还暴露出另一类边界问题，即风控和应急机制是否足够快。ICON 的第一条自动化告警在 UTC 时间 02:08 触发，距离攻击启动约 7 分钟。工作人员在 03:40 左右启动调查，03:53 暂停受影响合约，06:18:54 暂停整条网络。
从首次告警到完整应急处置，中间有约 90 分钟间隔。ICON 将原因归结为告警机制调整：由于该规则曾在网络连通故障中产生大量误报，因此没有以高优先级通知值班人员。基金会计划部署自动关停触发机制、降低熔断阈值，并围绕消息唯一性和重放防护展开专项复审。
研究认为，这类风控设计不能替代审计，但它回答的是另一个问题：当前置预防失效时，系统能否及时检测并隔离风险。
aelf：安全保障需要持续更新
8 月的 aelf 安全事件则从另一侧说明同样的问题。公开资料描述显示，事件涉及运行时入侵和可控恢复，但现有证据还不足以把攻击运行路径直接对应到某一份事前审计的覆盖范围里。
根据项目官方公告，存在一份未授权智能合约，可以借助交易参数，把编码后的 .NET 程序集和指令注入节点执行链路。
初步调查报告称，事件原因在于运行时反射与动态加载校验存在缺陷，同时合约执行环境与敏感节点、基础设施资源之间隔离不足。aelf 共识别出 155 笔相关交易、5 个独立载荷程序集，这些载荷具备执行主机命令、尝试对外通信、访问节点密钥和基础设施侦察等能力。
不过，具备这些能力，不等于全部载荷都已执行成功，也不代表攻击者已经拿到全部目标凭证或造成敏感数据外泄。aelf 表示，已按潜在泄露标准轮换签名密钥和基础设施凭证。
截至 9 月 11 日，上述结论仍属于阶段性判断。aelf 官网博客在 8 月 26 日之后，没有就这次事件发布专项更新；而 8 月 26 日公告曾承诺后续会发布更新和最终复盘。
aelf 技术安全文档写明，其区块链和 ELF 代币合约经过多轮审计，且未发现安全问题。但在现有公开页面中，外界无法把 8 月攻击对应的运行时路径，与事发前某一份具体审计报告建立对应关系。因此，无论把该事件定性为审计疏漏，还是审计范围外故障，现阶段都缺少足够证据。
研究给出的实际启发：需要带版本的安全记录
研究认为，这种不确定性本身就有参考意义。带时间戳的审计报告，会随着代码、依赖库和运维状态变化，逐渐与当前系统脱节。用户真正需要的是一份带版本的安全记录，用来说明已经审查过什么、后来又改变了什么。
按照论文提出的思路，这份安全记录应包含：
- 被审查的仓库和代码提交版本；
- 部署合约地址；
- 被排除在外的组件；
- 特权角色和依赖库；
- 审计完成后的合约升级情况；
- 密钥托管和轮换机制；
- 运行时隔离策略；
- 告警与熔断机制；
- 带时间戳的资产恢复状态，并区分确认损失、冻结资产和尚未解决的风险敞口。
论文并没有否定审计本身的价值。它讨论的是，审计宣传和实际工作内容需要对应起来，而且要能映射到当前真正运行中的系统。
对用户来说，真正还没有被回答的问题是：被审查的组件、已经部署的系统，以及系统在出故障时的应对机制，是否仍处在同一个安全边界内。
