一篇让你“读完就能上手”的智能合约审计指南

前言

想象一下：你把合约部署到链上那一刻，它就像被“刻”在区块链的石头上——公开、可调用、难以修改，还经常直接管着真金白银。\ 这也是为什么 Web3 里常听到一句话：上线不是发布，是“交付到对手手里”。

所以我们需要 合约审计（Smart Contract Audit）：在合约上链/升级前，用系统化的方法把潜在问题尽可能找出来，并给出修复建议。OpenZeppelin 把它描述为一种“系统化检查，用于发现漏洞并提出解决方案”的过程。

1. 合约审计到底在“审”什么？

把合约审计想成 三件事：

1. 审“钱”：资产怎么进、怎么出、谁能动、动多少、边界条件是什么。
2. 审“权”：管理员、owner、多签、角色权限、升级权限有没有被滥用的可能。
3. 审“逻辑”：有没有“不符合设计预期”的路径（包括极端输入、组合调用、跨合约交互）。

审计最终会交付一份报告：列出发现的问题、影响、严重性，以及怎么修。OpenZeppelin 的描述也强调了：审计在和项目方确定范围后系统性排查，最后输出 findings report，项目方再进行修复加固。

2. 为什么审计这么重要？

2.1 链上程序的“残酷现实”

• 公开透明：代码/字节码、交易、状态全公开，攻击者也能研究。
• 不可逆/难修复：出事不是“回滚一下”，更多是“损失已发生”。
• 攻击面巨大：不仅是单合约 bug，还有预言机、权限、升级、外部依赖等系统性风险。

OpenZeppelin 在其关于审计必要性的文章里引用了行业数据，强调了审计在“保护资金、提升代码质量”上的价值。

2.2 审计不是“免死金牌”

审计的目标更像：把风险从“未知”变成“已知”，再把“已知风险”尽可能降到可接受。\ 所以成熟团队会把审计放进一个更完整的安全开发生命周期：Plan → Code → Test → Audit → Deploy → Monitor。

3. 审计前要准备什么？（项目方视角）

你给审计师的材料质量，直接决定审计效率和深度。

必备清单（越齐越省钱）：

• ✅ 代码仓库（最好 GitHub / GitLab），并提供明确的 commit hash / tag
• ✅ 架构说明：合约之间怎么交互、关键角色、关键资产流
• ✅ 业务规则：哪些行为“必须允许”，哪些“绝对不允许”
• ✅ 测试：单测/集成测试、部署脚本、模拟环境说明
• ✅ 依赖：用到的外部合约地址、库版本、代理模式等

ConsenSys Diligence 也明确提到：文档是成功审计的前提，好的文档能帮助威胁建模与漏洞识别，让审计师少花时间“读懂项目”，更早进入“找 bug”。

4. 标准合约审计流程

下面这套流程，既适合你“自己审自己”，也适合你理解外部审计在干嘛。其中关键环节：代码获取、范围确定、漏洞识别、报告撰写，并提到可用工具做辅助（如 Solidity Metrics、CLOC），还通过“密码存储”合约做了演示。

4.1 一张图看懂全流程

4.2 Step 1：获取代码（别从浏览器“抄代码”）

特别强调：从可靠仓库（如 GitHub）获取代码，避免直接从区块链浏览器复制来审计。原因很简单：

• 浏览器代码可能不完整（依赖、编译参数、子模块缺失）
• 版本不一致（你审的不是最终部署的那份）
• 审计需要可复现环境（测试、脚本、配置） 你要做的：锁定 commit hash + 编译配置（solc 版本、optimizer、viaIR 等）。

4.3 Step 2：确定范围（Scope，不然你会“审到天荒地老”）

Scope 一般至少包含：

• 哪些合约/目录在本次范围内
• 是否包含脚本、部署、预言机、权限系统、多签配置
• 是否包含升级合约、初始化、管理员操作路径
• 明确“不审什么”（比如前端、节点、运维）

课与项目方沟通明确范围（合约、版本等）是流程关键。

4.4 Step 3：先建立“系统地图”，再开始找问题

一个很实用的顺序：

