面向数字货币机构的区块链渗透测试

因为损失最惨重的那些事件，越来越多起源于智能合约之外 —— 在签名、托管、密钥、人员与供应链上。

在我们自己 2026 年的追踪中（损失超过 10 万美元的事件），合约之外的失效大约占八分之一的事件，却占了四分之三以上的损失。

代码层面的审计检查代码；交易层面的监控检查交易抵达链上时的状态。两者都没有把它们之间的那条路径拼起来。

2025 年的 Bybit 事件说明了这类问题的形状：一个被操纵的签名界面，让运营人员自己的审批变成了一笔他们从未打算发出的转账 —— 而这个结果在合约、对合约的审计以及监控看来，都可以是合法的。

更多 BlockSec 事件分析：官方更新通道中被窃取的 API key、Profanity 地址生成器的缺陷、硬件钱包的熵失效。

区别在于保证目标。

代码审计主要建立对代码的保证，包括设计、架构与协议假设。渗透测试主要确认运行中的机构环境里的真实条件能否被串成可复现的实际影响。

仅有审计通常无法提供机构范围内的运行时可利用性证据；而渗透测试也不能替代代码层面的保证。两者方法上有重叠，团队也可以协同工作。它们是互补关系，而不是彼此的替代品。

传统渗透测试在云、Web、API、身份与特权访问等攻击面上依然有价值。它可能没有带来的是数字货币业务的业务语义：一个签名可以授权不可逆的价值转移；提现审批是一项资金控制决策，而不是一次表单提交。

测试者可能找到一个认证绕过，却没有看到它如何与签名展示不一致或薄弱的审批策略组合成一条通往资金的路径。

常规测试证明的是 IT 控制层面的影响；而这项服务把价值的转移作为终止条件。真正的差异在于专业的区块链安全判断，而不是新工具。

对特定一批持牌实体而言，是的 —— 但这项义务是有条件的，并非普遍强制，而且范围、频次与独立性要求在各个市场并不相同。

• 纽约（NYDFS Part 500）：covered entity（包括持有 DFS 牌照的虚拟货币业务）必须由合格的内部或外部方，从其信息系统边界的内侧与外侧两个方向开展渗透测试，且至少每年一次。达到该规章门槛的较小型 covered entity 可就该测试条款获得有限豁免，但仍受 Part 500 其余适用条款约束。
• 迪拜（VARA）：持牌 VASP 必须由合格的独立第三方开展漏洞评估与渗透测试，至少每年一次，并在引入任何新系统、应用或产品之前进行。
• 香港（SFC）：被视为已获发牌的 VATP 申请人必须在开始受限运营之前，由独立第三方完成渗透测试与漏洞评估，并取得令人满意的结果。
• 欧盟（DORA）：除微型企业以外的金融实体，必须确保对支撑关键或重要职能的系统至少每年开展适当的测试。威胁引导的渗透测试仅适用于由其主管当局点名的实体，在生产系统上执行，且通常要求至少每三年一次。
• 新加坡（MAS TRM Guidelines）：一项不具约束力的监管期望 —— 可从互联网直接访问的系统应至少每年、或在经历重大变更后接受测试。

监管要求的是渗透测试，而不是某个品牌化的服务品类 —— 专业版本是由范围内的系统决定的：当这些系统授权、签名、托管或核算数字资产价值时，要把它们测到位，就需要对签名与资金流有足够的熟稔。

以上示例仅供说明，不构成法律意见。机构应与律师确认自身的身份认定、豁免情形与义务范围。

五项相互连接的能力 —— 同一条资金处理链上可被测试的各个面；说它们相互连接，是因为一条路径可能同时跨越其中若干个：

• 生产环境与自动化运维
• Web 与 dApp 前端、授权与签名意图
• 签名、审批与提现授权链
• 资金业务逻辑
• 链上交易与已部署合约

合约的代码层面保证，仍然由对应的 Code Audit 负责。

只在书面授权与约定的安全保障措施之下进行，并在测试开始之前记录到一份测试规则（Rules of Engagement）文档里。

RoE 把什么在范围内与允许做什么活动区分开：一个生产提现服务可以为了验证授权路径而在范围内，同时禁止真实客户提现、私钥导出、持久化以及产生负载的攻击。

对签名与提现工作流，受控场景会明确规定指定钱包、白名单目标地址、最大测试金额、参与审批的人员，以及链上活动、账务记录与余额之间的对账。

可度量的停止条件、一条受保护的安全沟通通道，以及一位有权暂停或恢复测试的指定负责人，都会与服务负责人一并约定。机构始终保有对生产决策、客户沟通与修复工作的决定权。

产出把每一条已确认的路径与可复现的证据、严重级别、修复建议，以及对约定修复项的复测连接起来 —— 而不是给出一份彼此无关的弱点清单。

最终记录会把每一项发现与它的证据、影响、责任人、修复方案与复测条件关联起来。项目结束时，临时的测试身份与权限会被回收，证据仅在约定期限内保留。

交付物与复测安排按项目约定确认。

不能，负责任的项目也不会这样声称。这项评估是有方法、以证据为准且具有时点性的：它的结论适用于所测试的那些系统、版本、配置与访问假设。

在约定范围内系统性地开展工作，并不能保证每一个弱点或攻击路径都会被发现，也不能保证测试者一定能攻破。我们检查潜在路径；已确认的可利用路径会连同可复现的证据一并记录。

它无法保证防住入侵，也无法证明它本可以阻止过去某一次具体的事件。

先从三个问题开始：哪些系统在转移资金？已经存在哪些保证证据？哪一条控制链还没有被对抗式地验证过？这些答案能识别出保证缺口，而不必过早地按名字挑一项服务。

随后的范围沟通会把目标、访问假设、生产环境保障措施与预期交付物对齐。

BlockSec 不公开固定价格。范围、周期、交付物与定制报价在技术沟通之后按需提供。