纵深防御智能合约工作流：超越静态检查表

TL;DR — 为什么仅凭清单无法拯救你的协议

在 Web3 中，“快速行动，打破常规”不是一种开发方法论；它是一种财务上的死刑。一行错误的L代码就可能导致九位数的资金不可逆转地损失。

大多数开发者试图通过清单来缓解这种风险。然而，“清单疲劳”是真实存在的。一个包含 100 多个条目的静态 PDF 清单往往会变成一个官僚障碍，而不是一个工程工具。开发者在不理解攻击向量的情况下打勾，导致虚假的安全感。

本文概述了一种方法论，将基于 SCSVS (智能合约安全验证标准) 等标准的静态安全清单，转化为一个动态的、纵深防御的工程工作流。

1. 验证的层级结构

一个庞大的清单是低效的。它迫使开发者在尝试架构经济博弈论时，还要检查 gas 优化。为了有效地进行安全工程，我们必须将验证分层为三个抽象级别，使它们与 SDLC (软件开发生命周期) 对齐。

级别 1：架构和设计（蓝图）

此层解决基本的经济逻辑和信任假设。它必须在编写 Solidity 代码之前应用。

• 信任假设：谁持有管理员密钥？协议是否能抵御中心化向量？
• 经济激励：是否存在激励恶意行为的机制（例如，廉价的悲伤攻击）？
• 可组合性：协议如何处理预言机故障或依赖协议暂停？

注意：来自 Zealynx 等审计公司的数据表明，GameFi 和 DeFi 漏洞利用的很大一部分源于逻辑错误和代币经济学缺陷——这些问题存在于设计阶段，代码扫描器无法发现。

级别 2：实现（代码）

这是一个粒度层，侧重于 Solidity 模式。此层是自动化工具的主要领域。

• 重入：遵循 Checks-Effects-Interactions 模式。
• 算术：处理 精度损失 和溢出保护。
• 访问控制：正确实现 onlyOwner 或基于角色的修饰符。

级别 3：操作（实时环境）

用不安全的参数部署的安全合约是一个漏洞。

• 密钥管理：多重签名 多数阈值配置。

• 时间锁：根据治理提案验证延迟参数。

• • *

2. 左移：威胁建模和不变量

最有效的安全实践是“ Shift-left(左移)”——将安全约束集成到设计阶段。

智能合约的 STRIDE

我们将 Microsoft STRIDE 模型改编为区块链特定的向量：

• 欺骗：验证 msg.sender 与 tx.origin。
• 篡改：链上预言机数据是否可以通过 闪电贷 进行操纵？
• 否认：关键状态更改是否会发出事件？
• 信息泄露：私有数据（例如，提交-揭示盐值）是否暴露？
• 拒绝服务：是否存在无界循环或 gas 悲伤向量？

定义系统不变量

不变量 是关于系统的一个基本事实，无论市场条件如何，它都必须始终成立。这些应该在清单中定义，然后转化为代码。

不变量示例：

1. 偿付能力：总资产 >= 总负债
2. 守恒：供应量_t1 == 供应量_t0 + 铸造量 - 销毁量

3. 自动化合规：静态层

人工审查不应浪费在语法上。我们使用自动化 静态分析 来实现我们层级结构中的级别 2。

Slither 配置

Slither 是静态分析的行业主力工具。然而，使用默认设置运行时，它通常会产生太多噪音。为了将其有效地集成到 CI/CD 管道中，你必须对其进行调优，以专注于高价值的检测器。

创建一个 slither.config.json 来过滤噪音并专注于关键检测器（如重入或未初始化状态变量）：

1{
2    "detectors_to_exclude": [\
3        "naming-convention",\
4        "pragma",\
5        "solc-version"\
6    ],
7    "filter_paths": [\
8        "node_modules",\
9        "test"\
10    ]
11}

通过将其添加到你的仓库中，你可以确保每个 Pull Request 都会自动根据你的安全框架的“语法检查”层进行检查。

自定义检测器

对于项目特定的逻辑，标准工具会失效。如果你的协议要求“借贷池中的每项资产都必须具有非零的抵押系数”，你可以编写一个自定义的 Slither Python 脚本来强制执行此要求。这将一个手动清单项转变为一个自动化防护措施。

