T5 · Security Engineer
从「找到几个漏洞」走到「交出一份让别人敢据此做决策的威胁模型」。
面向安全与审计方向。
本页里的「T5」指这条 Track。课程章节一律写成「第 T30 章」并带链接，两者不是一回事——章节 T5 讲的是 EVM Account Model。
这条 Track 适合谁
你能看出代码里的问题，但说不清严重程度。 你发现某处缺了检查，也知道它不对。可要判断它是高危还是信息级，你只能靠感觉，因为你没有一套把「技术缺陷」换算成「谁会损失多少」的方法。
你查得了实现，查不了经济。 重入、权限、精度这些有固定形状的问题你越来越熟。但一个每步调用都合法、靠资金规模就能把协议搬空的攻击，你读代码时完全看不见。
你的报告是一个发现列表。 交付物是「第 137 行建议改成这样」。团队修完了，你也复核了，但你给不出「这个协议在什么条件下依然会出事」的回答。
你用工具，但你不知道工具没看什么。 静态分析跑了，覆盖率上去了，模糊测试也接了。可「它们合起来一共覆盖了哪一类问题、漏了哪一类」，你没有一张清单。
分界线是这一句：你交付的不是你找到的东西，是这个协议的边界在哪里——包括它明确不防什么。
前置
安全不是独立于业务的技能。图谱里第 T29 章同时依赖第 24 章和第 T21 章，这条边说的就是：不懂预言机和清算，你就审不了 DeFi。
- 第 T7–T9 章
- 第 T12 章
- 第 T28 章
- 第 24 章
- 第 T21 章
- 第 T29 章
- 第 T30 章
| 必须先读 | 图谱里的理由 |
|---|---|
| 第 T7 章 到 第 T9 章 | 图谱里第 T28 章依赖第 T8、T9 章。审代码的前提是写过代码，而且写到能算出 Gas 构成的程度 |
| 第 T12 章 · Testing & Deployment | 同为第 T28 章的直接前置。没有 Fork 能力就写不出复现代码，而复现代码是这条 Track 交付物里最硬的一块 |
| 第 T28 章 · Smart Contract Security | 漏洞在两行之间的顺序里，在没被把守的那条路径上。这是整条 Track 的第一性原理 |
| 第 24 章 · Crypto 为什么不断发生归零和攻击 | 图谱里第 T29 章的直接前置。它提供的是攻击的分类学，不是案例集 |
| 第 T21 章 · Oracle | 同为第 T29 章的直接前置。预言机是协议最常见的单点，也是经济攻击最常见的入口 |
| 第 T29 章 · Protocol Security | 攻击者不用漏洞、只用钱能做到什么。那张攻击成本表是这条 Track 的核心工具 |
| 第 T30 章 · Audit | 威胁模型四问、不变量三类、四层工具的能力边界。毕业作品的结构直接来自这一章 |
强烈建议再补两章：第 T24 章 · MEV（交易顺序本身就是攻击面）和第 T26 章 · Cross-chain（信任假设由谁承担，是跨链事故的统一解释）。
你会学什么
- Audit
- Threat Model
- Fuzzing
- Formal Verification
- Economic Security
五个 topic 分成三组，加一条贯穿始终的职业规范。
一、Threat Model 与 Audit：把「查什么」变成一个可交付的决定
审计的范围就是它的能力边界，而范围由威胁模型决定。这一组要做到的是：接手一个陌生协议，两天之内写出它的威胁模型四问——谁会来攻击、想拿走什么、各自能做到什么、以及明确不防什么。
配套的是一套工作流程：从入口函数出发画出资金路径、标出每一条信任边界、列出所有外部依赖及其失效模式、再把权限矩阵拉成一张表（谁能调什么、改完立刻生效还是有延迟）。
分级也要学。严重程度不是感觉，是两个变量的乘积：可达性（攻击者需要什么前置条件）和影响（成功了能拿走多少、有多少人受影响）。写不出这两个变量的分级，就是在猜。
二、Fuzzing 与 Formal Verification：让结论不随下一次提交流失
这一组的产出物是会自动运行的东西。有状态模糊测试是主力，因为真实漏洞几乎都藏在调用序列里；形式化验证是特种兵，只用在逻辑短、性质能被精确表达、出错代价极高的几个函数上。
要练到的具体程度：
- 从一份陌生代码里反推出不变量，并能区分「安全性质」和「当前实现恰好如此」
- 会写模糊测试的调用序列生成器，让它真的能走到深层状态，而不是在浅层反复打转
- 会做覆盖率引导的调参，并能说出「跑了多久之后收益开始递减」
- 知道形式化验证的结论只在你写下的模型里成立，模型写错了，证明也是错的
三、Economic Security：不用漏洞，只用钱
这是把「会审代码的人」和「能审协议的人」分开的一组。核心工具是攻击成本表：列出每一类攻击者，算出他们需要多少资金、多少时间、多少笔交易，以及能拿走多少。
要覆盖的攻击面至少包括：价格操纵与闪电贷放大、治理提案的时间窗与投票权租借、流动性抽离造成的连锁、清算激励被反向利用、以及跨协议依赖的传染。
这一组最难的不是算术，是想到该算哪一笔账。方法是从「这个协议假设了什么」出发，逐条问「买通这个假设要多少钱」。
四、职业规范：这条 Track 的入场券
安全方向有一条别的方向没有的硬规则：你的练习对象是真实系统，而真实系统上的每一次越界都是事故，不是学习。
- 只读公开代码，只在本地或 Fork 环境复现。任何时候都不要对未经授权的线上部署发起交互式测试。
- 发现真实漏洞，走负责任披露：先联系项目方或其公开的披露渠道，给出修复窗口，在修复并确认之后再公开。
- 需要真实资产的验证，一律用测试网；确实无法避免时用小额，并且事先说明。
- 报告里不要写可以直接复制粘贴执行的主网攻击脚本。复现代码放在 Fork 环境里，这是行业惯例，也是你自己的保护。
毕业作品
一份真实协议的审计报告，含威胁模型、不变量与复现代码。
和毕业项目完全不同：毕业项目是你建一个东西，这份作品是你评估别人建的东西。它也是所有 Track 里最容易被雇主直接当成工作样本的一份——因为它的格式和真实工作交付物几乎一样。
选标的的建议：挑一个代码公开、规模适中（核心合约在两千行以内）、且已经有公开审计报告的协议。有公开报告是关键——你可以在做完之后对照，看看自己漏了什么、又看到了什么别人没写的。
复现代码别人能不能跑起来。 这一条对审计报告同样排第一。每一个发现都要配一个可执行的测试：clone 之后一条命令跑起来，在 Fork 环境里复现，输出前后状态对比。
明确写出这些测试只在 Fork 环境运行，不得对线上部署执行。 没有复现代码的发现，在专业评审里只算一条待验证的猜测。
威胁模型四问全部回答，第四问至少三条。 谁会来攻击（角色要包括你自己人：多签持有人、升级权限持有人）、想拿走什么、各自能做到什么、明确不防什么。
第四问是区分专业和业余的地方。每一条都要写清「如果发生了，后果由谁承担」。
不变量清单加上跑过的模糊测试。 至少八条，三类都要有覆盖。每条注明违反后的后果，以及它是怎么被自动检验的。
留下一次「故意破坏、被抓到」的记录，包括最短失败序列。一个永远绿的检查等于不存在的检查。
一张攻击成本表。 至少三类攻击者，每类给出所需资金、所需时间、所需交易笔数、以及成功后的收益上限。
结论要落到一句可判断的话：在当前参数下，哪一类攻击是划算的。 如果全都不划算，说明是什么撑住了这个结论——是资金门槛、是时间锁、还是流动性深度。这句话比整份报告的其余部分都重要。
每个发现有分级，分级有依据。 严重程度写成两个变量：可达性与影响。不要只给一个标签。
报告开头写明范围：你审了哪些文件、哪个提交、哪些内容明确不在范围内。第 T30 章里那个「17 个发现全修完仍被搬空」的团队，栽的就是没人细读这一页。
怎样判断自己达标了
威胁模型与不变量清单。
发现列表描述的是「这里曾经写错过」，它在交付那一刻价值最高，之后每一次提交都会让它衰减一点——团队上线后改的每一行代码都不在它的覆盖范围里。
威胁模型定义的是边界，它回答「这个协议认为什么是危险的」。不变量会被接进测试流程，跟着代码库一起活下去：以后每改一行，这些性质都会被重新验证一遍。
所以正确的交付姿势是：发现列表是这次的产出，威胁模型和不变量是留给团队的能力。
问一句：如果它被违反了，有人会亏钱或者失去控制权吗。
「所有用户余额之和不超过合约实际持有的资产」——违反了就有人取不出钱，是安全不变量。
「内部数组的长度等于用户数」——换一种实现它就不成立了，但协议一点也不会更危险，是实现细节。
这个区分在使用 AI 辅助时特别重要：模型倾向于把「当前代码恰好如此」写成不变量，而这类断言全部成立，一条都不保护资金。
价格操纵：在流动性较薄的市场把某个抵押品的价格推上去，用它借走远超真实价值的资产，然后放弃仓位。资金可以来自闪电贷，本金需求接近于零。
治理攻击：在市场上借入或买入足够的治理代币，提一个把参数改到对自己有利的提案（比如把某个资产的抵押率调高），执行后套利，再把代币还掉。决定它可行性的是时间锁长度和代币的可借深度。
清算激励反向利用：在市场剧烈波动时占住清算通道，或者制造让清算无法完成的条件（比如抽走清算人卖出抵押品所需的流动性），让协议积累坏账，同时在别处持有从坏账中获益的头寸。
三条的共同点：每一步调用都完全合法。 这正是只审实现的报告照不到它们的原因。
三样工具都只能验证你已经表达出来的性质。
静态分析找的是有固定形状的已知模式，它不知道你这个协议的业务逻辑。模糊测试找的是违反你写下的不变量的状态组合，你没写出来的性质它不会替你想。形式化验证在你给定的模型里给出必然结论，模型之外的事它不管。
所以三样合起来漏掉的是同一类：你没想到的那一整类攻击者。 它不在任何列表里，也无法被直接统计。
唯一的间接手段是回到威胁模型第一问，检查有没有一整类角色被忽略——最常被忽略的两类是「能借到无限资金的套利者」和「你自己」。
没有标准答案，检查三件事：
- 你有没有先确定范围和威胁模型，而不是一上来就逐行读代码。两天读不完，也不该读完。
- 你有没有先画出资金路径和权限矩阵。钱从哪进、从哪出、谁能改规则——绝大多数高危发现都在这两张图上。
- 你有没有留时间给「明确不防什么」。这一节是团队最需要、也最可能从来没人替他们写过的东西。
一个反面信号：如果你的两天全花在读代码上，交付物大概率会是一个发现列表。
常见误区
「找到的漏洞越多，审计质量越高」
发现数量衡量的是实现层的粗糙程度，不是评估的深度。一份列了 23 条低危的报告，可能完全没碰经济假设；一份只列了 6 条的报告，如果带着威胁模型和不变量，价值高得多。
正确做法：把「这个协议在什么条件下依然会出事」当成报告要回答的主问题，发现列表只是回答它的过程中产生的副产品。
「工具跑完就是查过了」
静态分析是过滤器，不是判决书，误报率不低；模糊测试只检验你写下的不变量。工具的输出需要你判断，而判断的依据是威胁模型。
正确做法：把工具输出分成真问题、误报、漏报三类。前两类看得见，第三类只能通过「威胁模型里有没有一整类攻击者没被覆盖」间接推断——而它才是最危险的那一类。
「审计是上线前的一道关」
审计是一次快照。代码在变、依赖在变、市场条件在变，而报告不会跟着变。你依赖的一个外部协议升级了它的实现，你一行代码没改，安全假设可能已经不成立了。
正确做法：把审计的成果做成会持续运行的东西——不变量进 CI、关键假设进监控（比如「依赖合约的实现地址发生变化」要告警）。审计的价值取决于它留下了多少会自己运行的东西。
「我只审代码，经济模型不归我管」
这句话在报告里写清楚是专业的（那叫范围声明），在心里默认是危险的。现实是，多数团队不会另外找人审经济模型，你的范围声明对他们来说等于「这部分没人看」。
正确做法：即使不在收费范围内，也在报告里留一节，写明你注意到但未深入评估的经济假设，并建议他们自己算一遍攻击成本。指出一个你没审的风险，比多找三条低危有用得多。
接下来
- 带着自己的标的重读：第 T28 章、第 T29 章、第 T30 章。
- 要审 DeFi 协议，Track T4 · DeFi Engineer 那条线的机制理解是硬门槛，不是加分项。
- 常见组合：加 Track T1 · EVM Engineer 补实现深度，加 Track T3 · Onchain Data Engineer 做攻击后的链上取证与持续监控，加 Track T6 · AI × Crypto Engineer 研究模型参与决策带来的新攻击面。
- 用 AI 辅助审计前，先读AI 安全链路与第 T31 章：AI 提高的是产出速度，Review 的责任一点没有转移。
- 跨到非技术侧：Track N5 · Crypto Founder。创业者最贵的一课是「安全预算该花在哪一步」，而这个问题只有审过协议的人答得出来。
- 想从「审别人的」换到「建自己的」，去毕业项目。