NEWVenvera 支持您的语言: 完整平台支持英语、德语、西班牙语、保加利亚语、阿拉伯语和简体中文。查看新功能 →
VARA 渗透测试与智能合约审计
合规指南

VARA 渗透测试与智能合约审计

·Alexander Sverdlov
VARA 合规 · 迪拜

具有约束力的测试义务只是 Rule I.E.1 中的一句话,并且有两个触发条件。多数解读只引用年度触发条件,却漏掉另一个,而后者实际上更常被触发。

迪拜虚拟资产服务提供商的 VARA 渗透测试和智能合约审计要求

如果您想查看 VARA 具有约束力的渗透测试和智能合约审计要求全文,它位于 Technology and Information Rulebook 的 Rule I.E.1,原文大意如下:VASP 必须聘请合格且独立的第三方审计师开展漏洞评估和渗透测试,包括(在与业务和 VA Activities 相关的范围内)对所有智能合约的有效性、可执行性和稳健性进行全面审计,至少每年一次,并且在引入任何新系统、应用程序和产品之前进行。

两个触发条件。年度触发是所有人都会引用的那个。“在引入任何新系统、应用程序和产品之前”才是真正约束 VASP 发布产品的触发条件,而且它没有可供回避的日历周期。

您读到的关于这个主题的其他内容,包括季度漏洞评估、部署前智能合约审计、形式化验证、由合格第三方开展的渗透测试,都是真实存在的,但它们来自 Schedule 1。VARA 明确将 Schedule 1 作为 Guidance 发布,并用 VASP “expected to” do 的表述来描述。Schedule 1 是用于构建您的 Technology Governance and Risk Assessment Framework 的风险分类体系。并不存在所谓“Risk Category 2 中的 VASP”。本文将 Rules 与 Guidance 区分开,并逐一标明来源。

1
Rules,Part I Section E

四项具有约束力的测试 Rules,以及各自规定的义务

规则 义务
I.E.1 聘请合格且独立的第三方审计师开展漏洞评估和渗透测试,包括在与 VASP 业务和 VA 活动相关的范围内,对所有智能合约的有效性、可执行性和稳健性进行全面审计,至少每年一次,并且在引入任何新系统、应用程序和产品之前进行。应 VARA 要求提供结果。
I.E.2 维持有效的内部职能和措施以进行持续监控。VASPs 必须定期并应 VARA 要求执行 (a) 对基础设施和应用程序的安全测试,以及 (b) 内部系统和外部系统的漏洞审计。
I.E.3 测试和审计的证据必须形成文档,并应 VARA 要求立即提供以供检查。
I.E.4 VASPs 应确保其定期接受独立审计师审计,以检查其管理流程中流程、程序和控制措施的有效性,以及其对监管要求的合规情况。应 VARA 要求向其提供结果。

将这些规则放在一起看,会得出三点,而大多数测试计划都会在这些点上出错。

  • 触发因素既包括变更,也包括日历。如果一家 VASP 在 1 月完成了一次没有问题的年度渗透测试,却在 6 月上线了一个未经测试的新托管产品,就已经违反 I.E.1。应相应编制预算,因为繁忙的发布日程会把一次年度测试变成多次测试,而独立测试人员往往需要提前数周预约,因此您的上线日期最终会受制于别人的日程安排。这正是测试预算通常拨款不足的项目。规则写的是“and”,不是“or”。
  • 智能合约审计属于渗透测试义务的一部分,而不是并列事项。I.E.1 将其放在同一句话中,并以“to the extent relevant to the VASP’s business and VA Activities”加以限定。如果您部署或实质性依赖智能合约,审计就是同一项年度和上线前义务的一部分,并且必须由同一家合格、独立的第三方完成。
  • “Regular”是一项规则,间隔由您确定。I.E.2 要求安全测试和漏洞审计“on a regular basis”进行,但没有设定具体数字,同时还增加了“on request by VARA”。流传的季度频率来自 Schedule 1 Guidance,您在自己的策略文件中应准确区分这一点。

Section E 没有说的内容包括:没有指定方法论(没有 OWASP、PTES 或 CREST),没有规定报告格式,没有规定严重性等级,没有规定修复服务级别,也没有规定服务提供商轮换要求。任何把“关键审计发现需在 48 小时内处理”说成 VARA 规则的文章,都是自行杜撰。Section E 确实要求的是证据必须形成文档,并应 VARA 要求立即提供,这是一项您确实可能未能履行的文档义务。