1. 找入口：用户能调用哪些外部函数？
2. 画资产流：钱从哪来、到哪去、什么时候结算？
3. 找信任边界：哪些外部调用、哪些回调、哪些可控输入？
4. 找特权路径：owner / role / upgrade / emergency 的能力边界？

小技巧：先把“设计预期”写成几条不变量（invariants），后面审计和测试都会更稳。

4.5 Step 4：自动化扫描 + 代码度量（用工具帮你“扫雷”）

自动化工具不会替你思考，但它能：

• 快速提示常见模式风险（比如不安全的外部调用、可疑权限）
• 让你对代码规模、复杂度、重复率有直觉
• 帮你决定“先审哪里最划算”

可用 Solidity Metrics、CLOC 做辅助。 （你也可以把它们理解成：代码体检报告——告诉你哪里“脂肪多、压力大”。）

4.6 Step 5：手工审计（真正的“硬菜”）

手工审计建议按“资金优先级”切：

• 最高优先：存取款、赎回、清算、swap、mint/burn、桥相关、升级/初始化
• 中优先：参数配置、费率、白名单、暂停/恢复
• 较低优先：事件、view 函数、辅助工具

OpenZeppelin 提到审计通常是逐行检查并以协作方式与开发者沟通，必要时还会用 fuzzing / invariant testing 等高级测试技术。

4.7 Step 6：测试验证（你不是在“猜”，你要在“证”）

常见验证方式：

• 单元测试：覆盖边界条件（0、最大值、权限切换、极端顺序）
• 集成测试：模拟真实用户流程（多合约交互）
• 模糊测试 / 不变量测试：验证“在任意输入下都不应发生 X”

4.8 Step 7：分级与结论（别把所有问题都写成 Critical）

一个常用分级口径（示例）：

• Critical：可直接/高概率造成资金损失或控制权丢失
• High：重大风险，资金/权限有明显威胁但需条件
• Medium：可导致业务异常、资金卡死、会被利用放大影响
• Low / Info：最佳实践、可读性、gas/一致性问题

4.9 Step 8：写报告（交付物=让人能修）

强调报告要写清楚：漏洞描述、影响、复现步骤、修复建议。 下面我给你一个“可直接套用”的模板。

5. 审计报告怎么写才“像回事”？

目标不是“写得吓人”，而是：开发者看完能复现、能修复、能验证修复有效。

5.1 单个问题条目模板（Markdown）

## [H-01] 标题：一句话说清问题本质

**Severity**: High  
**Impact**: 会导致什么后果（资金、权限、DoS、数据错误）  
**Likelihood**: 触发难度（高/中/低）  

### Description
用“发生了什么”解释清楚：  
- 哪个函数/模块  
- 依赖什么条件  
- 违反了什么安全假设/业务规则  

### Recommendation
给出可执行的修复建议：  
- 改逻辑 / 加校验 / 调整权限 / 使用成熟库  
- 如果涉及设计，说明替代方案权衡

### Notes (Optional)
补充：边界情况、可能的误报、修复后需要关注的回归点

5.2 报告结构建议

• 项目概览（版本、范围、假设）
• 方法论（手工 + 工具 + 测试）
• Findings 列表（按严重性排序）
• 修复状态（Fixed / Acknowledged / Mitigated / Unresolved）
• 附录（测试环境、关键不变量、工具输出摘要）

6. 新手怎么练：从零到能做小审计

如果你是新手，建议走“低门槛但高反馈”的路线：

1. 先做审计竞赛/公开靶场：能看到别人的高质量报告写法，也能练“分级与表达”。也鼓励去 CodeHawks 参与竞争性审计提升技能。
2. 复盘经典审计报告：学“问题怎么描述、怎么给修复建议”。
3. 每次只练一个主题：比如今天只盯“权限与升级”，明天只盯“资产流”。
4. 形成自己的清单（Checklist）：把你常漏的点写下来，下次审计照着扫。

CodeHawks 文档对“什么是竞争性审计”有清晰定义：研究者在限定时间内审阅代码、提交问题，按有效性与严重性获得奖励。