1. 进行多次独立审计并正确构建它们
2. 部署具有有意义奖励的漏洞赏金计划
3. 实时监控和警报
4. 管理密钥安全和多重签名。无一例外。
5. 在发布前编写事件响应计划
6. 为你的用户和团队提供反钓鱼保护
7. 第三方服务和依赖项审查
8. 旧代码和分叉代码审计
TL;DR
2026 年 3 月 13 日
|
10
分钟阅读
|
一次审计是安全策略的开始，而不是结束。
最低标准是两家独立公司审查系统。两者都应检查业务逻辑以及低级漏洞。
时间安排应错开。第二家公司的部分职责是发现第一家公司遗漏的内容：边缘情况、有缺陷的假设或意想不到的交互。
一次适当的审计包括：
- 手动审查每一行代码
- 自定义测试用例
- 清晰的严重性分类
- 部署前对修复进行全面审查
包含自动化扫描器输出的 PDF 文件不是审计。
还值得注意的是，2026 年初的许多故障根本不是智能合约漏洞。财政钱包被盗用。Bridge 消息验证失败。系统级问题造成了损失。
你的审计范围应该反映整个系统，而不仅仅是合约。
如果你的 TVL 是 5000 万美元，而你的最高赏金是 5000 美元，那么白帽研究员就没什么理由负责任地报告漏洞了。
激励机制不匹配。
一个合理的规则是，最高严重漏洞赏金应大致等于最大可利用价值的 5% 到 10%。
Immunefi 仍然是 DeFi 漏洞赏金的标准平台。无论平台如何，该计划都应包括：
- 清晰的范围定义
- 快速响应时间
- 对已确认报告的快速支付
延迟响应或支付的计划会迅速形成负面声誉，并阻碍研究人员报告漏洞。
资金充足的赏金计划已经预防了重大事件。有些项目为单个漏洞支付了数百万美元。这些项目至今仍然存在。
一旦用户存入资金，监控就变得至关重要。
至少这包括链上监控，并对以下情况发出警报：
你还需要一个 24/7 的响应轮值。警报只有在有人能立即采取行动时才有用。
暂停或冻结功能必须在发布前已经存在。在事件发生期间构建它就太晚了。
Hypernative、Forta 和 Guardrail 等监控工具现在提供可靠的威胁检测。
在许多重大事件中，被盗资金在泄露公开之前就开始转移了。监控正是弥补这一差距的关键。
很大一部分损失来自被盗用的密钥，而不是合约漏洞。
基本规则很简单，但必须始终如一地遵守。
所有管理员功能都应要求多重签名批准。任何单一密钥都不应能够耗尽协议资金。
所有签名者都应使用硬件钱包。
助记词绝不应以明文形式存在于任何地方。不在云存储中，不在笔记应用程序中，也不在电子邮件草稿中。它们必须被加密、离线并进行物理安全保护。
关键操作也应通过 timelock 进行。对敏感操作施加 24 到 48 小时的延迟，让团队和社区有时间在执行前检测恶意更改。
密钥泄露仍然是 DeFi 中最常重复的失败模式之一。
如果你在事件发生期间才开始编写响应计划，那么宝贵的时间就已经流失了。
一个功能完善的响应计划包括：
- 已部署并测试过的紧急暂停功能
- 针对不同事件级别的预先编写的沟通模板
- 清晰的作战室结构和分配的角色
- 与交易所和调查人员建立联系，用于资金追踪和冻结
如果你在以太坊上构建，SEAL 911 存在。在你需要他们之前，知道如何联系他们。
沟通也至关重要。
在安全事件中保持沉默会迅速损害信任。一份准备好的声明，例如“我们正在调查一个潜在的安全问题，并将在 X 小时内更新”，可以在调查开始时立即发布。
提前起草这条消息只需几分钟，但在危机期间可以节省数小时。
相当一部分加密货币损失来自社会工程，而不是合约漏洞利用。
攻击者同时针对用户和内部团队成员。
对于你的社区：
- 清晰列出所有平台的官方渠道
- 反复强调团队绝不会主动私信
- 尽可能使用签名公告
- 定期发布关于常见骗局的提醒
对于你的团队：
- 拥有签名权限的任何人都使用硬件钱包
- 执行敏感操作前的验证程序
- 意识到攻击者经常制造紧迫感以迫使犯错
当紧急情况意外出现时，应始终触发额外的验证。
你的攻击面超出了你编写的代码范围。
它包括你集成的每一个服务或协议。
发布前，审查：
- Oracles
- Bridges
- 第三方合约
- 链下基础设施
- CI/CD pipelines
许多事件源于对外部系统的不正确假设，而非合约本身的缺陷。
Oracle 操纵、bridge 验证错误和基础设施故障都属于这一类别。
每个依赖项都应像审查自己的代码一样仔细审查。
分叉现有协议是常见做法。
假设继承的代码是安全的往往会导致问题。
发布前：
- 审计所有继承的代码，而不仅仅是新的更改
- 确认你正在使用的确切版本已通过审计
- 审查较旧的 Solidity 模式和已弃用的方法
- 检查依赖项是否存在已知漏洞
即使是你自己的旧合约，也应视为未经审查，直到它们被重新评估。
两年内未发生事故的代码是针对当时存在的威胁进行测试的，而不是针对今天存在的威胁。
每年有数亿美元因可避免的故障而损失。
具体的漏洞利用方式在变化，但根本原因没有改变。
更安全的发布流程包括：
- 多次范围正确的独立审计
- 反映真实财务风险的漏洞赏金
- 实时监控和响应轮值
- 严格的密钥管理和多重签名控制
- 书面的事件响应计划
- 为用户和员工提供反钓鱼保护
- 全面审查依赖项和旧代码
- 开发基础设施的强大操作安全性
这些措施都不能保证绝对安全。区块链系统在对抗性环境中运行，攻击者不断适应。
但在 2026 年发布时没有这些保障措施，其后果是可预见的。
安全发布。
在你发布之前
你刚刚阅读了在过去 90 天内给协议造成实际资金损失的八种故障模式。每个代码库都有漏洞。问题在于你是否能在别人发现它们之前发现它们。
那些事件背后的团队也不认为自己会成为受害者。
在你的发布前，与我们预约 15 分钟。我们将了解你的情况，提出正确的问题，并为你指明正确的方向——无论是我们还是其他人：
预约你的免费 15 分钟咨询
