智能合约端到端安全审查：用 Trail of Bits…

在每次提交、部署前或需要完整安全审查时，对智能合约项目执行系统化的五步安全开发工作流。

适用场景

解决思路

1. 第 1 步：用 Slither 的 70+ 内置检测器扫描已知安全问题；按严重程度解析结果，结合文件引用解释每个问题，给出修复建议，并协助判定误报；目标是得到干净的 Slither 报告或已记录的分诊结论。
2. 第 2 步：检测并验证适用的特殊功能——可升级性用 slither-check-upgradeability（覆盖 17 类升级风险）、ERC 合规性用 slither-check-erc（覆盖 6 个常见规范）、代币集成推荐 token-integration-analyzer 技能、安全属性用 slither-prop 处理 ERC20；只运行适用于当前代码库的检查。
3. 第 3 步：生成三张安全可视化图——继承图（识别遮蔽与 C3 线性化问题）、函数摘要图（展示可见性与访问控制）、变量与授权图（映射谁能写入状态变量），并逐图审查安全隐患。
4. 第 4 步：协助记录关键安全属性——状态机转换与不变量、访问控制要求、算术约束与精度、外部交互安全性、标准合规性；然后搭建测试：用 Echidna 做基于属性的模糊测试与不变量测试，用 Manticore 做符号执行的形式化验证，用自定义 Slither 检查覆盖项目特定业务逻辑；这是安全工作中最重要的活动。
5. 第 5 步：人工审查自动化工具覆盖不到的区域——隐私（链上秘密、commit-reveal 需求）、抢跑（滑点保护、排序风险、MEV）、密码学（弱随机性、签名问题、哈希碰撞）、DeFi 交互（预言机操纵、闪电贷、协议假设）；在代码库中搜索这些模式并标记风险。
6. 执行时先探索代码库理解结构，再依次运行第 1 步 Slither 扫描、第 2 步适用的特殊功能检查、第 3 步可视化图生成、第 4 步安全属性文档指导、第 5 步人工审查区域分析，最后给出按优先级排序的修复与后续步骤行动计划；根据已安装工具、项目适用性和开发阶段灵活调整。
7. 不要以“Slither 不可用就手动检查”为由跳过——手动检查会漏掉 70+ 检测器模式；应安装并运行 Slither，或记录受阻原因。
8. 不要以“无法生成图就用文字描述架构”代替——描述不是可视化，图能揭示文字遗漏的模式；应执行 slither --print 命令生成真实可视化输出。
9. 不要以“未检测到升级就跳过可升级性检查”为由跳过——代理和升级常是隐式或计划中的；跳过第 2 步检查前先用代码库搜索确认。
10. 不要以“不是代币就跳过 ERC 检查”为由跳过——代币可能在没有明显 ERC 继承的情况下被集成；跳过前先检查代币交互、转账、余额。
11. 不要以“现在无法搭建 Echidna，建议以后再做”为由推迟——基于属性的测试是第 4 步，不是可选项；应现在记录属性并搭建模糊测试基础设施。
12. 不要以“没有 DeFi 交互就跳过预言机/闪电贷检查”为由跳过——DeFi 模式会出现在意外之处（价格源、外部调用）；应完成第 5 步人工审查并在代码库中搜索相关模式。
13. 不要未经代码库搜索验证就宣称“这一步不适用于我的项目”——未经验证的“不适用”等于漏掉漏洞；声明 N/A 前必须显式搜索确认。
14. 不要用通用安全建议代替运行工作流——通用建议不可执行，工作流能发现具体问题；应执行全部 5 步并生成带 file:line 引用的项目特定发现。
15. 最终交付安全报告（含 Slither 发现及严重程度与修复、特殊功能验证结果、PNG/PDF 可视化图、人工审查发现）、行动计划（立即修复的关键问题、待记录的安全属性、待搭建的 Echidna/Manticore 测试、待人工审查区域）和工作流检查清单（干净的 Slither 报告、特殊功能已验证、可视化检查完成、属性已记录、人工审查完成）。

适用边界 · 注意事项

• 只想针对单个 bug 进行排查，而非端到端保障合约安全时
• 尚未安装 Slither 等必要工具且无法安装或记录受阻原因时
• 项目完全不涉及智能合约或链上代码时