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

机构面临的风险敞口不仅限于合约漏洞,还延伸至签名、托管、密钥、人员、供应链和基础设施 [1]。因此,这一攻击面无法仅靠人们熟悉的web3安全解决方案——代码级审计和交易级监控——或仅靠传统渗透测试来完全覆盖。这适用于任何存在这样情况的机构:某个人、供应商、接口或应用程序能够影响哪些内容被签署、批准、入账或转移——包括托管被外包的情形。与此同时,多个市场的监管机构提出了不同范围、频率和独立性规则的要求、附条件义务或监管期望。
本文开启我们的区块链渗透测试系列文章。在整个系列中,区块链渗透测试(blockchain penetration testing)和区块链渗透测试(blockchain pen 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]。
钱包和托管系统使这一模式变得具体,而钱包安全近年来一直是事件高发的活跃领域。我们的调查将失误归类为密钥处理、交易签名流程、供应链与依赖项、敏感数据泄露以及密码学实现。
| 链下失误 | 代表性事件 | 大致损失(已披露) |
|---|---|---|
| 密钥处理 | 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亿美元。
将这些事件与渗透测试联系起来的,不仅仅是它们发生在合约之外这一事实,而是这些漏洞能否被利用,往往取决于已部署的各个环节——身份、依赖项、签名控制、审批流程和资金逻辑——如何组合成一条攻击者可以从入口端走到资金端的完整路径。
1.2 代码级审计与交易级监控:不可或缺但存在局限
现有每种知名的web3安全解决方案都在特定层面发挥作用。**代码级审计(code audit)**检查代码——合约、钱包或服务逻辑。交易级监控(监控)检查交易到达链上时的情况;例如,Phalcon Security [11] 在运行时检测、告警并阻止恶意活动。
这些解决方案本身很有用,但当涉及加密货币机构的资金处理链——即价值从入口点流向资金转移操作所经过的相互关联的身份、云基础设施、签名工作流、审批链、钱包、供应商和操作员控制台——时,它们就显得局限。攻击者可利用的路径是穿越该链条的一条路线:它可以从网页、dApp、移动端、API、云端或身份入口点出发,经过签名、审批和资金逻辑,也可以经过合约在该实时环境中的行为方式,最终抵达另一端的资金转移操作。审查代码并不能将这条路径组装起来,监控交易也无法提前预知它。即使两者结合使用,仍可能存在组合缺口:审计只能证明代码在编写时是稳健的,而不能证明已部署的身份、审批流程和签名者仍在执行这些规则;监控则可能放行一笔技术上有效、但从未是操作员本意的转账。能够弥合这一缺口的,是独立的对抗性验证,用以确认各项控制在运行系统中是否正确组合运作。
区块链渗透测试对已组装完成的、正在运行的系统进行实测,以在事件暴露之前发现并证明这样的路径是否存在。Bybit事件的模式清楚地展示了这一问题的形态:一个被攻陷的签名接口,将操作员自己的批准变成了他们从未打算进行的转账——而合约本身、对合约的审计以及交易监控都可能将这一结果读取为合法操作。区块链渗透测试直接针对这种组合关系:以被攻陷的供应商、操作员或接口的身份,测试这样的立足点能否将一个看似有效的审批转变为未经授权的资金转移,以及已部署的哪些控制措施——身份、审批环节、签名检查——实际上能够阻止这一切。合约代码层面的保障仍然是审计的职责;区块链渗透测试仅在已部署合约的实时行为构成机构级资金路径一部分时才涉及该合约——这是互补的范围划分,以侧重点区分,而非硬性边界。第二部分将定义区块链渗透测试所验证的内容及其范围边界。
1.3 传统渗透测试:有用但不足够
传统渗透测试在云端、Web和API、身份及特权访问等层面依然具有价值。它的局限在于范围和领域背景:常规的测试项目可能不涉及加密货币特有的业务语义或紧密耦合的安全与合规模型。
在加密货币领域,一个签名可以授权不可逆的资金转移;提现审批是一项资金控制决策,而不仅仅是表单提交。存款入账、余额核算和内部转账都属于资金逻辑。地址和交易也可能带有制裁或资金来源方面的含义。测试人员可能发现了一个身份验证绕过漏洞,却忽略了它如何与签名显示不一致、薄弱的审批策略或舍入误差相结合,形成通往资金的路径。
区块链渗透测试将成熟的对抗性技术应用于传统攻击面,以及贯穿整个运行系统的web3特有的签名、审批、资金逻辑和合约动态行为攻击面。它的差异化优势在于专业的web3安全判断力,而非新工具:测试人员会像攻击者一样解读托管、交易意图、资金流向和合规控制。两者的差异体现在目标上:传统测试通常证明的是IT控制层面的影响——比如接管了一个管理员会话、攻陷了一台服务器——而区块链测试则将资金的实际转移作为最终判定条件。它会继续深入:在一个合法的签名请求内部篡改收款方或金额,并检查审批人所看到的内容、审批策略以及实际转移的资金三者是否仍然一致。
总而言之,这是一种互补性的保障,而非静态与动态之间的对立。代码级审计、交易级监控和传统渗透测试依然是必要的。区块链渗透测试通过验证可达路径将它们联系起来;它并不能取代它们,也无法保证发现所有入侵,或保证百分之百的防范。
第二部分:监管机构的要求
要求因司法管辖区而异,针对特定实体和系统形成了从许可、持续性到监管触发义务的一系列谱系。

