授权范围：仅对你拥有或获准审查的代码使用本清单。本文用于防御性审查，不讲解如何利用线上合约。
1. 先确认审查的具体版本
记录代码仓库、分支或发行版本、提交编号、编译器版本和相关构建设置。如果线上系统使用代理合约，还应确认授权范围是否包含实现合约和升级路径。旧版本上的正确观察，不一定适用于当前部署版本。
2. 核对告警背后的证据
代码位置报告指向的函数和代码行，是否与本次提交一致？
执行路径能否说明输入和状态如何到达被标记的操作？
触发条件需要哪些权限、状态、时间条件或外部行为？
是否可达在合理状态下，审查范围内的调用者能否走到这条路径？
实际影响什么安全属性可能失效，会影响哪些用户或资产？
覆盖边界哪些合约、依赖、配置或代码路径没有检查？
3. 把可信度和严重程度分开
可信度说明现有证据有多支持这条判断；严重程度说明如果判断成立，可能造成多大影响。两者都应明确：影响很大的推测仍需要验证，证据充分的问题也可能只有有限影响。
4. 安全、可重复地验证
在获准的本地测试环境或受控分叉环境中验证。测试应对应已审查的提交，记录假设，不要向线上系统发送交易或修改状态。其他审查者应能看懂测试并复现同一结论。
5. 写出别人可以核对的报告
- 注明审查提交、范围和工具版本。
- 把每条判断关联到文件、函数和具体代码位置。
- 用清楚的语言说明前置条件、推理过程和实际影响。
- 区分待核实、已确认、已排除和超出范围的项目。
- 列出重要假设、未测试区域和防御性修复建议。
没有告警不等于安全。自动化检查可能漏报，也可能误报。报告应说明覆盖限制；对影响重大的系统，还应安排独立复核。