内容摘要：2023年秋天，一个叫"闪电贷"的攻击在半小时内从某DeFi协议卷走了2800万美元。代码审计报告三个月前刚签过字，结论是"未发现高危漏洞"。问题出在哪？审计员漏看了一个修饰符——onlyOwner写

2023年秋天，加密一个叫"闪电贷"的漏洞攻击在半小时内从某DeFi协议卷走了2800万美元。代码审计报告三个月前刚签过字，测评结论是加密"未发现高危漏洞"。问题出在哪？漏洞审计员漏看了一个修饰符——onlyOwner写成了onlyowner，Solidity编译器不报错，测评因为那只是加密一个未定义的外部函数调用。就这么一个字母的漏洞大小写，合约的测评控制权直接敞开。

这类事我见得太多。加密加密漏洞测评不是漏洞拿着工具跑一遍就完事的活。工具能查重入、测评能标出整数溢出，加密但真正掏空资金的漏洞漏洞，往往藏在业务逻辑的测评褶皱里。Slither和Mythril这类静态分析器对已知模式很敏感，可一旦攻击路径需要跨三个合约、绕两轮代理升级，它们基本就瞎了。

去年我参与过一次针对跨链桥的测评。桥的锁定合约看起来没问题，验证者签名逻辑也符合规范。但我在读前端代码时发现，中继器提交证明的接口没有校验chainId。这意味着攻击者可以在一条廉价链上伪造事件，让桥在以太坊主网上释放资金。这个漏洞静态工具扫不出来，因为它不理解"跨链消息来源可信"这个前提本身可能被打破。后来我们把它归类为"信任边界模糊"，写进了报告的高危项。

测评里最容易被忽视的是权限配置。很多项目方把管理员私钥放在热钱包里，多签设置成2/3，其中两个签名者还是同一台服务器上的两个进程。这种设计在纸面上满足"多签"要求，实际单点故障依旧。我习惯在测评时直接要他们的部署脚本和运维文档，比看合约代码更能暴露问题。有一次，部署脚本里明晃晃写着PRIVATE_KEY=0xac09...，连环境变量都没用。项目方解释说那是测试网，但主网部署脚本用的是同一个模板。

经济模型层面的漏洞更隐蔽。某借贷协议把清算阈值设成85%，抵押品是波动性极高的 meme 币。表面看参数正常，可一旦市场剧烈波动，清算机器人来不及平仓，坏账就会累积。这种漏洞没有代码错误，纯粹是参数设计对极端行情的估计不足。测评时得跑蒙特卡洛模拟，把历史波动率代进去，看穿仓概率。工具不会告诉你这些，得靠人对市场的理解。

说回开头的案例。那个onlyowner漏洞后来被修复了，但项目方在修复时又引入了一个新问题：他们把函数可见性从external改成public，导致内部调用也能触发。审计报告里没提这个，因为二次审计只看了diff，没重新跑完整测试。测评的连续性比单次深度更重要。代码在变，威胁模型也在变，一次通过不代表永远安全。

我现在的习惯是，每份报告最后附一个"未验证假设"清单。比如"假设多签持有人之间没有串谋"、"假设预言机报价不会被闪电贷操纵"。这些假设一旦不成立，前面所有分析都要推倒重来。客户通常不喜欢这部分，觉得不够确定。但漏洞测评的本质不是给安全感，是给风险地图。地图上得标清楚哪里是已知雷区，哪里是未探明的盲区。

工具在进步，AI辅助审计也开始冒头。但代码是人写的，漏洞也是人留的。理解人的意图和疏忽，比理解机器指令更难，也更重要。