从事件到监管:加密机构为何需要区块链渗透测试

对于加密货币机构和服务提供商——包括加密货币交易所、支付公司、数字资产托管方以及托管和非托管钱包提供商——区块链渗透测试对于在其范围内的机构而言，并非可有可无的预防措施。当漏洞可能波及签名或资金，或适用规则要求进行对抗性验证时，这是保障体系中不可或缺的一环。这一论点建立在两大支柱之上：超出合约代码范围的风险来源，以及监管要求或对对抗性验证的期望。

机构面临的风险敞口不仅限于合约漏洞，还延伸到签名、托管、密钥、人员、供应链和基础设施 [1]。因此，这一攻击面并不能被人们熟悉的 web3 安全解决方案——代码层审计和交易层监控——所完全覆盖，也不能仅靠传统渗透测试来覆盖。这适用于任何存在人员、供应商、接口或应用程序可能影响签名、批准、入账或转账事项的机构——包括托管业务外包的情况。与此同时，多个市场的监管机构提出了不同范围、频率和独立性规则的要求、附条件义务或监管期望。

本文开启我们的 web3 渗透测试系列文章。在整个系列中，区块链渗透测试（blockchain penetration testing）和 web3 渗透测试（web3 penetration testing）指代同一学科：我们将前者作为主要术语，后者作为业界常用的同义词。本文从宏观、全局的角度阐述其必要性；后续文章将详细定义该学科、其操作边界以及机构层面的攻击面。

第一部分：风险从何而来

1.1 智能合约之外的风险

智能合约漏洞依然重要，但近期许多最大规模的损失源自其他方面，尤其是密钥、签名系统和运营基础设施。2024 年，攻击者通过入侵一家钱包软件提供商并操纵一笔合法的交易请求，从 DMM Bitcoin 窃取了约 3.05 亿美元 [2]。2025 年，Bybit 因供应链攻击操纵其签名界面而损失约 15 亿美元 [3]，而 BtcTurk 的热钱包损失同样可追溯至私钥泄露 [4]。我们的研究指向同一方向：在我们追踪的 2026 年损失超过 10 万美元的事件中，链下（off-contract）失败约占事件总数的八分之一，但占总损失的四分之三以上。截至 2026 年 8 月，在 rekt.news 公开排行榜上排名前十的最大黑客攻击事件中（不含欺诈及其他非黑客类条目），有七起属于链下入侵，无论按事件数量还是按美元金额计算，占比均约为 70% [5]。

钱包和托管系统正是这一模式的具体体现，钱包安全在近年来始终是事件高发的重点领域。我们的调查将失败归类为：密钥处理、交易签名管道、供应链和依赖项、敏感数据泄露，以及密码学实现。

* Coldcard 的约 9,000 万美元是经链上验证的下限（约 1,405 枚 BTC）；私下估计最高可达约 1.3 亿美元。

将这些事件与渗透测试联系起来的，并不仅仅是它们发生在合约范围之外，而是这些漏洞能否被利用，往往取决于已部署的各个组成部分——身份、依赖项、签名控制、审批和资金逻辑——是否能够组合成一条攻击者可以从入口点走到底、直达资金的完整路径。

1.2 代码层审计和交易层监控：至关重要但存在局限

现有每一种知名的 web3 安全解决方案都作用于特定层面。代码层审计检查代码（代码审计）审查合约、钱包或服务逻辑代码。交易层监控（监控）在交易上链时对其进行检查；例如，Phalcon [11] 能够在运行时检测、告警并拦截恶意活动。

这些解决方案很有用，但在面对加密货币机构的资金处理链条——即由相互关联的身份、云基础设施、签名工作流、审批链、钱包、供应商和操作员控制台构成，价值从入口点流向资金转移操作的整个链条——时，就显得力有不逮。攻击者可利用的路径，是横跨该链条的一条路线：它可能从 Web、dApp、移动端、API、云或身份入口点出发，穿过签名、审批和资金逻辑，也可能涉及合约在该实时环境中的实际行为，最终抵达资金转移操作。审查代码并不能拼凑出这条路径，监控交易也无法预见它。即便将两者结合使用，仍可能留下组合层面的缺口：审计只能证明代码在编写时是合理的，无法证明已部署的身份、审批和签名方仍在切实执行该逻辑；而监控可能会放行一笔在技术上合法有效、但从未获得操作员真实意图授权的转账。要弥合这一缺口，需要独立的对抗性验证，来确认各项控制措施在实际运行的系统中是否正确组合运作。

区块链渗透测试通过对已部署、正在运行的系统进行实测，来发现并证明是否存在这样一条可以在事故发生前抵达资金的路径。Bybit 事件模式揭示了这一问题的本质：被入侵的签名界面将操作员自己的审批变成了一笔他们从未打算进行的转账——而无论是合约本身、对合约的审计，还是交易监控，都可能将这一结果判定为合法。Web3 渗透测试正是直接针对这种组合层面的问题：以被入侵的供应商、操作员或接口的立场出发，测试这样的立足点能否将一笔看似合法的审批转变为未经授权的资金转移，以及哪些已部署的控制措施——身份、审批步骤、签名检查——真正能够阻止这一行为。合约代码层面的保障仍然是审计的职责；web3 渗透测试仅在已部署合约的实时行为构成机构层面通向资金的路径的一部分时才涉及该合约——两者的范围互为补充，区别在于侧重点，而非存在硬性界限。第二部分将定义 web3 渗透测试所验证的内容及其范围边界。

