掌握威胁建模：Soroban智能合约的安全蓝图

安全关乎方法论。但方法论只有在人们实际使用时才有效，这意味着它必须简单到易于维护，清晰到他人能顺利理解，并且专注到足以凸显风险。这三个特性——简单、清晰、专注——是任何有用威胁模型的基础。

在 Certora，我们开发了一套威胁建模方法，并已应用于 DeFi 中一些最大的协议。我们反复发现，那些在编写第一行代码之前就投入威胁建模的团队，最终会拥有更简单的架构、更少的漏洞和更快的审计。对于已经推进到一定阶段的项目，开始这一宝贵过程也永远不晚。编写一份威胁模型文档并持续更新始终是值得的。

本文基于我们的 4月21日研讨会，介绍了我们的方法以及 Stellar 开发者基金会使用的威胁建模工具，并解释了这两种互补工具如何为保护你的 Soroban 智能合约奠定基础。

威胁建模至关重要，尤其是当系统不断增长时

开发者或许能在脑海中记住中等规模项目的所有运作环节。但随着协议成熟，涉及更多市场、更多集成方、更多链下基础设施、更多多重签名签名者……任何单一人员都无法掌握全貌。集成了哪些预言机提供商？它们有哪些已知问题？我们的完整依赖供应链是什么？我们对每个参与者及其密钥的安全假设是什么？

没有结构化的方式来捕捉这些信息，随着时间的推移，心智模型中的空白必然会形成。最近我们有一个客户，威胁建模迅速发现了一个漏洞——如果他们在开发周期早期就创建了威胁模型，这个漏洞本可以更早被发现。他们可能已经意识到，他们使用的某个预言机存在一个与其特定代币相关的已知漏洞。仅仅是将该预言机列出，并附上名称或联系人，就创造了一个之前不存在的可见考虑点。

这就是威胁建模的核心承诺：以最小开销获得最大安全可见性。

即使你的项目没有那么庞大复杂，进行类似于下面描述的过程也有充分的理由。即使是小规模的威胁模型，对你和你的审计师也非常有帮助，甚至可能是注重安全性的利益相关者和融资的要求——稍后会详细说明。

4A 框架

Certora 创建并持续使用的框架围绕系统的四个“A”类别构建。我们在审计 Web2 项目和 Web3 项目时都广泛采用此框架。

A1 - 资产：我们在保护什么？

资产是你关心的一切，即需要保持安全、可用或完整的事物。资产可以包括：

• 链下基础设施（服务器、数据库）
• 私钥和签名者钱包
• 协议可用性（正常运行时间作为要求）
• Gas 成本可预测性
• 声誉和治理完整性

问：我们最关心什么？什么算得上是灾难性故障？ 不要指望一次就能列出完整的清单，但可以先列出清单并持续思考。即使只是一个单行清单：“资产：用户流动性”，也比没有清单更有用。经常重新审视，并随着协议的发展而扩展。

A2 - 参与者：谁和什么拥有访问权限？

每个以有意义的方式与你的系统交互的地址、合约或外部服务都是参与者。这包括：

• 管理员和治理合约
• 多重签名签名者
• 流动性提供者和交易者
• 预言机合约及其操作者
• 你集成的外部协议
• 你集成的内部协议

经验法则：如果一个地址或服务在你的系统中具有不同的控制流，它就应该属于这个列表。如果你无法清晰地列举你的参与者，这表明你的系统已经变得过于复杂而无法安全推理，可能需要进行设计审计。

A3 - 假设：我们简单信任什么？

这通常是最难的类别，因为它需要承认你尚未完成的事情。需要记录的假设包括：

• 你信任的外部服务（预言机提供商、桥接基础设施等）
• 假定安全的代码库部分（例如，第三方库）。你应该链接你的审计历史，以便轻松交叉引用什么时候由谁审计了什么。
• 你有意识地决定不考虑的攻击场景，以及原因。考虑被攻破的预言机和多重签名、拒绝服务、闪电铸造和不受支持的 ERC-20 类型。

记录假设可以创建你风险面的诚实地图，并为未来的审计师提供记录。当新团队接手你的协议时，假设部分会告诉他们该从哪里开始提出有趣的问题。

A4 - 攻击向量：我们害怕什么？

在确定了资产、参与者和假设之后，最后一步是明确列出你正在考虑的具体威胁。这可以包括经典的类型：

