SEAL Certifications 是由 Security Alliance (SEAL) 发布的开源运营安全认证项目。其现行基线将 99 项具体运营要求（称为控制项）归入六个模块，涵盖加密协议相关的人员、账户、签名人、域名、基础设施、资金管理流程和响应能力 [1, 2]。
BlockSec 是该项目首批获得认可的评估机构之一，目前也是唯一一家总部位于亚洲的获认可评估机构。作为 SEAL 认可的评估机构，我们与客户确定范围，评估选定的控制项和证据，记录差距，并判断范围内的要求是否得到满足。满足要求后，我们以 SEAL 认可资质签发链上证明 [4]。
本文介绍组织为何可能寻求 SEAL 认证、认证结果意味着什么、哪些模块可能适用、我们如何开展评估，以及团队如何为评估项目做准备。
1. 为何寻求 SEAL 认证
SEAL 建立这一框架的理由是，加密领域的主要攻击利用源头已从智能合约漏洞转向运营失误 [1]。因此，评估的关注点转向签名人、多签、域名、凭证、基础设施监控和事件响应相关的控制项。SEAL 认证评估会检查这些控制项是否在实践中有效运行，以及是否有证据支持，从而让加密领域的组织独立了解哪些控制项达到基线、哪些方面仍存在差距 [1, 3]。
SEAL 认证回答一个保障问题：约定范围内的运营控制项是否经过独立评估，并被认定达到公开的、针对加密领域的运营安全基线？ 当投资者、上币团队、合规相关方、内部治理机构、保险机构或尽职调查人员要求提供运营控制项的独立证据时，协议、交易所、支付平台和托管机构等加密领域的组织可能需要这种保障。认证结果会列明接受评估的模块和边界，并记录该范围是否达到基线 [5, 6]。
将这一保障与相近的安全活动比较，可以更清楚地看到其范围。评估可能检查与代码相关的运营证据，以验证代码仓库、CI/CD 和基础设施控制项，包括权限、分支保护设置、代码审查记录、安全扫描结果、流水线控制措施和基础设施配置 [7]。评估不会通过审查源代码来查找实现漏洞，也不会判断协议逻辑是否正确 [1]。下表比较了 SEAL 认证、代码审计和渗透测试。
| 比较项目 | SEAL 认证 | 代码审计 | 渗透测试 |
|---|---|---|---|
| 主要评估对象 | 约定模块和边界内的运营控制项及支持证据 | 约定审计范围内的源代码和协议逻辑 | 约定环境和测试规则内的系统及攻击面 |
| 核心问题 | 范围内的运营控制项是否有充分证据支持，并达到 SEAL 的要求？ | 范围内的代码是否存在实现漏洞或协议逻辑缺陷？ | 能否在约定环境中复现可利用的攻击路径？ |
| 评估方法 | 通过文档、运营记录、配置、访谈，以及适用情况下的测试证据，审查控制项的实施情况 | 审查范围内的源代码及支持性规范，查找实现和逻辑缺陷 | 测试约定的攻击面，并验证发现的弱点能否在测试规则内被利用 |
| 结果 | 范围内的要求得到满足时，授予认证并签发相应的链上证明；未满足要求时，记录差距发现 | 针对审计范围提出安全发现和整改建议 | 针对测试范围提出安全发现和整改建议 |
这些服务的评估目标不同。测试可以为某些 SEAL 控制项提供证据，但审计或渗透测试本身并不能确立 SEAL 认证。
SEAL 认证是一项独立的评估项目。只有选定的范围满足 SEAL 的要求，才会授予认证 [6]。代码审计和渗透测试是单独的活动；两者都不是获得认证的前提条件。
同样的区别也适用于更广泛的保障标准。根据 SEAL 的征求意见文章，SOC 2 和 ISO 27001 仍有价值，而且最终对许多组织而言将是必要的，但它们并非针对由小型分布式团队控制大量链上资产等加密领域特有的运营模式而设计 [5]。SEAL 框架为加密领域的运营控制项提供了一个更聚焦的起点，并可与这些更广泛的标准并行使用。
2. 认证能证明什么
SEAL 认证结果适用于评估项目所选定的运营控制项、模块和边界。当选定的控制项满足 SEAL 的要求时，BlockSec 等 SEAL 认可的评估机构会以其认可资质，通过 Ethereum Attestation Service 签发链上证明，并颁发适用的 SEAL 徽章 [4]。证明是公开的；详细评估报告和证据仍由评估机构与客户保密 [1]。下表区分了通过认证的结果所能支持的结论，以及仍在其范围之外的主张。
| 通过 SEAL 认证的结果表明…… | 但并不表明…… |
|---|---|
| 受评估组织就约定范围内的模块和边界满足了 SEAL 的要求 | 未列出的模块或运营系统也接受了评估 |
| 范围内的运营控制项及支持证据经过了独立第三方审查 | 已审查源代码中的实现缺陷、已测试攻击路径，或协议不存在漏洞 |
| 约定范围内逐项控制项符合要求 | 获得了安全评分、成熟度等级、代码质量意见或监管批准 |
| 获得了基于特定时间点、有效期有限且需要重新评估的认证 | 持续符合要求，或保证不会发生安全事件 |
这些限制在证明签发后依然适用。SEAL 证明并不表示协议不存在安全问题 [1]。它有时效限制，需要定期重新评估，并可能在持续不符合要求后被撤销；SEAL 未公布固定的有效期 [1]。
3. 框架涵盖什么
六个模块可以单独评估，也可以一起评估。现行基线包含 99 项控制项 [1, 2]。When it may apply 列是根据模块定义编写的参考指引，并非 SEAL 官方的范围界定规则；我们会在评估项目中与客户确认最终范围。
| 模块 | 涵盖内容 | 可能适用的情况 |
|---|---|---|
| 多签运营（24 项控制项） | 签名人设置、交易执行、协调、连续性和紧急程序 | 多签钱包、签名人群组或协同交易审批 |
| 资金管理运营（23 项控制项） | 托管架构、资产管理、交易治理、对账、监控、供应商管理、保险和资金管理应急响应 | 资金管理资产、资产配置、托管关系或资金流转 |
| 事件响应（13 项控制项） | 准备、升级上报、沟通、应急预案、演练和协同响应 | 需要检测、遏制、通报安全事件并从中恢复的团队 |
| DevOps 与基础设施（15 项控制项） | 代码仓库治理、代码审查和扫描控制、CI/CD、供应链管理、基础设施访问、监控和韧性 | 代码仓库、部署流水线、云基础设施或生产环境管理 |
| DNS 与域名注册商（16 项控制项） | 域名所有权、域名注册商访问、DNS 配置、监控、恢复和接管事件响应 | 关键域名、域名注册商账户、DNS 记录或电子邮件身份验证 |
| 身份与账户（8 项控制项） | 账户清单、所有权、抗钓鱼身份验证、凭证管理、恢复、访问权限审查、生命周期管理、监控和第三方访问 | 代码仓库、云平台、域名注册商、托管系统或内部工具中的人员账户、服务账户或特权账户 |
如需进一步了解 DNS 与域名注册商模块，请参阅智能合约之外：Web3 中的域名与 DNS 运营安全。
即使单独评估，各模块在运营层面仍相互关联。DevOps 与基础设施以及 DNS 与域名注册商模块中的一些控制项依赖于身份与账户模块所定义的账户安全实践。事件响应要求也出现在多个模块中，例如在事件期间协调多签签名人或恢复账户 [2]。
这些跨模块引用会影响范围内控制项所需的证据；它们不会自动使被引用的模块获得认证，也不会形成必须遵循的认证顺序或扩大评估项目范围。DNS 与域名注册商证明不会仅仅因为某项 DNS 控制项依赖账户安全实践，就变成身份与账户证明。证明仅适用于其范围中列明的模块和边界 [1, 6]。
4. 评估如何开展
SEAL 维护框架并运营认证项目。作为 SEAL 认可的评估机构，我们通过五个步骤开展每项客户评估 [1, 4]：
图 1。SEAL 认证评估项目从约定范围开始，经过证据审查、整改和重新评估，最后签发证明。
-
界定范围。 我们与客户共同商定哪些模块、控制项、系统、运营活动和组织边界纳入范围。
-
收集证据。 客户提供材料，说明范围内的控制项如何设计、分配责任、运行和接受审查。
-
评估。 我们根据 SEAL 公布的要求评估证据，并指出缺失或不充分的支持材料。
-
整改与重新评估。 如果约定范围未达到基线，我们会提供差距报告。客户针对发现的差距进行整改，并提交更新后的证据以供重新评估。
-
认证。 当约定范围达到基线时，我们以 SEAL 认可资质签发正式链上证明。
证据收集与评估相互配合：客户提供支持材料，BlockSec 则评估这些材料能否证明每项控制项在实践中有效运行。SEAL 的《认证指南》将支持证据分为五类，下表结合指南和模块基线中的例子加以概述 [2, 3, 7]：
| 证据类别 | 有助于证明什么 |
|---|---|
| 程序文档 | 预期的控制措施，包括政策、版本和批准日期 |
| 运营证明 | 通过日志、记录、工单或团队成员访谈，证明流程在实践中得到使用 |
| 测试/验证 | 保障措施或响应流程已经过演练或检查 |
| 责任归属详情 | 谁负责维护控制项、审查频率以及最近一次更新的时间 |
| 技术材料 | 配置、截图或系统导出内容，包括代码仓库和 CI/CD 设置、云配置、域名注册商或 DNS 导出内容，以及范围内的其他技术证据 |
依据这些证据，BlockSec 将范围内的每项控制项记录为“已实施”“部分实施”“未实施”或附有理由的“不适用”。正式认证要求约定范围内的控制项均为“已实施”或有理由支持的“不适用”，且相关主张有证据支持。因此，尽管基础评估是逐项控制项进行的，整体认证决定对完整的约定范围而言仍是二元的 [3, 6]。
5. 如何准备
在启动 SEAL 认证评估项目之前，请准备以下四项：
-
拟议范围： 与拟获得的认证结论相关的模块、系统、实体、团队和边界。
-
逐项控制项自评： 判断各项要求属于“已实施”“部分实施”“未实施”还是“不适用”，并说明每项判断的依据。
-
证据清单： 将现有程序、运营记录、测试结果、责任归属记录和技术材料对应到拟议范围。
-
明确参与人员： 指定负责范围决策、证据收集和整改协调的人员。
由于框架和检查清单均已公开，团队可以在正式启动评估项目之前开始这项工作。自评有助于发现未形成文档的流程、缺失的运营证据、尚未分配责任的控制项，以及已知的整改工作。但自评仍只是内部检查节点：它未经独立验证，也不会产生 SEAL 证明 [1, 3]。
这四项内容有助于初步界定范围；详细的材料要求取决于所选模块。上述模块名称界定的是主题领域，而非必须遵循的认证顺序。专门文章发布后，将提供模块层面的控制项指引。如需讨论模块选择、证据准备情况和评估项目范围，请通过 [email protected] 联系我们。
参考资料
- Security Alliance，SEAL 认证框架：概览。
- Security Alliance，导出全部认证（XLSX），可从框架概览页面获取。控制项数量和跨模块引用也已对照 2026 年 10 月公布的六个模块页面核查。
- Security Alliance，认证指南。
- Security Alliance，审计机构认可；SEAL 认证。
- Security Alliance Radar，征求意见：SEAL 认证。
- Isaac Patka，Security Alliance Radar，SEAL 认证：现已开放申请（2026年6月2日）。
- Security Alliance，SFC：DevOps 与基础设施。