4. 动态验证：基于属性的测试

静态分析 捕获模式；动态分析（fuzzing）捕获边缘情况。在这里，我们以数学方式验证在第一阶段定义的不变量。

Foundry 和不变量测试

Foundry (Forge) 允许开发者用 Solidity 编写有状态的模糊测试。与单元测试只检查一个输入不同，模糊测试器会生成数千个随机交易序列，试图破坏你的不变量。

清单项：“用户余额绝不能超过总供应量。”

代码实现 (Foundry)：

1// defined in your test file
2function invariant_totalSupply() public view {
3    // The fuzzer will call random functions (mint, burn, transfer)
4    // and check this assertion after every step.
5    assert(token.totalSupply() >= token.balanceOf(msg.sender));
6}

如果模糊测试器发现一个导致 totalSupply 小于用户余额的调用序列，则测试失败。这自动化了复杂经济逻辑的验证，而这种逻辑是无法通过简单 单元测试 验证的。

5. 人为因素：“瑞士奶酪”模型

自动化无法理解业务意图。手动审计工作流使用清单来发现工具遗漏的内容。

“瑞士奶酪”发现模型

在复杂系统中，灾难性故障很少是由单一错误引起的。它发生在多个微小弱点对齐时。

1. 漏洞 1：一项 gas 优化 删除了一个检查（低严重性）。
2. 漏洞 2：一个宽松的 访问控制 修饰符（中严重性）。
3. 结果：攻击者将它们结合起来，清空金库。

漏洞评分

当人工审查发现清单违规时，必须根据影响与可能性进行评分。

• 危急：易于利用，资金完全损失。
• 高：难以利用，资金完全损失；或易于利用，导致收益损失。
• 中：影响有限。

这种优先级排序允许团队将工程资源集中在“资金安全”问题上，而不是样式细节。

结论：安全是一个过程

清单不是安全证书；它是探索的地图。

通过分层构建需求，使用 Slither 等工具自动化语法检查，并使用 Foundry 以数学方式验证经济真理，我们将清单从一个被动文档转变为一个主动防御系统。

安全不是部署前的最终关卡。它是一个持续的 威胁建模、自动化分析和 不变量测试 循环。随着 DeFi 生态系统的发展，你的不变量也必须随之演变，将每一次过去的漏洞利用转化为未来的防御。

联系我们

正在构建 DeFi 协议并希望超越静态清单？在 Zealynx，我们设计纵深防御安全工作流，将自动化分析与专家人工审查相结合。

准备好保护你的协议了吗？获取报价 或 直接联系我们 讨论你的项目。

常见问题：纵深防御工作流

1. 智能合约的纵深防御是什么？

纵深防御是一种分层安全策略，它结合了多种独立的保护措施——架构审查、自动化静态分析、动态模糊测试和人工审计——而不是仅仅依赖单一的清单或工具来保护你的协议。

2. 为什么安全清单本身会失效？

静态清单会受到“清单疲劳”的影响。开发者在不理解底层攻击向量的情况下打勾，导致虚假的安全感。清单也无法捕获由多个合约组件交互而产生的新兴漏洞。

3. STRIDE 模型是什么，它如何应用于 Web3？

STRIDE 是一个最初由微软开发的威胁建模框架。它代表欺骗（Spoofing）、篡改（Tampering）、否认（Repudiation）、信息泄露（Information Disclosure）、拒绝服务（Denial of Service）和权限提升（Elevation of Privilege）。应用于智能合约时，它映射到诸如 tx.origin 欺骗、预言机操纵、缺失事件发出和 gas 悲伤等向量。

4. 不变量测试与单元测试有何不同？

单元测试验证开发者预期的特定输入-输出场景。不变量测试定义了必须始终成立的基本属性（例如，“总供应量等于所有余额的总和”），并使用模糊测试器生成数千个随机交易序列，捕获开发者无法手动测试的边缘情况。

5. 我应该何时开始为我的协议进行威胁建模？

威胁建模应在编写任何 Solidity 代码之前——在架构和设计阶段——就开始。在实现后审计中发现设计层面的缺陷，远不如预先定义信任假设、经济激励和系统不变量更经济高效。

词汇表

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