Day 55：安全基础(2) — 审计报告阅读

日期：2026-03-12 主题：学习如何阅读智能合约审计报告，精读 Aave V3 和 Uniswap V3 审计报告，产出阅读笔记

---

今日目标

---

一、为什么 PM 需要读审计报告

1.1 PM 不需要会写代码，但需要理解安全

PM 需要审计知识的场景：
├── 评估新协议集成风险："这个协议安全吗？可以集成吗？"
├── 产品决策中的安全权衡："这个功能会引入什么风险？"
├── 安全事件应对："被攻击了，影响范围多大？如何响应？"
├── 与安全团队沟通："审计发现了什么问题？修复优先级？"
└── 面试必备："你如何评估一个协议的安全性？"

1.2 审计报告的局限性

⚠️ 审计 ≠ 100% 安全

审计能做的：
├── 发现已知类型的漏洞
├── 代码质量和最佳实践评估
├── 逻辑错误和边界条件检查
└── 对已审计版本的代码给出安全评估

审计做不到的：
├── 保证无漏洞（审计后仍有协议被黑）
├── 覆盖经济攻击和治理攻击
├── 审计后代码更新的安全性
├── 预测零日漏洞
└── 防止管理员密钥被盗

→ 审计是安全的"基线"，不是"保证"

---

二、审计报告结构解析

2.1 标准审计报告结构

一份典型的审计报告包含：

1. Executive Summary（执行摘要）
   ├── 审计范围、时间、方法
   ├── 总体安全评估
   └── 关键发现数量统计

2. Scope（审计范围）
   ├── 审计的合约文件列表
   ├── Commit Hash（代码版本）
   ├── 排除范围
   └── 使用的工具和方法

3. Findings（发现）
   ├── 按严重程度分类
   ├── 每个发现包含：
   │   ├── 标题和描述
   │   ├── 影响分析
   │   ├── 漏洞位置（文件+行号）
   │   ├── 攻击场景（POC）
   │   └── 修复建议
   └── 团队回应和修复状态

4. Informational / Gas Optimizations
   ├── 非安全性问题
   └── 代码质量和效率建议

5. Appendix（附录）
   ├── 审计方法论
   ├── 工具列表
   └── 审计团队信息

2.2 漏洞严重程度分级

2.3 PM 快速阅读法（15分钟读完一份报告）

Step 1（2分钟）：读 Executive Summary
├── 总共发现多少问题？
├── Critical/High 有几个？
├── 整体评估是什么？
└── 如果有 Critical 未修复 → 高风险

Step 2（5分钟）：读所有 Critical + High
├── 问题描述是什么？
├── 影响范围多大？
├── 是否已修复？
└── 修复方式是否合理？

Step 3（3分钟）：看 Medium 的标题
├── 有没有经济模型相关的问题？
├── 有没有权限/治理相关的问题？
└── 快速判断是否与你的产品集成相关

Step 4（3分钟）：看团队回应
├── 所有 Critical/High 是否都已 Resolved？
├── 有没有 "Acknowledged but won't fix"？
│   └── 如果有，理由是否合理？
└── 有没有未回应的发现？

Step 5（2分钟）：看审计范围
├── 审计的代码版本和当前版本是否一致？
├── 有没有核心合约被排除在审计范围外？
└── 审计时间是否足够（<2周对复杂协议不够）

---

三、审计报告精读：Aave V3

3.1 报告概览

3.2 关键发现分析

High #1：闪电贷可绕过借款上限

问题：
├── Aave V3 引入了借款上限（Borrow Cap）限制每种资产的借款总量
├── 但闪电贷不受借款上限约束
├── 攻击者可通过闪电贷借出超过上限的资产
└── 影响：借款上限形同虚设

PM 解读：
├── 这是一个"新功能引入新风险"的典型案例
├── V3 新增了 Borrow Cap 功能，但没考虑到与闪电贷的交互
├── 功能之间的交互是审计最常发现问题的地方
└── PM 教训：新功能评审时必须考虑与所有现有功能的交互

修复：
└── 在闪电贷中也检查借款上限 → 已修复 ✅

High #2：价格预言机操纵在低流动性资产上可行