2
指南,Schedule 1 RC2

季度频率从何而来,以及其实际含义

关于 VARA 附表 1 安全测试预期的引文,包括年度渗透测试和季度漏洞评估

附表 1 的安全测试标准(风险类别 2,标准 11)是您所见所有被归因于 VARA 的频率要求的来源。其框架性句子才是重点:

“为确保在漏洞被利用之前持续识别并修复漏洞,VASPs 应定期开展适当的安全测试,并且在任何生产系统更新之前均应开展。此类安全测试应包括但不限于:a. 由合格第三方进行的年度渗透测试;b. 季度漏洞评估;c. 持续自动化安全扫描;d. 针对高价值系统的定期最佳实践安全演练;以及 e. 对已识别漏洞进行正式修复跟踪。”

VARA Technology and Information Rulebook,附表 1,风险类别 2,标准 11

请注意,这比通常的报道要窄得多。它是 Guidance 中列明的一项预期。而且在一个方面它比规则更严格:Guidance 预期在任何生产系统更新之前进行测试,而规则 I.E.1 要求在引入新系统、应用程序和产品之前进行测试。Guidance 还将正式修复跟踪列为测试的必要组成部分。这是大多数 VASPs 无法提供证据的项目。尽管这里是 Guidance,也应认真对待。当监管人员手里同时拿着一条写有新产品的规则,以及一份写有任何生产更新的 Guidance 时,辩称您的发布只是一次更新,可能在纸面上赢,却在现场输。

风险类别 2 的智能合约安全标准(标准 4)是另一半,而且足够简短,可以完整列出。VASPs 应实施正式的智能合约审查和测试流程,包括:静态和动态代码分析;部署前的独立第三方审计,以及在适用情况下进行形式化验证;全面渗透测试;以及对已部署合约进行定期重新评估。

VARA 未说明的智能合约审计事项

它没有列明任何漏洞类别。重入、预言机操纵、闪电贷攻击向量和抢跑都是真实存在的,您的审计师也应覆盖这些内容,但 VARA 并未规定其中任何一项,也没有发布漏洞类别的强制与预期矩阵。它没有设定审计时长、审计师认证要求,也没有设定超过何种价值阈值后形式化验证即成为强制要求。形式化验证是在“适用情况下”被预期开展的事项,这是您需要在自身风险评估中作出并说明理由的判断。任何声称提供 VARA 智能合约漏洞检查清单的人,提供的都是其自己的清单。

3
规则 I.E.5 至 I.E.10

TLPT:仅在 VARA 通知您时适用

示意图,展示 VARA 测试义务如何锚定在第 I 部分 E 节的有约束力规则和附表 1 Guidance 之中

Threat-Led Penetration Testing 并非常设测试计划的一部分。规则 I.E.5 明确说明这是一项通知权:“VARA 可以通知某 VASP 其必须通过 TLPT 开展高级测试,前提是 VARA 认为这样做有必要且相称”,并会考虑该 VASP 已面临或可能面临的任何特定风险、该 VASP 的业务或 VA Activities 的关键性,以及任何其他相关风险。如果 VARA 尚未通知您,您就没有 TLPT 义务。也正因如此,规则 I.E.6 至 I.E.10 值得现在就阅读,而不是等通知送达当天再看。您需要从关键服务提供商处取得的参与条款和审计权条款,往往需要数月时间重新谈判;而没有合同义务参与的服务提供商,完全有商业动机拒绝参与。

当 VARA 确实发出通知时,规则 I.E.6 至 I.E.10 会设定相关条件。以下是您编写工作说明书时真正重要的要求:

  • 仅限外部测试人员(I.E.6.a)。每项 TLPT 均应由外部测试人员执行。不存在内部测试人员例外。
  • 在有要求时使用实时生产环境(I.E.6.b)。TLPT 可能被要求覆盖关键或重要职能,并且在有要求时,应在支持这些职能的实时生产系统、技术和流程上执行。
  • 您的第三方可能会被纳入(I.E.6.c)。在有必要将第三方服务提供商纳入范围时,VASP 应确保其参与。这是您需要在通知到来之前解决的合同问题,而不是之后。
  • 测试风险由您承担(I.E.6.d)。VASP 必须缓解测试风险,包括对数据的影响、对资产的损害,以及对 VASP 自身或其交易对手的关键或重要职能造成的中断,同时对客户资产的数据安全和隐私提供适当的安全保证。
  • 总结、整改计划和方法证明(I.E.6.e 和 I.E.6.f)。测试结束时,VASP 必须与外部测试人员共同形成相关审计发现的总结、整改计划,以及证明 TLPT 按照要求开展的文件,并且必须及时将全部内容提供给 VARA。