• 舍入和精度错误
• 抢跑和 MEV 暴露
• 密钥泄露或网络钓鱼
• 预言机操纵
• 关键函数的拒绝服务
• 访问控制失效

但这个列表并非详尽无遗。向开发者提出开放式问题：“当你开发功能/合约 X 时，考虑过哪些攻击向量？”创造性地思考以发现遗漏，并将它们添加到列表中，边记录边缓解。

尽量做到全面，但最重要的是诚实。列出任何会损害你资产（A1 列表）的攻击。让这指导你测试什么，要求审计师重点关注什么，以及你的应急响应预案涵盖什么。

针对行动的 STRIDE 框架

上面的 4A 框架为你提供了系统级视图。STRIDE 威胁建模方法则帮助你详细检查系统行动，并对每个行动进行批判性思考。目标是了解“可能出什么问题？”

STRIDE 是一种经过验证的方法，你需要检查合约可以执行的每个重要行动（例如，存款、提款、管理操作、治理投票……），最好基于全面的数据流图。对于每个行动，考虑从端到端的完整数据流，并提出这六个问题：

• S - 欺骗：该行动是否可以被冒充其他参与者的人发起？
• T - 篡改：该行动的输入或输出是否可以被恶意修改？
• R - 抵赖：是否有人可以否认执行了该行动？是否有足够的链上证据？
• I - 信息泄露：该行动是否会泄露敏感数据，或者是否会共享超出严格必要的信息？
• D - 拒绝服务：该行动是否可能被阻止或变得成本过高，或者该行动是否可能阻止其他行动？
• E - 权限提升：该行动是否允许某人获得他们不应拥有的权限？

Stellar 的威胁建模

Stellar 开发者基金会（SDF）提供了 STRIDE 框架的文档，包括指南、模板和示例。这些资源对任何项目都很有用，但对于希望获得 SDF 审计支持的项目尤其重要。他们的 Soroban 安全审计银行计划为符合条件的项目提供审计资金，并将其与 Certora 等顶级审计公司对接，而 STRIDE 分析是 SDF 审计银行准入条件 的要求之一。

付诸实践

4A 和 STRIDE 两者并无优劣之分。它们处于不同的抽象层次。4A 解决你的整体安全态势，而 STRIDE 让你有条理地分析具体交互。两者结合，有助于你同时从宏观画面和细微细节思考，以识别更多安全风险。

事实上，同时拥有 4A 和 STRIDE 威胁模型，是向每个投资者、生态系统合作伙伴和用户发出的强烈信号，表明你认真对待安全。一些合作伙伴（例如 AMM）将要求将威胁建模作为其尽职调查过程的一部分，因此将这些工具纳入你的项目生命周期可以加速投资和采用。

对于上述任一威胁建模框架，推荐的工作流程都很直接：

1. 创建文档。 创建一个活的威胁模型文档，映射你的 4A 分析、STRIDE 分析，或者最好是两者。将其放在显眼的位置，不要深埋在 wiki 导航的三层之下，并与你项目中的每个人分享。
2. 合作填写。 开发者、架构师和安全负责人应共同贡献和讨论。在提问和达成一致过程中暴露出的空白通常极具价值。
3. 持续更新。 威胁模型必须随着你的协议发展而演变，包括新的集成、新的参与者、假设的变化等。至少在添加新功能时重新阅读文档，并考虑其影响。
4. 在审计中使用。 尽早将（更新的）文档分享给外部审计师。一个好的威胁模型能让审计师快速完成熟悉阶段，更快进入有趣的部分。这是你从审计合作中获得更多价值的最佳杠杆之一。

从简单开始，Certora 可以帮忙

威胁建模中最大的错误就是因为它看起来太艰巨而根本不去做。你不需要一份 10 页的文档，也不需要方法论顾问。从简单开始，尽早开始，诚实地列出你在保护什么、谁有权访问、你在假设什么以及你害怕什么。由此起步，在构建过程中不断更新。与你的审计师分享。

我们很乐意帮助你改善安全，无论是通过 Certora Sunbeam 对 Soroban 智能合约进行形式化验证、全服务安全分析，还是免费的安全咨询。如果你有问题，报名参加我们的免费 Office Hours，与 Certora 安全研究员交流。

那些进行了深思熟虑的威胁建模的协议，将比那些没有付出努力的协议拥有更好的审计、更少的灾难性意外以及更快的应急响应。

• 原文链接： certora.com/blog/threat-...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～