问题：
├── 某些低流动性资产的价格可在单个区块内被操纵
├── 攻击者可操纵价格 → 超额借贷 → 跑路
└── 影响：协议坏账

PM 解读：
├── 上币决策不仅是"用户需求"，更是"风险管理"
├── 低流动性代币 = 高操纵风险
├── PM 在评估新资产上线时必须和风险团队协作
└── 这就是为什么 Aave 有独立的 Risk DAO（Gauntlet/Chaos Labs）

修复：
├── 引入 Isolation Mode（隔离模式）限制新资产风险
├── 低流动性资产只能用作抵押品，不能被借出
└── 已修复 ✅

3.3 Aave V3 审计总结

安全评估：⭐⭐⭐⭐⭐（行业顶级）
├── 0 Critical，说明核心逻辑扎实
├── High 发现都是功能交互问题，非基础架构问题
├── 多家审计机构交叉审核
├── 所有 High/Medium 已修复
├── 持续的 Bug Bounty 计划（最高 $250K）
└── 独立的风险管理团队持续监控

---

四、审计报告精读：Uniswap V3

4.1 报告概览

4.2 Uniswap V3 审计总结

安全评估：⭐⭐⭐⭐⭐（行业顶级）
├── 0 Critical + 0 High → 核心代码极其健壮
├── Medium 都是边界情况而非核心逻辑问题
├── 代码量小（~2,500行）但复杂度高（数学密集）
├── Uniswap Labs 有 $3M Bug Bounty
└── 补充：Uniswap V3 部署后从未因合约漏洞被攻击

---

五、PM 审计检查清单

5.1 评估协议安全性的检查清单

## 协议安全评估检查清单

### 审计覆盖度
□ 是否有至少1份来自知名审计机构的报告？
□ 复杂协议是否有多家审计（交叉验证）？
□ 审计版本与当前部署版本是否一致？
□ 核心合约是否都在审计范围内？
□ 审计时间是否充足（复杂协议至少4周）？

### 审计结果
□ 有无未修复的 Critical/High？
□ "Acknowledged but won't fix" 的理由是否合理？
□ 是否有经济模型/治理层面的发现？
□ 之前的审计发现是否都已解决？

### 持续安全
□ 是否有 Bug Bounty 计划？奖金是否有吸引力？
□ 是否有实时监控和告警系统？
□ 是否有应急响应计划（暂停功能、升级合约）？
□ 合约是否可升级？升级权限由谁控制？
□ 是否有 Timelock（延时执行）？

### 团队与社区
□ 安全团队是否专业？是否有安全顾问？
□ 历史安全记录如何？被攻击过吗？如何处理的？
□ 社区是否活跃参与安全讨论？

5.2 知名审计机构

---

六、面试准备

问题：你如何评估一个协议的安全性？

30秒版本： 看四个层面。第一，审计覆盖——是否有知名审计机构审计、Critical/High 是否全部修复。第二，持续安全——Bug Bounty 奖金是否有吸引力、是否有实时监控。第三，团队能力——历史安全记录、是否有专业安全顾问。第四，架构设计——合约是否可升级、是否有 Timelock、admin 权限是否过大。

追问准备：

• Q：审计过就安全吗？→ 不。审计是必要条件非充分条件。很多被攻击的协议都经过审计（如 Euler、Cream）。审计后的代码更新、经济攻击、admin key 泄露都不在审计范围内
• Q：如何在安全和速度之间取舍？→ 分层处理。核心合约必须完整审计；非核心功能可以先用 Code4rena 竞赛式审计快速覆盖；上线后用 Bug Bounty 持续发现问题
• Q：PM 在安全事件中该做什么？→ 立即暂停受影响功能、发布公告告知用户影响范围、协调技术团队排查和修复、事后发布详细的事后报告（transparency builds trust）

---

参考

• Trail of Bits 审计报告库：github.com/trailofbits/publications
• Rekt News 安全事件库：rekt.news
• Code4rena 审计竞赛：code4rena.com
• 博客笔记：/blog/day55-audit-report

---

完成后

Day 56：安全事件响应流程，研究 Euler 被黑事件，产出面试题答案"被攻击如何应对"。