规则 I.E.7 规定了测试人员标准,对于 VARA 规则而言,其具体程度并不常见。外部测试人员必须适格且声誉良好;具备所有必要的技术和组织能力,并证明其在威胁情报和渗透测试方面具有特定专长;已获得认证机构认证,或遵守正式行为准则或伦理框架;就 TLPT 执行风险的稳健管理提供独立保证或审计报告,包括保护 VASP 的机密信息;并且已妥善且充分投保相关专业赔偿保险,包括针对不当行为和疏忽风险的保险。

规则 I.E.8 直接延伸到合同本身:与外部测试人员签订的协议必须要求对 TLPT 结果及其任何数据处理进行稳健管理(生成、存储、汇总、起草、报告、沟通和销毁),且不得为 VASP 或其任何系统造成额外风险。

规则 I.E.9 和 I.E.10 处理一种特定结构。如果可以合理预期第三方技术服务提供商的参与会对其向市场提供的服务质量或安全性,或与这些服务相关的数据保密性产生不利影响,则 VASP 与该服务提供商可约定由该服务提供商直接与外部测试人员签约。如果采用这种安排,该服务提供商仍必须接受 VASP 的指导,结果必须覆盖支持 VASP 关键或重要职能的相关服务范围,并且该服务提供商向测试人员提供的所有结果都必须公平反映 VASP 的情况,并且专门针对 VASP。

VARA 未规定 TLPT 持续时间、测试频率、红队或白队结构,也未要求紫队协同。它未点名 OSCP、CREST 或任何其他认证。I.E.7.c 中的认证要求,可通过认证机构认证或遵守正式行为准则或伦理框架来满足。规则中写明的是“或”。

4
指引,附表 1 RC5

数字运营韧性测试,以及年度最低要求

附表 1 风险类别 5 将视角从安全测试扩展到运营韧性。它属于指引,并包含该附表中的第二项具体频率要求。VASP 预期应:

  • 建立并维护健全、全面的数字运营韧性测试方案;
  • 识别弱点、缺陷和差距,并及时实施纠正措施;
  • 遵循基于风险的方法,考虑具体风险、资产和服务的关键性,以及任何其他重大风险因素;
  • 确保测试由独立外部方执行;
  • 对发现的所有问题进行分类和补救,并建立内部验证流程,以确认每一项已识别的弱点均得到充分处理;以及
  • 确保至少每年对支持关键或重要职能的所有系统和应用程序开展适当测试。

该方案本身预计将通过以下方式对工具和系统进行演练,包括:漏洞评估和扫描;开源分析;网络安全评估;差距分析;物理安全审查;问卷和扫描软件解决方案;源代码审查;基于场景的测试;兼容性测试;性能测试;端到端测试;以及渗透测试。该清单共有十二项,是 VARA 发布的最接近测试菜单的内容。其中没有规定持续时间、团队结构或恢复时间目标。

5
规则及其他规则手册

Section E 之外的审计

Venvera 第三方风险管理登记册,显示供应商、关键性和评估状态
Rule I.E.6.c 可能会将您的第三方服务提供商纳入 TLPT。包含关键性和合同状态的供应商登记册,是开启这一讨论的起点。

仅根据 Section E 制定的测试日历,会漏掉 VARA 在其他位置规定的有约束力的审计义务。其中有三项很重要:

  • 外部审计,每年一次(Compliance and Risk Management Rulebook I.G.1)。独立第三方审计师必须审计财务报表并出具年度报告,且在任命时必须向 VARA 通知审计师的全名和联系方式。如果原审计师被认为不适合企业的规模、复杂性和声誉,VARA 可以要求 VASP 任命替代审计师。
  • 内部审计,每季度一次(Compliance and Risk Management Rulebook I.G.2)。在适用情况下,应设立独立于运营职能、客观的内部审计职能,直接向高级管理层报告,定期开展审计工作,并且至少每季度一次,向高级管理层通报审计发现并跟进直至解决。
  • 钱包转账机制,如果您是托管方(Custody Services Rulebook III.C.1.c)。确定热钱包、冷钱包和温钱包之间转账的方法必须有充分文档记录,并受内部控制措施约束,且由独立第三方审计师执行审计。这是一项不同于 Section E 渗透测试的独立审计,很容易被遗漏在覆盖范围之外。