1.3 传统渗透测试：有用，但并不足够

传统渗透测试在云、Web 和 API、身份以及特权访问等层面上依然具有价值。它的局限在于范围和领域上下文：常规的测试项目可能无法涵盖加密货币特有的业务语义及其相互耦合的安全与合规模型。

在加密货币领域，一个签名可能授权不可逆的价值转移；提现批准是一项资金控制决策，而不仅仅是表单提交。存款入账、余额核算和内部转账都属于资金逻辑。地址和交易也可能承载制裁或资金来源方面的含义。测试人员可能发现了一个身份验证绕过漏洞，却未能察觉它如何与签名显示不一致、薄弱的审批策略或舍入误差相结合，形成一条通向资金的路径。

区块链渗透测试将成熟的对抗性技术应用于传统攻击面，以及贯穿整个运行系统的 web3 特有的签名、审批、资金逻辑和合约动态行为攻击面。它的差异化优势在于专业的 web3 安全判断力，而非新的工具：测试人员会像攻击者一样解读托管、交易意图、资金流动和合规控制。二者的差异在于目标不同：常规测试通常证明的是 IT 控制层面的影响——例如管理员会话被劫持、服务器被攻陷——而 web3 测试则将价值的实际转移作为最终验证条件。它不止于此：它会在一个合法的签名请求中篡改收款人或金额，然后检查审批人所看到的内容、审批策略以及实际转移的资金三者是否依然保持一致。

总而言之，这是一种互补性的保障，而非静态分析与动态分析之间的一道壁垒。代码层审计、交易层监控和传统渗透测试依然是必要的。Web3 渗透测试通过验证可达路径将它们联系起来；它并不能取代它们，也无法保证发现所有漏洞或保证防范一切风险。

第二部分：监管机构的要求

各司法辖区的要求各不相同，针对特定实体和系统形成了一系列牌照、持续性以及监管机构触发式的义务谱系。

这些示例仅供参考说明之用，并非法律意见。机构应就自身地位、豁免情形、系统及义务咨询法律顾问加以确认。

• 美国纽约州：明确要求，附有限豁免。 根据 NYDFS 23 NYCRR Part 500 [12] 受监管的实体——包括获得 DFS 许可的虚拟货币企业——必须基于风险评估，至少每年一次从系统内部和外部对信息系统进行测试。测试可由合格的内部人员或外部第三方执行。符合条件的小型实体可获得该测试条款的有限豁免，但仍需遵守 Part 500 中其他适用条款。

• 迪拜：每年及变更触发式要求。 持牌 VASP（虚拟资产服务提供商）必须至少每年进行一次漏洞评估和渗透测试，并在引入新系统、应用程序或产品之前进行测试 [13]，测试须由合格的独立第三方执行。智能合约审计适用于与 VASP 业务和活动相关的情形。威胁引导型渗透测试（threat-led penetration testing）没有统一的执行频率：VARA 可根据风险情况，在必要且相称时要求进行此类测试。

• 香港：视为持牌申请人的牌照条件要求。 视为持牌的虚拟资产交易平台申请人必须在限制运营开始前完成渗透测试和漏洞评估，并取得令人满意的结果 [14]。针对新设公司申请人则适用另外的指引。测试须由独立第三方执行，覆盖应用层和网络层的指定基础设施和应用程序。在限制运营开始之前，管理层必须完成针对中高风险发现事项的所有主要及关键整改措施。

• 欧盟：比例原则框架；TLPT 以识别为前提条件。 DORA 适用于金融实体，包括加密资产服务提供商 [15]。该法规要求对支撑关键或重要功能的系统至少每年进行一次适当的测试——并非特指渗透测试。渗透测试是根据风险和相称性原则选择的一种测试方法。威胁引导型渗透测试仅适用于经主管机构识别指定的实体，须在生产系统上实际进行，通常至少每三年进行一次；主管机构可根据风险因素调整该频率。DORA 还对测试人员的独立性提出了相关条件要求。微型企业不受该测试计划要求的约束。

• 新加坡：非强制性的监管期望。 MAS《技术风险管理指引》指出，金融机构应进行渗透测试，并期望面向互联网的系统至少每年或在发生重大变更或更新后接受一次测试 [16]。这属于非强制性的监管指引，并不要求由独立第三方执行。具有约束力、适用于银行范围的《网络卫生通知》并未具体规定渗透测试要求。具有约束力的支付或数字支付代币相关通知不在本文讨论范围之内。

综合来看，这些监管制度要求或期望进行渗透测试——而非某种带有品牌色彩的"web3"类别测试。Web3 专业版渗透测试的必要性源自其所涉及的系统本身：只要这些系统涉及加密货币价值的授权、签名、托管或核算，对其进行妥善测试，就需要具备第一部分所述的那种对签名和资金流动的专业理解能力。

