SEAL Certifications 是 Security Alliance (SEAL) 发布的开源运营安全认证项目。其当前 v0.0.1 基线将 99 项具体运营要求（称为控制项）组织为六个模块，涵盖加密协议相关的人员、账户、签名人、域名、基础设施、财库流程和响应能力 [1, 2]。
BlockSec 是该项目首批获得认可的评估机构之一，目前也是唯一一家总部位于亚洲的获认可评估机构。作为 SEAL 认可的评估机构，我们与客户确定范围，评估选定的控制项及证据，记录差距，并判断范围内的要求是否得到满足。满足要求后，我们依据 SEAL 授权签发链上证明 [4]。
本文说明组织为何可能寻求 SEAL 认证、认证结果意味着什么、哪些模块可能适用、我们如何开展评估，以及团队如何为项目做好准备。
1. 为什么寻求 SEAL 认证
SEAL 制定该框架的理由是，加密领域漏洞利用的主要来源已从智能合约漏洞转向运营失误 [1]。因此，评估的关注点也转向签名人、多签、域名、凭证、基础设施监控和事件响应相关的控制措施。SEAL 认证评估会检验这些控制措施是否在实践中运行且有证据支持，让加密领域的组织独立了解哪些控制项达到基线要求、哪些方面仍存在差距 [1, 3]。
SEAL 认证回答一个保障问题：约定范围内的运营控制措施是否已经过独立评估，并被认定符合公开的、专为加密领域设计的运营安全基线？ 协议项目、交易所、支付平台和托管机构等加密领域的组织，在投资者、上币团队、合规相关方、内部治理机构、保险机构或尽职调查人员要求其提供运营控制措施的独立证据时，可能需要这种保障。认证结果会列明所评估的模块和边界，并记录该范围是否达到基线要求 [5, 6]。
将这种保障与相邻的安全活动比较，可以更清楚地理解其范围。评估可能检查与代码相关的运营证据，以验证代码仓库、CI/CD 和基础设施控制项，包括权限、分支保护设置、代码审查记录、安全扫描结果、流水线控制措施和基础设施配置 [7]。评估不会通过审查源代码来查找实现漏洞，也不会判断协议逻辑是否正确 [1]。其他安全活动分别针对这些及相关目标：代码审计评估源代码中的实现漏洞和协议逻辑缺陷；渗透测试评估是否能够在约定环境中复现可利用的攻击路径；漏洞赏金计划为外部发现提供持续提交渠道；持续监控则支持持续的检测与响应。
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]。可能适用的情况 列是根据模块定义编写的参考说明，并非 SEAL 的官方范围界定规则；我们会在项目开展期间与客户确认最终范围。
| 模块 | 涵盖内容 | 可能适用的情况 |
|---|---|---|
| 多签运营（24 项控制项） | 签名人设置、交易执行、协调、连续性及应急程序 | 多签钱包、签名人团队或协同交易审批 |
| 财库运营（23 项控制项） | 托管架构、资产管理、交易治理、对账、监控、供应商管理、保险及财库应急响应 | 财库资产、资产配置、托管关系或资金流转 |
| 事件响应（13 项控制项） | 准备工作、升级上报、沟通、应急预案、演练和协同响应 | 需要检测、遏制、通报安全事件并从中恢复的团队 |
| DevOps 与基础设施（15 项控制项） | 代码仓库治理、代码审查和扫描控制措施、CI/CD、供应链管理、基础设施访问、监控及韧性 | 代码仓库、部署流水线、云基础设施或生产环境管理 |
| DNS 与注册商（16 项控制项） | 域名所有权、注册商访问、DNS 配置、监控、恢复及域名接管事件响应 | 关键域名、注册商账户、DNS 记录或电子邮件身份验证 |
| 身份与账户（8 项控制项） | 账户清单、归属、抗钓鱼身份验证、凭证管理、恢复、访问权限审查、生命周期管理、监控及第三方访问 | 代码仓库、云平台、注册商、托管系统或内部工具中的人员账户、服务账户或特权账户 |
即使单独评估，各模块在运营层面仍相互关联。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]。
这四项内容为初步确定范围提供支持；具体的材料要求取决于选定的模块。上述模块名称定义的是主题领域，而非必须遵循的认证顺序。后续发布的专题文章将提供模块级控制项指引。请联系我们 [需实证:CONTACT_OR_RELEVANT_PAGE_URL]，讨论模块选择、证据准备情况和项目范围。
参考资料
-
Security Alliance，SEAL 认证框架：概览。框架制定理由、模块、独立确定范围、评估流程、自评、证明与徽章、保密、重新评估及撤销。https://frameworks.securityalliance.org/certs/overview/
-
Security Alliance，导出所有认证（XLSX）。当前各模块的控制项数量及跨模块引用，已与 SEAL 认证框架概览提供的官方导出文件核对；访问于 2026 年 9 月。https://frameworks.securityalliance.org/certs/overview/
-
Security Alliance，认证指南。逐项控制项状态、认证标准及证据类别。https://frameworks.securityalliance.org/certs/certification-guidelines/
-
Security Alliance，评估机构认可；以及 SEAL Certifications。认可流程、评估机构职责、项目状态及当前公开的合作伙伴信息。https://frameworks.securityalliance.org/certs/certified-partners/ and https://securityalliance.org/our-work/certifications
-
Security Alliance Radar，征求意见：SEAL Certifications。合约安全成熟度、SOC 2 和 ISO 27001 的定位、模块化及可验证性的制定理由。https://radar.securityalliance.org/request-for-comments-seal-certifications/
-
Security Alliance Radar，SEAL Certifications：现已开放（Isaac Patka，2026 年 6 月 2 日）。六大领域概览及针对约定范围作出的单一通过/不通过决定。https://radar.securityalliance.org/seal-certifications-auditor-accreditations-protocol-assessments/
-
Security Alliance，SFC：DevOps 与基础设施。关于代码仓库权限、分支保护、代码审查和扫描控制措施、CI/CD、供应链管理及基础设施配置的公开基线。https://frameworks.securityalliance.org/certs/sfc-devops-infrastructure/