再加上 Rule I.E.4,即由独立审计师对 VASP 的管理流程和监管合规情况进行定期审计,整体情况就是 VASP 面临四套不同的审计制度:技术测试、财务报表、内部审计和管理流程审计。它们有不同的审计师、不同的周期和不同的报告。把它们合并成合规日历上的一条事项,正是造成差距的方式。托管审计是那个不显眼的遗漏项。机构把资产在热钱包、冷钱包和温钱包之间的移动视为工程细节,而 Custody Services Rulebook 将其视为经审计的控制措施;到了无人安排该项审计的那一年,它就会以审计发现的形式浮现。

6
规划

测试日历,每一行都可追溯至其来源

VASP 测试计划的仪表板示意图,包含已安排的测试和未关闭的审计发现
活动 时间 执行方 来源和状态
漏洞评估和渗透测试,适用时包括智能合约审计 至少每年一次,并且在任何新系统、应用程序或产品上线前进行 合格且独立的第三方审计师 Rule I.E.1 - 具有约束力
基础设施和应用程序的安全测试;内部和外部漏洞审计 定期进行,并按 VARA 要求进行 未指定 Rule I.E.2 - 具有约束力,未设定间隔
漏洞评估 每季度 未指定 Schedule 1, RC2 standard 11.b - 指引
生产系统任何更新前的安全测试 每次生产更新 未指定 Schedule 1, RC2 standard 11 - 指引,比 Rule 更严格
支持关键或重要职能的系统的韧性测试 至少每年一次 独立外部方 Schedule 1, RC5 standard 1 - 指引
内部审计 至少每季度一次 内部审计职能,独立于运营 Compliance and Risk Management Rulebook I.G.2 - 具有约束力
财务报表外部审计 年度报告 独立第三方审计师,并通知 VARA Compliance and Risk Management Rulebook I.G.1 - 具有约束力
TLPT 仅在 VARA 通知您时 符合 Rule I.E.7 的外部测试方 Rules I.E.5 to I.E.10 - 一经通知即具有约束力

请注意缺少的内容:没有持续时长、没有团队规模、没有成本区间、没有补救服务级别。VARA 并未发布这些内容,因此您的策略不应假装引用了这些内容。在规则手册未明确间隔的地方,Rule I.A.2 要求您的策略和控制措施考虑业务的性质、规模和复杂性、其运营的多样性,以及其交易的数量和规模。设定数字,写明理由,并准备好为其辩护。

使证据可立即提供,这才是实际的 Rule

规则 I.E.3 会悄然决定该计划其余部分是否算数:测试和审计的证据必须形成文档,并在 VARA 要求时立即提供以供检查。一份渗透测试报告如果只是放在某个人的收件箱里,没有记录哪些审计发现已关闭以及何时关闭,就不符合这一标准。关闭审计发现才是真正的工作;出具报告只是较容易的一半。请假设请求会在最糟糕的时刻到来,并据此构建机制:每一项审计发现都应有负责人、日期和关闭证据,并存放在另一个人无需依赖您也能访问的位置。

Venvera 并不提供 VARA 框架模块,本文也不声称提供。Venvera 提供的是可将其落地的结构:一个韧性测试登记册,用于安排测试,并让每项审计发现都带有严重性、负责人、整改计划和整改状态(该结构为 DORA 测试条款而构建,也正是 Section E 计划所需的形态);带有新鲜度跟踪的证据库;用于承载 VARA 留给您的基于风险判断的风险登记册;面向规则 I.E.6.c 可能纳入 TLPT 的服务提供商的第三方风险管理;以及控制措施框架映射,让一次测试服务于 ISO 27001、NIST CSF 和 UAE Information Assurance,而不是为每个框架重复执行。

审计发现、负责人和关闭证据集中一处

安排测试,跟踪每项审计发现直至关闭,并让证据随时可用于应对突如其来的请求。

常见问题

VARA 要求多久进行一次渗透测试?