结论是精确的：在特定司法辖区内，大量持牌实体已经面临某种要求或监管期望——但这在不同市场并非同一强制性规定。这些差异决定了范围、频率、测试人员独立性、整改、证据留存，以及测试是服务于牌照申请、持续合规，还是监管机构触发的专项审查。

结论：两大支柱的交汇

风险来源与监管要求或期望这两条线索，共同指向同一个结论：对于处于适用范围内的机构而言，web3 渗透测试是保障体系中不可或缺的一环。它在验证访问、审批、签名和资金各环节可达路径的同时，与现有控制措施形成互补。它无法保证防范一切风险，无法证明它本可以阻止任何特定的历史事件，也无法找出所有可被利用的路径。其目标是在产品发布、日常运营、检测、响应和监管取证等各个环节持续提供保障——而非一份一次性报告。

继续阅读本系列文章：

• 第二部分：什么是 Web3 渗透测试？定义与边界

• 第三部分：机构级 Web3 渗透测试的交战规则与生产安全

• 第四部分：Web3 攻击面：渗透测试概览

本系列即将发布的其他文章：

• 第五部分：授权与签名安全：Web、dApp 与移动端
• 第六部分：云与 CI/CD 安全：自动化运营攻击面
• 第七部分：资金管理控制平面安全：签名与提现审批
• 第八部分：交易所账本安全：盗窃路径与数据平面逻辑

BlockSec 帮助机构精准定位这一保障层级：梳理资产、资金流动、信任边界及现有保障措施；确认法律顾问认定适用的各项义务；随后明确测试目标、范围、访问权限、生产环境安全保障措施、整改证据及复测计划。若要识别您的保障缺口，请联系我们的区块链渗透测试团队 ；测试范围和报价可应要求提供。从资金流动之处开始。

参考文献

按首次出现顺序编号。

1. BlockSec, 《加密支付安全手册》. https://blocksec.com/crypto-payment-playbook

2. 美国联邦调查局（FBI）、DC3 及日本国家警察厅, 《对造成 Bitcoin.DMM.com 3.08 亿美元被盗事件负责的朝鲜网络行动人员（TraderTraitor）的身份认定》（2024 年 12 月）. https://www.fbi.gov/news/press-releases/fbi-dc3-and-npa-identification-of-north-korean-cyber-actors-tracked-as-tradertraitor-responsible-for-theft-of-308-million-from-bitcoindmmcom

3. BlockSec, 《Bybit 15 亿美元黑客事件：恶意 Safe{Wallet} 升级攻击深度分析》. https://blocksec.com/blog/bybit-1-5-b-hack-in-depth-analysis-of-the-malicious-safe-wallet-upgrade-attack

4. rekt.news, 《BtcTurk — Rekt》. https://rekt.news/btcturk-rekt

5. rekt.news, 《排行榜》. https://rekt.news/leaderboard

6. SwissBorg, 《SwissBorg 安全更新：Kiln 事件》. https://swissborg.com/blog/swissborg-security-update-kiln-breach

7. BlockSec, 《TrustWallet 事件：被盗的 API 密钥如何将官方更新渠道变成后门》. https://blocksec.com/blog/trust-wallet-incident-a-stolen-api-key-turns-the-official-update-channel-into-a-backdoor

8. Slope, 《Slope Wallet Sentry 漏洞：数字取证与事件响应报告》. https://slope-finance.medium.com/slope-wallet-sentry-vulnerability-digital-forensics-and-incident-response-report-d7a5904e5a39

9. BlockSec, 《我们对 Profanity 工具漏洞的简要分析》. https://blocksec.com/blog/our-short-analysis-of-the-profanity-tool-vulnerability

10. BlockSec, 《Coldcard 熵值失效与种子恢复》（私钥泄露）. https://blocksec.com/blog/coldcard-entropy-failure-seed-recovery

11. BlockSec, Phalcon Security（交易监控与拦截）. https://blocksec.com/phalcon/security

12. 纽约州金融服务局, 23 NYCRR Part 500. https://www.dfs.ny.gov/industry_guidance/cybersecurity

13. 迪拜虚拟资产监管局, 《技术与信息规则手册》第一部分 E 节. https://rulebooks.vara.ae/rulebook/e-testing-and-audit

14. 香港证券及期货事务监察委员会, 《通函 24EC65，2024 年 12 月 18 日》. https://apps.sfc.hk/edistributionWeb/api/circular/openFile?lang=EN&refNo=24EC65

15. 欧盟, 《条例 (EU) 2022/2554（数字运营弹性法案）》，第 24-27 条. https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng

16. 新加坡金融管理局, 《技术风险管理指引》（2021 年 1 月），第 2 及第 13 节, https://www.mas.gov.sg/regulation/guidelines/technology-risk-management-guidelines; _《FSM-N06 通知：网络卫生通知》_（2024 年）, https://www.mas.gov.sg/regulation/notices/notice-fsm-n06