编译：GaryMa 吴说区块链

如果更加重视智能合约的安全性，许多 web3 项目上的攻击事件是可以避免的。

通常情况下，攻击者会发现并利用整个软件开发生命周期中的多个缺陷，从设计到部署和维护。如果正确的协议和最佳实践更加普及，我们相信安全事件的发生会少得多。

这篇文章的目的是概述 web3 构建者、开发者和安全团队在设计、开发和维护安全智能合约系统时必须考虑的核心安全基本要素。下面介绍的框架讨论了在整个软件开发生命周期内应该实施的八个核心类别的安全考量，从威胁建模到应急响应准备。

在进入智能合约的安全考量之前，了解安全软件的开发生命周期很重要，这可以用以下五个阶段来描述。

• 设计：开发人员描述系统所需的功能和操作，包括重要的基准和不变的属性。

• 开发：开发人员编写系统的代码。

• 测试和审查：开发人员将所有的模块集中在一个测试环境中，并评估它们的正确性、规模和其他因素。

• 部署：开发人员将系统投入生产。

• 维护：开发人员评估和修改系统，以确保它执行其预期的功能。
   

有了这个基本的生命周期基础，现在让我们深入了解影响每个步骤的智能合约安全考量因素。下图将这些考量因素映射到其相关的开发阶段。 注意生命周期中的一些步骤有多个安全考量因素。不过，上面仅是理论线性地阐述的软件开发生命周期，实际开发并不一定总是遵循线性路径。在实践中，类别可能会重叠或延伸到其他阶段。每次发布都可能重复一些步骤。而一些任务如测试和安全审查，可能需要在整个过程中执行。

虽然上面描述的软件生命周期步骤和相应的安全考量因素为促进智能合约安全提供了一个有用的基础，但我们在下面更详细地了解它们。我们可以通过借助三个关键问题来尽可能简单和具体地去理解、应用和分享这些最佳实践：what、why、how。
 

设计阶段的智能合约安全考量

#1：考虑威胁建模和安全设计

• What: 从开发生命周期的一开始就明确识别系统的潜在威胁并确定其优先级是很重要的。智能合约开发人员应该识别在开发中要实现的任何安全控制，以及在测试、审计和监控中应该检查的任何威胁。所有安全假设，包括攻击者预期的复杂程度和经济手段，都应该在设计阶段明确定义和阐明。

• Why: 虽然开发人员很容易只关注智能合约或协议的预期用途，但这种唯一的关注可能会给他们留下盲点，攻击者可以而且将会利用这些盲点。

• How: 遵循已知的威胁建模实践。如果一个开发团队没有内部的安全专家，那么它应该在设计阶段的早期就与安全顾问合作。在设计系统时采用 "攻击者" 的思维方式，并假设任何个人、机器或服务都可以合理地被破坏。

开发阶段的安全考量

#2：考虑管理员和访问控制权限

• What: 实现访问控制，将调用执行管理员任务的特殊函数（如升级合约和设置特殊参数）的能力限制为特权帐户和智能合约。遵循“最小特权原则”：每个参与者应该只拥有所需的最小访问量。

• Why: 通过升级和治理过程来维护协议，允许开发人员通过添加新特性、修补安全问题和解决不断变化的条件来改进协议。如果升级的能力没有得到适当的控制，这可能会构成一个严重的安全漏洞。

• How: 建立多重签名钱包或 DAO 合约，以透明的方式代表社区管理变更。更改应该经过彻底的审查过程，并设置一个时间锁，以确保在治理攻击的情况下可以验证其正确性并回滚。确保特权密钥在自托管钱包或安全托管服务中安全地存储和访问。

#3：考虑可重用的、经过实战测试的模板和集成

• What: 尽可能利用现有的智能合约标准（如 OpenZeppelin 合约），并评估你可能需要与现有协议进行的协议整合的安全假设。

• Why: 使用现有的经过实战检验、社区审计的标准和实现，对减少安全风险有很大的帮助。评估协议集成的风险有助于你制定安全检查，以防止对外部组件的攻击，如预言机的操纵。

• How: 导入经过安全审计的可信的合约库和接口；毕竟，加密行业和 web3 的全部意义在于开源使用、重复使用和可组合性。确保在代码库中记录你的合约依赖关系及其版本，并尽可能地减少你的代码足迹；例如，导入大型项目的特定子模块，而不是所有项目。了解你的风险，以便你能监测生命周期阶段的攻击。使用官方接口来调用外部协议，并确保考虑到潜在的集成风险。监测你所重复使用的合约的更新和安全披露。

测试 & 审查阶段的安全考量

#4：考虑测试和文档记录