至少每年一次,并且在引入任何新系统、应用程序和产品之前进行。《技术与信息规则手册》的规则 I.E.1 使用“and”连接这两个触发条件,因此,对于一年中发布新系统或产品的 VASP,仅进行年度测试是不够的。测试必须由合格且独立的第三方审计师实施,并在 VARA 要求时向其提供结果。

VARA 是否要求进行智能合约审计?

是,在相关情况下需要。规则 I.E.1 要求第三方审计师的工作包括,“在与 VASP 业务和 VA Activities 相关的范围内,对所有智能合约的有效性、可执行性和稳健性进行全面审计”,并适用与渗透测试相同的年度和上线前触发条件。Schedule 1 Guidance(Risk Category 2, standard 4)还补充了预期方法:静态和动态代码分析、部署前独立第三方审计,以及在适用情况下进行形式化验证、全面渗透测试,并对已部署合约进行定期重新评估。

季度漏洞评估是否是 VARA 规则?

不是。季度这一频率来自 Schedule 1, Risk Category 2, standard 11.b,VARA 将其作为 Guidance 发布,并表述为 VASP “expected to” 执行的事项。具有约束力的规则是 I.E.2,该规则要求“定期并在 VARA 要求时”对基础设施和应用程序进行安全测试,以及开展内部和外部系统漏洞审计,但未指定具体间隔。季度是合理的默认频率,也是 VARA 已发布的频率,但如果您选择了不同且有正当理由的节奏,并不因此违反某项 Rule。

每个 VASP 都必须执行 TLPT 吗?

不是。规则 I.E.5 规定,在 VARA 认为必要且相称时,可以通知某个 VASP 要求其开展 TLPT,并会考虑该 VASP 已面临或可能面临的任何特定风险、其业务和 VA Activities 的关键性,以及任何其他相关风险。如果没有收到 VARA 的通知,则不存在 TLPT 义务。一旦收到通知,规则 I.E.6 至 I.E.10 即适用,包括仅可使用外部测试人员、可能在生产系统上进行测试,以及范围内第三方服务提供商必须参与。

VARA 渗透测试人员必须持有哪些认证?

对于持续测试义务,规则 I.E.1 仅要求“具备资质且独立的第三方审计师”,并未指定任何认证。对于 TLPT,规则 I.E.7 要求外部测试人员适任且信誉良好;具备必要的技术和组织能力,并在威胁情报和渗透测试方面具有特定专业知识;由认可机构认证或遵守正式行为准则或伦理框架;就其测试风险管理提供独立保证或审计报告;并由专业责任保险适当且充分承保,包括不当行为和疏忽风险。VARA 并未指定 OSCP、CREST 或任何其他具体资质。

VARA 可以要求 VASP 提供哪些测试证据?

规则 I.E.3 要求测试和审计的证据应形成文档,并“在 VARA 提出请求时,立即提供给 VARA 检查”。规则 I.E.1 和 I.E.4 还分别要求,应请求向 VARA 提供第三方评估结果和独立管理流程审计结果。VARA 未规定报告格式、严重性等级或整改时间表。附表 1 指引确实将“对已识别漏洞进行正式整改跟踪”作为安全测试本身的组成部分,因此需要能够提供的是关闭证据,而不仅仅是报告。

主要来源

本文中的每项要求均取自 VARA 已发布的规则手册。在依赖任何具体规则前,请确认当前版本。

最后更新:2026 年 7 月。本文为一般信息,不构成法律意见。请确认当前规则手册文本,并直接咨询 VARA 以获取针对具体实体的指引。

Alexander Sverdlov

Alexander Sverdlov

Venvera 首席执行官兼创始人

Alexander 是 Venvera 的创始人,在欧洲网络安全与合规领域拥有 20 多年经验。他曾为受监管的金融机构、金融科技公司和 SaaS 企业主导安全与风险项目,这些企业需要遵守 DORA、NIS2、GDPR、ISO 27001 和 EU AI Act。创立 Venvera 之前,他创办了进攻性安全咨询公司 Atlant Security,为 EU 和中东地区的客户开展渗透测试、红队演练和 ISO 27001 就绪项目。他的文章聚焦现代合规的跨框架实践:如何把一项控制措施映射到多项义务,电子表格会在哪里失灵,以及审计师真正坐下来之后,监管机构实际要求的是什么。

查看 Alexander 的更多文章 →

相关文章