据 Woofun AI 消息，加密货币协议界普遍存在的'已审计'标识正沦为一种危险的认知陷阱，其背后往往仅指向对特定代码库中少量文件在短短一周内的有限审查，而非对资金安全、运营方专业能力或软件全面检测的有效背书。这种将局部合规等同于整体安全的错觉，正在掩盖系统性的风险敞口。

审计范围的狭隘性构成了这一认知偏差的核心。许多项目将针对某一个代码库中的几份文件进行的短期审查，错误地包装为全栈安全证明。这类似于建筑物所有者聘请电工检查电路断路器箱，却将所得证书当作整个建筑具备防盗功能的证明。

尽管电工的工作可能非常出色，但该证书却被用来承诺建筑物具备门锁、警报系统等原本不在电工检查范围之内的安全功能。后续的修改版本以及实际生产环境中使用的配置还可能需要另行测试。员工的笔记本电脑或云账户属于另一层需要考虑的因素；签名设备以及用于说明交易流程的界面同样需要接受独立审查。

这种安排属于正常的职业实践，因为有限的审计工作必然有其特定的范围。而问题则在于，当一份经过严格限定的审计报告被发布到项目网站上后，却变成了对负责维护该代码的机构的整体评价。

从缺陷分布来看，审计发现的内容其实与那些受雇检查代码的人所给出的报告并无二致。逻辑缺陷和业务逻辑缺陷占总缺陷数的 14.6%，代码质量问题占 13%，输入验证缺陷占 10%，访问控制问题紧随其后，占比为 9.8%。大约六分之一的审计发现被评定为严重或高严重程度，据此可得出共有 1,439 项严重问题以及 2,659 项高严重程度的问题存在。审计发现指的是在审查过程中发现的缺陷，而漏洞攻击损失则记录的是从实际运行系统中发生的成功盗窃事件。许多缺陷在代码部署之前就已经得到修复，还有一些存在漏洞的代码甚至从未进入生产环境。由于这两组数据所涵盖的范围不同，因此其百分比并非转换率。将两者放在一起对比，就能清楚地看到其中的差异。

Woofun AI 整理数据显示，排名靠前的三类审计问题占了所有已公开审计发现的 37.6%，而私钥被盗和钓鱼攻击——这两类问题大多不属于常规的合同审查范畴——则导致了 43.9% 的资产损失。

如果再将依赖关系相关攻击和治理层面攻击纳入考量，那么'人为因素'这一类别所造成的损失比例则上升至 49.6%。这些故障的根源往往在于人员、操作流程以及第三方系统，而这些都是标准代码审查工作并未涉及的部分。对于这个 49.6% 的数字，其实也需要加上相应的警示说明。

极端案例进一步揭示了行业盗窃特征的结构性偏差。在总计 15.1 亿美元的钓鱼攻击损失中，Bybit 承担了 14.3 亿美元；在所有相关损失案例中，Bybit 也占了 18.4% 的份额。有 8 起案件就造成了全部损失的一半，剩下的 210 起案件则分担了其余的损失。加密货币领域的盗窃案往往存在极端的异常情况，这意味着某一起重大事件就足以改变整个行业的状况。

不过，这种更广泛的趋势并不仅限于 Bybit。在 45 起案件中都出现了私钥被窃的情况，即便在将钓鱼攻击纳入统计之前，它就已经是造成损失的最主要根源。从 2023 年到 2025 年，涉及密钥、人员、依赖关系或治理层面的攻击，每年造成的损失占比都在三分之二到四分之三之间。随着行业将专业精力集中在代码审查上，攻击者们则学会了绕过代码进行攻击。智能合约只不过是一座巨大建筑中的一个房间而已。用户通过网站和钱包进入这个房间，而该合约在执行操作之前可能还需要依赖外部提供的价格数据。多签机制用于管理敏感的资金转账，管理员权限则决定了谁有权修改软件。对于用户而言，整个系统看起来就像是一个完整的产品。

然而，对于攻击者来说，这里却是一系列由不同人员和使用不同软件负责守卫的'门'。Bybit 的链上组件能够执行经过妥善签名的交易。问题的起始点在于开发人员的电脑，他们首先制定了交易提案，随后通过某个界面向签名者表明他们正在批准一项常规操作。Bybit 随后重建了自身的基础设施，更换了凭证，并致力于让交易更容易被验证。这些措施其实都是针对那些已经按照规定正常执行的链上代码所采取的运营和界面方面的修复措施。