• What: 创建清晰、全面的代码文档，并建立一个快速、彻底、易于运行的测试套件。可以的话，在测试网或通过主网模拟建立测试环境，进行更深入的实验。

• Why: 写出代码库预期行为的假设，有助于确保威胁模型中的风险得到解决，并确保用户和外部审计人员理解开发团队的意图。为代码创建测试套件有助于证明或反驳开发假设，并鼓励对威胁模型进行更深入的思考。这个测试套件应该包括对机制设计的测试，检查项目在极端市场情况下的 tokenomics，以及单元测试和集成测试。

• How：实施已知的测试框架和安全检查器，如 Hardhat、Mythril、Slither、Truffle 等。提供不同的测试技术，如模糊测试、属性检查，甚至是形式验证。广泛地记录你的代码，使用 NatSpec 注释来指定预期的副作用、参数和返回值。使用文档生成工具与高级设计解释一起制作实时文档。

#5：考虑内部审查和安全审计

• What: 专注于通过内部和外部的代码审查来寻找错误。

• Why: 从功能开发中抽身出来，专注于安全问题，使开发人员有时间发现潜在的隐晦问题。外部审计在这方面特别有帮助，因为他们可以带来开发团队所不具备的外部视角和专业知识。

• How: 在项目开发的适当时刻，安排一个功能冻结，以便有时间进行内部审查，然后再进行外部审计。这应该在任何实际部署和升级之前进行。看看 ConsenSys、Nascent、OpenZeppelin 和 Trail of Bits 的指南，它们为开发者提供了包括时间在内的注意事项清单，以供准备审计的人参考。还要确保审查部署事务，以确保它们使用被审计的代码版本并有适当的参数，特别是在升级软件时。

部署 & 维护阶段的安全考量

#6：考虑激励社区白帽的参与

• What: 创建激励活动，鼓励社区参与开源代码库的安全改进。其中一个方法是通过创建 bug 赏金。另一个方法是鼓励社区开发协议监测检测机器人。

• Why: 开发团队可以从更广泛的知识和经验库中受益匪浅。(值得注意的是，这些活动可以帮助产生对项目的热情，基本上把社区和白帽黑客变成布道者。它们还可以通过为黑客提供成为防御者的途径，帮助将潜在的攻击者变成一道安全保障。

• How: 使用漏洞赏金平台（如 Code4rena、HackenProof、Immunefi 或 Secureum），以基于严重程度的奖励资助赏金系统，激励熟练的黑客安全地披露漏洞。 开发团队可以鼓励他们的协议社区利用传统的和 web3 原生的方法来激励 bug 赏金活动，并且让参与者通过加强安全来获得潜在的利益，实现双赢。

#7：考虑实时监控

• What: 实施监测智能合约和关键操作组件的系统，如预言机和桥，并根据已知的威胁模型向开发团队和社区报告可疑的活动。

• Why: 及早发现问题，使团队能够迅速应对漏洞和错误，有可能阻止或减轻任何损害。这似乎是显而易见的，但在计划中可能会被忽视。

• How: 使用监控平台或分布式节点来运行实时监控智能合约事件的机器人。根据需要为开发团队和更广泛的社区实施仪表板和警报通知。

#8: 考虑事件和应急反应行动

• What: 利用工具和流程，在出现任何安全问题时能够立即做出反应。

• Why: 即使有最好的部署前保障措施，智能合约和关键组件仍然有可能出现实时问题。拥有专门的人员、明确的流程和适当的自动化，可以确保事件得到快速调查，并尽可能迅速地解决。

• How: 为最坏的情况做准备，计划如何应对事件或紧急情况，并在最大程度上将响应能力自动化。这包括将调查和响应的责任分配给有能力的人员，这些人员可以通过分布式安全邮件列表、代码库中的指示或智能合约登记处公开联系到安全问题。基于协议的威胁模型，制定一套流程，可以包括情景演练和采取紧急行动的预期响应时间。考虑将自动化整合到事件响应中：例如，工具可以摄取 Forta 机器人的事件并采取行动。

安全考量应该是成功开发的一个组成部分，而不仅仅是事后的想法或附加物。

虽然这个框架为那些建立 web3 协议和应用程序的人分享了一些快速指南，可以促进整个开发流程的安全，但没有一个简短的概述可以提供智能合约安全的所有方面的详尽讨论。缺乏内部安全专业知识的团队应该与合格的 web3 安全专家联系，他们可以帮助他们将上述一般指导应用于他们的具体情况。但最重要的是，请记住，安全从来都不是在简单地列规划；因此，它永远是一套永无止境的、持续的最佳实践。我们仍然处于建立这些最佳实践的开始阶段，所以现在是在所有层面上为所有开发人员协作创建和分享这些最佳实践的时候了。