评估区块链安全成熟度 - Trail of Bits博客

Josselin Feist, 区块链工程总监
2023年7月14日
审计, 区块链

全面的安全审查应该揭示的远不止简单漏洞。通常，这些漏洞暗示着更深层次的问题，这些问题可能难以理解和解决。鉴于审查的时间限制特性，安全工程师可能没有机会识别由这些问题引起的所有漏洞——即使初始漏洞被修复，它们也可能在未来继续引发问题。

这就是为什么在开发安全产品时更需要全局性思考安全的重要性。这种视角需要综合考虑软件开发生命周期以及软件的架构和设计。我们开发了一套代码库成熟度标准，用于评估代码库是否符合行业标准和最佳实践。我们的建议已经促进了客户代码库的实质性改进。例如，Balancer根据我们关于算术舍入的建议（附录H）开发了更好的算术原语，而其他客户包括Optimism、Uniswap和Primitive则通过实施Echidna属性加强了他们的代码库。

我们分享这些指南是为了帮助每个人评估和增强自己智能合约代码库的成熟度。

我们如何评估成熟度

基于我们十多年来执行数百次安全审计的经验，我们确定了几个重要的控制类别。这些是我们通常发现安全缺陷的领域，也是经常需要改进以增强产品安全状况的地方。在这些领域实现更高成熟度会在产品生命周期中减少漏洞（也让安全工程师更开心）。

我们将每个类别评级为弱、中等、满意或强：

• 算术运算
• 审计
• 认证/访问控制
• 复杂性管理
• 去中心化
• 文档
• 低级操作
• 交易排序风险
• 测试与验证

（请注意，我们对所有客户都采用这种基于控制类别的方法，无论是区块链还是其他领域，并根据审查目标调整控制措施。我们的密码学和应用程序安全团队有自己推荐的控制措施。）

大多数团队需要付出大量努力才能达到满意的成熟度。例如，如果代码库不包含针对算术运算的自动化测试方法，最多只能被评为中等。这可能看起来很严格，但现实是，如果你在2023年还没有将模糊测试纳入开发过程，那么你已经落后了。同样，如果你的系统报告事件，但缺乏监控策略或对报告故障的响应策略，你应该重新考虑事件响应策略。

图1：中等成熟度的算术标准

虽然我们基于丰富经验制定了这些最佳实践，但我们欢迎反馈。随着我们与更多客户合作以及提供安全区块链解决方案所需的控制措施随时间变化，我们会定期更新此列表。

使用代码成熟度评估

根据这些具体指南评估项目有助于就区块链项目的软件安全风险进行深入且知情的对话。在新威胁每日出现、信息安全推特难以在一个话题上停留超过一小时的环境中，这有助于团队专注于基本需求。它还有助于展示安全方面的积极进展，而不仅仅是漏洞检测（负面指标）。

我们的指南可用作软件开发中各种角色的自我评估协议：

开发人员应遵循指南。在整个开发过程中纳入这些指南将有助于识别潜在的盲点。一个力求在第一天就在所有类别达到满意或更高评级的项目将为成功奠定基础，并降低安全问题的可能性。

安全工程师应根据指南衡量目标。他们应使用从代码审查收集的信息来丰富评估，并为开发人员提供改进成熟度的指导。但是，他们应记住这些标准旨在指导自我反思，而不是解决所有风险的全面清单。安全工程师的一个关键职责是将成熟度评估置于具体情境中。

公司领导者应分配资源解决缺陷。他们应审查成熟度评估以了解项目安全状况。这将帮助他们确定优先级，决定如何改善组织的安全状况，并将资源分配到薄弱环节。

迈向行业最佳实践

我们鼓励安全行业专业人士采用这些指南作为最佳实践。随着最佳实践的发展和新风险的出现，我们将定期更新它们。如果你想增强整体安全状况——而不仅仅是寻找漏洞——请通过我们的网站或电子邮件联系我们。

如果你喜欢这篇文章，请分享： Twitter | LinkedIn | GitHub | Mastodon | Hacker News

页面内容
我们如何评估成熟度 | 使用代码成熟度评估 | 迈向行业最佳实践

近期文章
我们构建了MCP一直需要的安全层 | 利用废弃硬件中的零日漏洞 | EthCC[8]内幕：成为智能合约审计师 | 使用Vendetect大规模检测代码复制 | 构建安全消息传递很难：对Bitchat安全辩论的细致看法

© 2025 Trail of Bits.
使用Hugo和Mainroad主题生成。