预印本研究显示，在 218 起案件中，有 105 起涉及在相关事件发生之前至少经历过一次公开审计的协议。这些案件涉及的损失金额约为 43 亿美元，占所有观测到损失总额的 55%，这一数字几乎就是为了便于被误用而刻意设定的。它并不能证明审计人员遗漏了价值 43 亿美元的具有漏洞的代码。'此前已审计'这一表述可能指的是另一个版本、另一组合同，或者与最终进入系统的路径无关的另一次审查。在该组 12 起损失最严重的案件中，有 9 起是由于钓鱼攻击、私钥被盗、依赖关系问题、基础设施故障或治理层面问题造成的。那些由代码问题引发的案件也同样难以简单下定论。以 Nomad、Euler 等项目为例，研究中发现，经过审查的代码与最终用于存储资金的软件之间存在后续开发的代码、被排除在外的路径以及其他差异。

如果将所有这些问题都归结为审计失败，那就犯了与研究初衷相悖的错误。由于这份报告是由审计行业内部人士撰写的预印本，因此也需要以谨慎的态度来解读。报告中没有提及具体的 22 家审计公司，这就无法对各家公司的表现进行评估，而且这些案件数据也仅来自某一家发布机构的相关档案。PDF 文件的提取过程进一步增加了信息的模糊性，部分分类工作还是在大语言模型（LLM）的辅助下、在人类监督下完成的。

此外，这份报告还缺乏未经审计的协议的对应数据，因此无法计算出审计实际上提供了多少保护作用。那些有价值的项目往往会更频繁地聘请审计机构，同时也更容易吸引更有能力的攻击者，因此它们同时出现在这两组数据中，根本无法说明二者之间的因果关系。

构建标准化、透明化的安全披露体系是破局关键。加密货币行业擅长委托某种类型的审查工作，但却不善于向用户说明这类审查的覆盖范围究竟到何处为止。审计公司能够胜任合同审查工作，托管服务提供商也能按照承诺妥善保管私钥。云服务提供商、监控公司和漏洞奖励平台都能完成各自负责的任务，但从开发人员的笔记本电脑到签名者的屏幕，再到最终部署的代码，这一整个流程却从未经过测试。相关细则表明，虽然面向公众的审计表述仍将安全性视为附着在代码库上的某种证书，但实际上应用程序才是整个系统的真正所有者。

审计标识应该少些华丽的辞藻，多些客观的事实描述。采用标准化的安全标签，就能让那些缺失的审查工作显现出来，尤其是当某个项目已经支付了合同审查费用，却忽略了与之相关的其他所有工作之时。报告的上方部分应当注明经过审计的代码提交时间以及审查日期，同时列出所有被审查的合同，以及任何尚未解决的严重或高严重程度的问题。另一部分则应说明实际部署的字节码是否与审查过的版本一致。生产环境中的配置也需要标注对应的验证日期，这样用户就能知道该报告是否适用于当前存储着资金的软件。

私钥管理及签名流程需要单独进行评估，前端基础设施和云访问权限也需要另作评估。构建系统应当说明代码版本是否有可能因某台机器被攻破而被篡改。监控系统和事故应对方案也应当标注日期，因为随着工作人员、服务提供商和软件的不断变化，这些系统的有效性也会随之下降。一旦有重要的代码版本发布，相关的记录就应该失效，直到再次经过测试为止。这样的格式既有助于审计人员的工作，也有助于用户了解情况。一个项目可以宣称其智能合约已经过审计，但同时却隐瞒生产环境部署并未经过验证、签名者安全措施也未经过审查的事实。

这样一来，审计人员就不再需要为那些被合约拒绝的承诺负责，而该项目也会有动力去完成那些缺失的审查工作。在某个 token 发行时或存款按钮旁边出现的'已审计'标识，应当详细说明究竟审查了哪些内容、哪些内容被排除在外，以及这些审查结果的有效期限有多长。该标识应当明确说明所进行的审查类型，列出所有仍在审查范围之外的关键系统，而不应成为一种无需任何专业机构背书就随便做出的承诺。