本文是针对在 Stellar 平台上开发 Soroban 智能合约项目的安全审计准备指南。内容涵盖了从设计阶段的威胁建模(STRIDE)、编写易于验证的 Rust 代码、进行模糊测试,到利用自动化工具(如 Scout 和 Sunbeam)进行预审计的完整流程,旨在帮助开发者在申请 Stellar 审计银行资助前提升代码安全性。
Stellar Security Audit Bank 在 Stellar Community Fund 的支持下,为构建 Stellar smart contracts 的、符合条件的 SCF 获奖项目 提供 security audits 资金。这是一个极其宝贵的机会。但要充分利用它,你需要先做好 audit 准备。一个准备充分的 codebase 意味着更快、更深入、也更有价值的 audit。本指南将带你完成准备的每个阶段,帮助你的项目为成功做好准备。
1. 从第一天起就为 Security 设计
“Security starts at the whiteboard, not at the code review” 是 cybersecurity 的传统格言。在你写出第一行 Rust 之前,先投入时间完成这些步骤:
- 定义你的 invariants。 在你的系统中,哪些属性必须 始终 成立?(例如:“total supply 永远不超过 X”,“只有 admin 可以 pause contract。”)尽早写下这些内容,可以为开发、测试以及最终的 formal verification 提供方向。
- 使用 STRIDE 进行 threat modeling。 Stellar Development Foundation 遵循 “STRIDE” 框架,并要求将 threat modeling 作为 Readiness Review 的一部分。STRIDE 帮助你系统地识别诸如 spoofing、tampering、information disclosure 和 denial of service 等威胁。Stellar 提供了完整的 Threat Modeling How-To Guide 以及可直接使用的 STRIDE template。
- 跳出 block(chain) 思考。 在过去一年中,crypto 领域许多最成功的攻击都是 “web2.5” 攻击——利用传统 web2 技术来 compromise keys。因此,关键在于考虑一种安全且稳健的 security architecture,遵循最小权限原则,同时密切关注 hot/cold wallet 分离。
- 警惕 resource DoS。 Soroban 的一项重要创新是其复杂的 resource model。然而,这也要求 protocol designers 和 builders 尽早密切关注 resource utilization,以避免 denial-of-service(DoS)攻击向量。请考虑 instance storage limits,避免无限循环。请有意识地在
Instance 和 Persistent storage 之间做选择,对所有由用户控制的写入施加严格边界,并在你的 threat model 中考虑 storage rent 成本。
- 记录你的 architecture。 记录操作的高层逻辑、信任假设、数据流以及每个 contract 的角色。内部和外部的审查者都需要这些上下文,才能有效评估你的代码。Audit Readiness Checklist 说得很清楚:你的提交应包含审查者所需的全部上下文。
需要实际操作方面的指导吗? Certora 于 2026 年 4 月 21 日举办的 Mastering Threat Modeling workshop 将深入讲解 STRIDE 框架。也欢迎参加我们下一场 Security Office Hours for Stellar Builders,在与 Certora security expert 的 live session 中提出问题。
2. 编写干净、便于 Verification 的代码
你编写 contract 的方式会直接影响它们能够被测试、分析以及 formal verification 的彻底程度。养成几个习惯会很有帮助:
- 使用标准库。 对于常见模式,不要重复造轮子。可以参考可信来源,例如 OpenZeppelin Soroban Helpers library,它提供了经过良好测试、由社区审查过的基础构件。
- 注意常见的 security 问题。 检查你的代码中是否存在 authorization/authentication 问题、integer overflow、arithmetic bugs 和 rounding errors、错误的 error handling,以及 storage key collisions。你也许可以在 The Soroban Security Portal’s vulnerabilities list 中搜索与你的 protocol 相关的关键词,从早期项目中学习。
- 保持函数小而模块化。 将数学公式隔离到它们自己的、没有副作用的纯函数中。这会让逻辑更容易推理、单独测试,以及借助自动化工具进行 verification。
- 避免 contract 之间的循环依赖。 干净的 dependency graph 可以降低复杂性,并使你的系统更容易被 auditors 理解。
- 为 verifiability 而写。 像避免过深嵌套的数据结构、尽量减少
Option 类型使用等模式,会让你的代码更适合 formal verification engines。若想更深入了解,请参阅我们的博客文章:Writing Verification-Friendly Smart Contracts in Rust。
- 扩大你的 scope。 考虑任何 off-chain code,验证所有输入,并审查 authentication、authorization、secrets management 等方面的 security best practices。Soroban Registry Security Guide 是一个很好的参考。
3. 严格测试
当 auditors 可以把注意力集中在细微的逻辑 bug 上,而不是去发现你自己测试本应捕捉到的问题时,他们的工作会高效得多。
- 争取高测试覆盖率。 在你的 contract modules 上使用
cargo test。不仅要覆盖 happy path,也要覆盖 edge cases 和 error handling。
- 对你的 contracts 进行 fuzz 测试。 Fuzzing 会向你的代码投放随机输入,以暴露意外崩溃和逻辑错误。Stellar 提供了出色的 fuzz testing guide,帮助你入门。
- 在 testnet 上运行 integration tests。 Unit tests 很棒,但在真实 testnet 上进行 end-to-end 测试可以验证你的 contracts 在现实环境中的行为是否正确,包括 cross-contract calls、resource management 和 transaction sequencing。
4. 在申请抢跑 Security 工具
Audit Bank 的 Pre-Audit Preparation 阶段要求你使用自助式 security tooling,在外部 audit 开始之前识别并修复漏洞。请查看 Stellar 推荐的 Security Tools 列表。当你找到一个可用工具后,将其集成到你的 CI/CD pipeline 中,这样它们就会自动运行,并在你做最后这些修复时捕捉可能遗漏的回归问题:
- 使用 Scout 等工具进行 静态分析,它可以检测 Soroban contracts 中常见的漏洞模式。
- 使用 Certora Sunbeam 进行 formal verification,这是我们为 Soroban 专门打造的 formal verification 工具。Sunbeam 验证的是 可部署的 Wasm bytecode(不是 Rust source),因此你可以确信编译后的 contract 满足你指定的正确性属性。请注意,formal verification 不包含在最初的 Audit Bank engagement 中,但它可以作为后续“traction milestone” audits 的一部分提供。
目标很简单:先自己修复那些容易发现的问题,这样 auditors 就能把他们的专业能力集中在那些即便是最好的自动化工具仍然会遗漏的深层、细微漏洞上。
5. 提交一份强有力的申请
当你已经收到 intake form 并且准备好申请时,请确保:
- 包含所有必需文档。 Architecture diagrams、threat models、测试结果、部署说明……一切都应包含在 Audit Readiness Checklist 中。记住:review panel 只会考虑你提交内容中包含的东西。
- 定义一个经过深思熟虑的 audit scope。 不要只把范围限制在核心 contract code 上。请考虑 cross-chain integrations、off-chain components、governance mechanisms 或 admin flows 是否也应纳入 scope。更广的 scope 意味着更全面的保护。
- 冻结。 这本不言而喻,但请准备在 audit 期间保持你的 codebase 不被修改。这样可以在 audit 过程中以及对发现的任何漏洞进行 remediation 时,尽量减少你与 audit team 之间的混淆。
- 请求你偏好的 security partner。 在 Audit Scheduling 期间,SDF 会考虑多个因素,包括你对 audit firm 的明确偏好。因此,你对谁来 review 你的 code 有发言权。
一旦你的项目准备就绪,Stellar Community Fund 就会向符合条件的、由 SCF 资助的项目 发送电子邮件 并附上 intake form。
准备好安全地构建了吗?我们随时可以提供帮助。
Certora 自 2023 年以来一直为 Stellar 提供 security 支持,其中包括用于 formal verification 的 Sunbeam。我们的团队 在 Rust、DeFi protocol design 以及 formal methods 的数学严谨性方面拥有深厚专长。无论你是在准备第一次 audit,还是希望在后续 engagement 中加入 formal verification,我们都很乐意与你合作。
- 按照上述步骤,让你的项目具备 audit-ready 状态。
- 在下一场 Security Office Hours for Stellar Builders 中带上你的问题。
- 在你的 Audit Bank intake form 上请求 Certora 作为你的 security partner。
Stellar ecosystem 正在构建非凡之物。让我们确保它建立在坚如磐石的 foundation 之上。