安全审计：一份审计报告究竟告诉了你什么
“经某某审计”是加密领域最常见的徽章之一。它出现在网站上、融资演示文稿里和代币发行活动中，常常被当作已经回答了“某样东西是否安全”这个问题。事实并非如此——但一份真正的审计报告，只要读法得当，能告诉你非常多的信息。诀窍在于知道该看什么。
什么是审计
安全审计是由外部机构在限定时间内对特定代码进行的审查。审计人员会阅读代码、测试代码、尝试攻破它，并把发现的问题写成文字。对于智能合约，这通常意味着人工审查加上自动化工具；对于钱包，审计范围可能包括应用本身、密码学实现、应用所连接的服务器，以及这些部分如何协同工作。
审计的产出是一份报告：审查了什么、何时审查、发现了什么、每个问题的严重程度如何，以及团队是否已经修复。
这段描述中有三个短语比其他内容更重要**：特定代码****、限定时间以及发现了什么**。
先读审计范围
审计范围准确说明了审计人员看过哪些内容——通常是指明名称的代码仓库、合约或组件，并且往往固定在某个特定的提交版本上。
大多数误导性的“已审计”说法，正是在这里站不住脚的。一个项目可能只审计了一个小合约，却宣传整个协议都已审计。一款钱包可能审查了它的智能合约，而真正构建并签署你交易的应用却从未被检查过。如果你所信任的东西不在审计范围内，那么这次审计对它没有任何结论。
问问自己：审计范围是否覆盖了接触我资金的那些部分？
核对日期和版本
审计描述的是代码在接受审查当天的状态。此后发布的一切——新功能、新链、代码重构——都不在审计之内，除非它们再次接受了审查。
这很正常，软件总在不断变化。但这意味着，对一个快速迭代的项目而言，两年前的审计只是一份历史文档。真正有用的问题是：审计是什么时候做的，覆盖的是哪个版本，以及此后的重大变更是否经过了单独的审查。
对智能合约来说还有一层额外的复杂性：如果合约是可升级的，那么今天运行的代码可能并不是当初被审计的代码。谁控制升级与审计本身同样重要。
读具体发现，而不只是摘要
审计报告会按严重程度对发现的问题分级——通常分为严重、高、中、低和信息性几个等级——并记录每个问题是已修复、已确认，还是维持原状。
- 严重级和高危级问题是可能导致资金损失的问题。有没有这类问题？如果有，是否已修复并经过复查？
- 已确认不等于已修复。“已确认”意味着团队接受了这一风险。有时这是合理的，但请看清理由。
- 零发现并不自动等于好消息。它可能意味着代码非常出色，也可能意味着审计范围狭窄、工作周期很短。
- 复测很重要。一份好的报告会写明审计人员验证了修复，而不只是团队声称已经修复。
审计无法告诉你的事
即便是一次彻底的审计，也有一些值得直白说明的局限：
- 它是对注意力的一次抽样，而不是一份证明。审计人员能发现很多漏洞，但不可能发现全部。经过审计的协议也曾遭到攻击。
- 它覆盖的是代码，而不是运营。密钥如何保管、谁有权部署、团队如何应对安全事件——这些通常都不在范围之内。
- 它不覆盖经济模型设计，除非这部分被明确纳入审计范围。一个合约可以完全按照代码所写的那样运行，却仍然可能通过价格、激励机制或其他协议被利用。
- 它不覆盖你实际安装的东西。对源代码的审计，无法说明一个同名的假冒应用是否可信。可复现构建才是把公开代码与你实际运行的软件联系起来的手段。
“已审计”说法中的危险信号
- 没有指向实际报告的链接，或者报告只托管在项目自己的网站上。
- 找不到这家审计机构，或者其官网上并未列出这次审计项目。
- 审计范围与宣传内容不符。
- 未修复的高危问题被描述为“已处理”。
- 只有一次多年前的审计，而产品自那以后已经彻底改变。
SSP 的做法
SSP 的代码是开源的，任何人都可以阅读——但开源代码和经过审计的代码不是一回事，我们会分开对待。
独立安全公司 Halborn 审计了 SSP 的 ERC-4337 智能合约，并对 SSP Wallet 浏览器扩展、SSP Key 应用和 SSP Relay 进行了整体审计。两份报告都公开发布在 Halborn 的官网上，没有严重级或高危级问题，低危和信息性问题也均已处理。我们的 2025 年审计回顾列出了每次审计的范围和日期。
适用于任何人的注意事项同样适用于我们。这些审计覆盖的是代码在接受审查时的状态；此后新增的功能和链并不在其覆盖范围内。因此，对于较新的代码，我们会说明它经过了哪种审查，而不是拿一枚旧徽章去硬套。
坦诚的总结
审计是证据，而不是保证。它告诉你：特定的代码，在特定的时间，由特定的机构审查过，以及他们发现了什么。
读审计范围，核对日期和版本，查看问题的严重程度及其处理方式，并在审计机构自己的网站上找到这份报告。做到这些，“已审计”就不再只是一枚徽章，而是真正有用的信息。
