对于加密货币机构和服务提供商——包括加密货币交易所、支付公司、数字资产托管方以及托管型和非托管型钱包提供商——区块链渗透测试对于在范围之内的机构而言，并非可选的预防措施。当漏洞可能波及签名或资金，或适用规则要求进行对抗性验证时，它就是保障体系中不可或缺的一环。这一论断建立在两个支点之上：超越合约代码的风险来源，以及监管要求或对对抗性验证的预期。
机构面临的风险敞口不仅限于合约漏洞，还延伸到签名、托管、密钥、人员、供应链和基础设施 [1]。因此，仅凭我们熟悉的 web3 安全解决方案——代码级审计和交易级监控——或单独的传统渗透测试，都无法完全覆盖这一风险面。这适用于任何机构，只要有人员、供应商、接口或应用程序能够影响签名、批准、入账或转移的内容——包括托管被外包的情形。与此同时，多个市场的监管机构提出了要求、附条件义务或监管预期，其范围、频率和独立性规则各不相同。
本文开启我们的区块链渗透测试系列。在本系列中，"区块链渗透测试"与"web3 渗透测试"指的是同一学科：我们以前者作为主要术语，后者作为其行业通用同义词。本文从宏观、全局的视角论证其必要性；后续文章将详细定义该学科、其运作边界以及机构层面的攻击面。
Blockchain Penetration Testing
Find the path in — across contracts, nodes, APIs, and cloud
第一部分：风险从何而来
1.1 超越智能合约的风险
智能合约漏洞依然重要，但近期许多最大规模的损失却源自其他环节，尤其是密钥、签名系统和运营基础设施。2024 年，攻击者通过入侵一家钱包软件提供商并操纵一笔合法的交易请求，从 DMM Bitcoin 窃取了约 3.05 亿美元 [2]。2025 年，Bybit 因供应链攻击导致其签名接口被操纵，损失约 15 亿美元 [3]；而 BtcTurk 的热钱包损失同样可追溯至私钥被泄露 [4]。我们的研究指向相同的方向：在我们追踪的 2026 年损失超过 10 万美元的事件中，合约外故障约占事件总数的八分之一，却造成了超过四分之三的总损失。截至 2026 年 8 月，在 rekt.news 公开排行榜上（不含欺诈及其他非黑客类条目）的十大黑客攻击中，有七起属于合约外攻击，按事件数量和美元价值计算均约占 70% [5]。
钱包和托管系统使这一模式变得具体可见，钱包安全近年来一直是事件高发的重点领域。我们的调查将故障归为以下几类：密钥管理、交易签名流程、供应链及依赖项、敏感数据泄露，以及加密实现。
| 合约外故障 | 代表性事件 | 大致损失（据报道） |
|---|---|---|
| 密钥管理 | BtcTurk [4], SwissBorg [6] | 约 5170 万美元（BtcTurk），约 4150 万美元（SwissBorg） |
| 交易签名流程 | Bybit [3] | 约 15 亿美元 |
| 供应链及依赖项 | TrustWallet [7] | 约 850 万美元 |
| 敏感数据泄露 | Slope [8] | 约 410 万美元 |
| 加密实现 | Wintermute [9], Coldcard [10] | 约 1.6 亿美元（Wintermute），约 9000 万美元（Coldcard）* |
* Coldcard 的约 9000 万美元是经验证的链上最低损失（约 1,405 枚 BTC）；私下估算最高可达约 1.3 亿美元。
将这些事件与渗透测试联系起来的原因，并不仅仅在于它们发生在合约范围之外，而在于它们能否被利用，往往取决于已部署的各个环节——身份、依赖项、签名控制、审批和资金逻辑——是否恰好排列组合成一条攻击者可以从入口一直走到资金的完整路径。
Best Security Auditor for Web3
Validate design, code, and business logic before launch
1.2 代码级审计与交易级监控：至关重要但存在局限
现有的知名 web3 安全解决方案各自在特定层面发挥作用。代码级审计（代码审计）检查代码——合约、钱包或服务逻辑。交易级监控（监控）在交易上链时对其进行检查；例如，Phalcon [11] 在运行时检测、告警并拦截恶意活动。
这些解决方案确实有用，但在应对加密货币机构的资金处理链条——即连接身份、云基础设施、签名工作流、审批链、钱包、供应商和操作员控制台，价值正是通过这些环节从入口点流向资金转移操作——时存在局限。攻击者可触达的路径是穿越这一链条的一条路线：它可能从网页、去中心化应用（dApp）、移动端、API、云端或身份入口开始，经过签名、审批和资金逻辑，并可能涉及合约在该实际运行环境中的行为方式，最终到达另一端的资金转移操作。审查代码并不能拼凑出这条路径，监控交易也无法预见它。即便两者结合使用，仍可能留下组合层面的缺口：审计只能证明代码在编写时是健全的，却无法证明已部署的身份、审批和签名方仍在切实执行该逻辑；而监控可能放行一笔技术上有效、但从未被操作员真正意图批准的转账。能够弥合这一缺口的，是对运行系统中各项控制是否正确组合运作所进行的独立对抗性验证。
区块链渗透测试对已组装、正在运行的系统进行实测，以在事件发生并暴露该路径之前，发现并证实此类路径是否存在可达性。Bybit 事件的模式揭示了这一问题的本质：一个被攻破的签名接口，将操作员自己的批准变成了他们从未打算进行的转账——这一结果无论是合约本身、对其的审计，还是交易监控，都可能将其判读为合法操作。区块链渗透测试正是直接针对这种组合层面进行测试：以被攻陷的供应商、操作员或接口的视角，测试这样一个立足点是否能将一个看似有效的审批转变为未经授权的资金转移，以及已部署的哪些控制措施——身份验证、审批步骤、签名检查——能够真正阻止这种情况。合约代码层面的保障仍属于审计的职责；区块链渗透测试仅在已部署合约的实际运行行为构成机构层面通往资金路径的一部分时，才涉及该合约——两者范围互补，区别在于侧重点不同，而非存在硬性边界。第二部分将定义区块链渗透测试所验证的内容及其范围边界。
1.3 传统渗透测试：有用，但并不足够
传统渗透测试在云、网页与 API、身份以及特权访问等层面依然具有价值。它的局限在于范围和领域背景：常规的测试项目可能并不具备加密货币的业务语义，或其耦合的安全与合规模型。
在加密货币领域，一次签名就可能授权不可逆的价值转移；提款审批是一项资金控制决策，而不仅仅是表单提交。充值入账、余额核算和内部转账都属于资金逻辑范畴。地址和交易还可能带有制裁或资金来源方面的含义。测试人员可能发现了一处身份验证绕过漏洞，却未能察觉它与签名显示不一致、审批策略薄弱或舍入误差相结合，会形成一条通往资金的路径。
区块链渗透测试将成熟的对抗性技术应用于传统安全面，并延伸至整个运行系统中特有的 web3 签名、审批、资金逻辑和合约动态行为等安全面。它的差异化优势在于专业的 web3 安全判断力，而非新的工具：测试人员像攻击者一样解读托管、交易意图、资金流向和合规控制。二者在目标上的区别在于：常规测试通常证明的是 IT 控制层面的影响——比如管理员会话被接管、服务器被攻破——而区块链测试则将价值的实际转移作为最终判定条件。它会继续深入：在一个合法的签名请求内部篡改收款人或金额，然后检验审批人看到的内容、审批策略以及最终实际转移的资金三者是否仍然一致。
总而言之，这是一种互补性的保障，而非静态与动态测试之间的对立。代码级审计、交易级监控和传统渗透测试依然是必要的。区块链渗透测试通过验证可达路径将它们串联起来；它并不能取代它们，也不能保证发现所有入侵行为，或保证能够阻止入侵。
第二部分：监管机构的要求
要求因司法管辖区而异，针对特定实体和系统，形成了从许可要求、持续性义务到监管机构触发义务的一整套光谱。
以下示例仅供说明参考，并非法律意见。各机构应就自身身份、豁免情形、系统及义务咨询法律顾问予以确认。
-
美国纽约州：明确要求，附有限豁免。 根据 NYDFS 23 NYCRR Part 500 [12]，受监管实体（包括获得 DFS 许可的虚拟货币业务机构）必须基于风险评估，至少每年从系统内部和外部对信息系统进行测试。测试可由具备资质的内部或外部人员执行。符合条件的小型实体可就该测试条款获得有限豁免，但仍需遵守 Part 500 中其他适用条款。
-
迪拜：每年及变更触发的要求。 获许可的 VASP 必须至少每年进行一次漏洞评估和渗透测试，并在推出新系统、应用程序或产品之前进行测试 [13]，测试须由具备资质的独立第三方执行。在与 VASP 业务和活动相关的情况下，还适用智能合约审计要求。威胁导向渗透测试并无统一的测试频率：VARA 可根据风险评估在必要且合理的情况下要求进行此类测试。
-
香港：视为已获牌申请人的牌照条件要求。 视为已获牌的虚拟资产交易平台申请人，必须在受限运营之前完成渗透测试和漏洞评估，且结果须令人满意 [14]。新设公司申请人适用另行发布的指引。独立第三方须覆盖指定的基础设施和应用程序，涵盖应用层和网络层。在开始受限运营之前，管理层必须针对中高风险发现事项完成所有重大及关键整改步骤。
-
欧盟：按比例框架；TLPT 以识别结果为条件。 DORA 涵盖金融实体，包括加密资产服务提供商 [15]。该法规要求对支撑关键或重要职能的系统至少每年进行适当的测试——并非特指渗透测试。渗透测试是根据风险和相称性原则所选择的测试方法之一。威胁导向渗透测试仅适用于被主管当局识别出的实体，测试在实际生产系统上进行，通常要求至少每三年进行一次；主管当局可基于风险考虑调整该频率。DORA 同时对测试人员的独立性提出了要求。微型企业不适用测试计划要求。
-
新加坡：不具约束力的监管预期。 MAS《科技风险管理指引》指出，金融机构应进行渗透测试，并预期互联网可访问系统至少每年或在发生重大变更或更新后接受测试 [16]。这属于不具约束力的监管指引，并不要求由独立第三方执行。具有约束力、仅适用于银行的《网络卫生通知》并未明确规定渗透测试要求。具有约束力的支付或数字支付代币相关通知不在本文讨论范围之内。
综合来看，这些监管制度所要求或预期的是渗透测试本身——而非某种带有"web3"标签的专属类别。之所以需要 web3 专业化版本的测试，是由所涉系统本身决定的：只要这些系统涉及加密货币价值的授权、签名、托管或核算，就需要对其进行妥善测试，而这恰恰需要第一部分所描述的那种签名与资金流转方面的专业能力。
结论是精确的：在特定司法管辖区内，相当一部分获得许可的实体已经面临某种要求或监管预期——但这并非在每个市场都是同一种强制性规定。这些差异决定了范围、频率、测试人员独立性、整改、证据留存，以及该测试究竟是服务于牌照申请、持续合规，还是监管机构触发的专项检查。
结论：两条支点殊途同归
风险来源和监管要求或预期都指向同一个结论：对于在范围之内的机构而言，区块链渗透测试是保障体系中不可或缺的一环。它验证了跨越访问、审批、签名和资金各环节的可达路径，同时与现有控制措施形成互补。它无法保证能够阻止风险发生，无法证明它能够阻止过去任何一起具体事件，也无法找出所有可被利用的路径。其目标是在上线、运营、检测、响应以及监管取证的各个阶段提供持续性保障——而非一份一次性报告。
继续阅读本系列：
本系列即将发布：
- 第五部分：授权与签名安全：网页、dApp 与移动端
- 第六部分：云与 CI/CD 安全：自动化运营攻击面
- 第七部分：资金管理控制平面安全：签名与提款审批
- 第八部分：交易所账本安全：盗窃路径与数据平面逻辑
BlockSec 帮助各机构精准定位这一保障层：梳理资产、资金流向、信任边界以及现有保障措施；确认法律顾问指出适用的各项义务；然后明确测试目标、范围、访问权限、生产环境安全防护、整改证据以及复测计划。若想了解您的保障缺口所在，请联系我们的区块链渗透测试团队；测试范围与报价可按需索取。从资金流转的地方开始。
参考文献
按首次出现顺序编号。
- BlockSec，《加密货币支付安全指南》。
- 美国联邦调查局、DC3 及日本警察厅，《对从 Bitcoin.DMM.com 窃取 3.08 亿美元负责的朝鲜网络行为体（TraderTraitor）的身份确认》（2024 年 12 月）。
- BlockSec，《Bybit 15 亿美元黑客事件：恶意 Safe{Wallet} 升级攻击深度分析》。
- rekt.news，《BtcTurk — Rekt》。
- rekt.news，《排行榜》。
- SwissBorg，《SwissBorg 安全更新：Kiln 漏洞事件》。
- BlockSec，《TrustWallet 事件：被盗的 API 密钥将官方更新渠道变成了后门》。
- Slope，《Slope Wallet Sentry 漏洞：数字取证与事件响应报告》。
- BlockSec，《我们对 Profanity 工具漏洞的简要分析》。
- BlockSec，《Coldcard 熵值失效与种子恢复》。
- BlockSec，Phalcon Security。
- 纽约州金融服务厅，《23 NYCRR Part 500 — 金融服务公司网络安全要求》。
- 迪拜虚拟资产监管局，《技术与信息规则手册》，第 I 部分，E 节。
- 香港证券及期货事务监察委员会，通函 24EC65（2024 年 12 月 18 日，PDF）。
- 欧盟，《（欧盟）2022/2554 号条例——数字运营弹性法案（DORA）》，第 24–27 条。
- 新加坡金融管理局，《科技风险管理指引》（2021 年 1 月），第 2 节及第 13 节；《FSM-N06 号通知：网络卫生通知》（2024 年）。