这些示例仅作说明用途,不构成法律意见。机构应就其身份地位、豁免情形、系统情况及义务咨询法律顾问加以确认。
-
美国纽约州:明确要求,附有限豁免。 根据NYDFS 23 NYCRR Part 500 [12] 受监管的实体,包括获DFS许可的虚拟货币企业,必须基于风险评估,至少每年从内部和外部两方面对信息系统进行测试。测试可由合格的内部或外部方进行。符合条件的小型实体在该测试条款上享有有限豁免,但仍须遵守Part 500的其他适用条款。
-
迪拜:年度性及变更触发型要求。 获许可的VASP必须至少每年,并在引入新系统、应用程序或产品之前,使用合格且独立的第三方进行漏洞评估和渗透测试 [13]。智能合约审计适用于与该VASP的业务和活动相关的情形。威胁引导型渗透测试没有统一的频率要求:VARA可根据风险判断在必要且合理的情况下要求进行此类测试。
-
香港:视为已获牌申请人的牌照条件要求。 视为已获牌的虚拟资产交易平台申请人必须在受限运营前完成渗透测试和漏洞评估,并取得令人满意的结果 [14]。新公司申请人适用另外的指引。独立第三方必须覆盖应用层和网络层的指定基础设施和应用程序。在受限运营开始之前,管理层必须完成所有针对中高风险发现事项的重大及关键整改步骤。
-
欧盟:比例性框架;威胁引导型渗透测试以被识别为前提。 DORA适用于金融实体,包括加密资产服务提供商 [15]。它要求对支持关键或重要职能的系统至少每年进行适当的测试——并非特指渗透测试。渗透测试是根据风险和比例原则选择的一种方法。威胁引导型渗透测试仅适用于被主管机关识别的实体,需在实际生产系统上进行,通常要求至少每三年一次;主管机关可基于风险考量调整该频率。DORA还规定了测试人员独立性方面的条件。微型企业不在测试计划要求范围内。
-
新加坡:不具约束力的监管期望。 MAS《技术风险管理指引》指出,金融机构应进行渗透测试,并期望可通过互联网访问的系统至少每年或在发生重大变更或更新后接受测试 [16]。这属于不具约束力的监管指引,且不要求由独立第三方进行。具有约束力、适用于银行范围的《网络卫生通知》未对渗透测试作出规定。具有约束力的支付或数字支付代币通知不在本文讨论范围内。
综合来看,这些监管制度要求或期望进行的是渗透测试——而非某种打上"web3"标签的类别。web3专业化版本的测试要求,源自其涉及的系统范围:只要这些系统涉及加密货币价值的授权、签名、托管或核算,恰当地对其进行测试就需要具备第一部分所述的同样的签名及资金流向方面的专业素养。
结论是精确的:在特定司法管辖区,相当数量的持牌实体已经面临某种要求或监管期望——但这并非每个市场都统一适用的强制规定。这些差异决定了测试的范围、频率、测试人员独立性、整改要求、证据留存,以及测试是服务于牌照申请、持续性合规,还是监管触发型的专项检查。
结论:两大支柱的汇合
风险来源与监管要求或期望共同指向同一个结论:对于在范围内的机构而言,区块链渗透测试是一层必要的保障机制。它在补充现有控制措施的同时,验证跨越访问、审批、签名和资金各环节的可达路径。它无法保证百分之百的防范,无法证明它本可以阻止任何特定的历史事件,也无法找出所有可被利用的路径。其目标是在产品上线、运营、检测、响应及监管取证等各个阶段提供持续性保障——而非一份一次性的报告。
继续阅读本系列:
本系列还将陆续发布以下文章:
- 第五部分:授权与签名安全:Web、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 — 金融服务公司网络安全要求。
- 迪拜虚拟资产监管局,技术与信息规则手册,第一部分,E节。
- 香港证券及期货事务监察委员会,通函24EC65(2024年12月18日,PDF)。
- 欧盟,(欧盟)2022/2554号条例——数字运营韧性法案(DORA),第24-27条。
- 新加坡金融管理局,技术风险管理指引(2021年1月),第2节与第13节;FSM-N06号通知:网络卫生通知(2024年)。



