报告要过的是银行那一关：香港金融科技公司面对交易对手审查时的渗透测试

简短回答：银行要的这份渗透测试报告，并不是写给你看的。读它的人是对方第三方风险团队里的一位分析师——他需要在清单上打一个勾，并且日后能为这个勾辩护。让报告被接受的，是与对方关注点相符的测试范围、明确写出的方法论、可复现的证据，以及带日期的修复与复测记录，而不是发现问题的数量。

为什么一家 28 人的金融科技公司，会被银行要求提交渗透测试报告？

设想一家综合性的、用于说明情况的香港金融科技公司。全公司 28 人，大约一半是工程师。产品是一个面向企业客户的支付与对账平台：企业客户通过 API 把自己的财务系统接进来，平台负责匹配收付款、标记异常、推送结算指令。整门生意都离不开一家合作银行——银行开立客户资金账户、提供支付通道，而且越来越希望用 API 直连，而不是靠上传文件。

商务条款几个月前就谈妥了。随后，开户与接入流程转到了银行的第三方风险团队，然后卡在了一份安全问卷上。大多数问题，技术负责人一个下午就能答完：静态数据是否加密、生产环境访问是否强制多因素认证、密钥怎么保管、谁有权限部署。只有一行完全答不上来。那一行要求提供最近一次由独立第三方执行的渗透测试报告，覆盖本次合作所涉及的系统，且报告日期在过去十二个月之内。

公司从来没有做过渗透测试。融资前曾经用一个免费扫描器扫过官网，云服务商自带的安全面板大部分也是绿色的。可这两样都不是渗透测试，也都不是独立的。销售团队已经向三家企业客户承诺了上线日期，距离现在只剩八周。创始人的第一反应是：找最便宜、能出一份 PDF 的测试。技术负责人的第一反应是：买钱能买到的最彻底的测试。事实证明，这两种直觉都瞄错了读者。

这种情况在香港金融科技圈已经常见到有了固定的形态：团队很小，对方有正式的准入流程，截止日期由别人定，而那份文件要求听起来简单，其实并不简单。本文要讲的，就是这份文件实际上要完成什么任务。

这和为上线、为监管、为保险做测试有什么不同？

同一项服务——渗透测试——回答的问题，取决于谁来读它的结果。如果触发点是你自己的上线日期，测试是为你自己做的：你想在客户发现之前知道哪里会出问题，这个时间规划的问题我们在对着 App 上线日期安排渗透测试一文中讨论过。如果触发点是发牌监管机构，问题就变成：你是否多年持续运行一套有维护的测试计划，这是一家香港支付公司没料到的渗透测试要求一文的视角。保险公司在续保时，通常更想看到持续的安全卫生证据，而不是一次性的深度测试。

交易对手和这三者都不一样。银行不是你的监管机构，无权检查你；也不是你的保险公司，不会把你的风险折算成保费。它是一家正在决定是否把自己的系统和声誉接到你身上的企业，它的风险团队有一条政策：拥有这种访问级别的第三方，必须提供独立的安全测试证据。这份报告就是那份证据。它会被归档，可能会被内部审计抽查，而接受它的那位分析师，个人的名字就记录在这次接受上。这一点改变了报告需要包含的内容。

实际读这份报告的是谁？他在找什么？

想象一下这位读者。银行第三方风险或信息安全部门的一位分析师，同时手上有几十个供应商和合作方尽职调查在跑。他大概率不会复现你的漏洞利用过程，甚至可能根本不会打开技术附录。他读报告时找的是四样东西，通常按这个顺序。

第一，测试是否覆盖了与这次合作相关的系统。如果银行要调用你的 API，而你的报告只测了公司官网，那么无论报告多干净，都与这次审查无关。第二，测试是否由独立方执行、是否采用公认的方法、是否在他们政策要求的时间窗口内。第三，发现了什么、严重到什么程度——特别是有没有被评为严重或高危、至今仍未关闭的问题。第四，你对这些问题做了什么，以及有没有人核实过。

请注意，这张清单上没有的是：发现问题的总数。一份有四十个低危观察项、并且修复记录清楚的报告，比一份只有三个发现、却看不出后续处理情况的报告更容易被接受。一份零发现的报告反而可能引来疑问——有经验的分析师知道，一次真正圈定了范围的线上 Web 应用测试，几乎总会发现点什么；结果一片空白，会让他怀疑到底测了什么。

分析师还得写下点东西。他的内部记录大致会是这样一句话：“合作方提供了日期为 X 的独立渗透测试，范围覆盖 Y，无未关闭的严重或高危问题，修复已于 Z 日核实。”如果你的报告让这句话里的每一个空都很容易填上，审查就会走得很快。如果分析师得回信问你测了哪些范围、某个高危问题修好没有，你就损失了一周——在只剩八周的截止日期面前，一周很重要。

一份让交易对手接受的渗透测试报告，需要具备什么？

去掉排版格式，几乎所有工作都由四个要素完成。缺了其中任何一个，往往就会招来追问；四个都齐全，报告通常就会被直接归档。

范围说明是否与对方关注的内容一致？

范围说明是风险分析师第一页认真读的内容。它应该用对方能认出的方式列出被测系统：银行将要对接的生产 API 端点、面向客户的 Web 应用、承载这些服务的环境的外部边界，以及任何可能触及客户数据的管理界面。它应该说明测试的是哪个环境——生产环境，还是与之一致的预发布环境；如果是后者，要说明为什么它有代表性。

同样重要的是，要写明哪些不在范围内、为什么。“企业内部办公网络不在范围内；与生产环境无网络连通”——只要属实，这是一句完全可以接受的话。读起来糟糕的是沉默，因为沉默逼着分析师去猜，而猜恰恰是他不被允许做的事。

方法论是明确写出来的，还是靠对方去推断？

分析师需要看到，测试遵循的是公认的方法，而不是临场发挥。对于 Web 应用和 API，通常意味着要写明：测试覆盖了 OWASP Top 10 各类别及以上内容；采用的是黑盒（测试人员事先不掌握内部信息）还是白盒（测试人员拿到了文档、账号或代码）；使用了哪些测试账号和角色；以及测试进行的日期和时间段。

黑盒还是白盒，是一个有实际后果的选择。黑盒告诉你一个外部人员能做到什么。白盒加上每个用户角色的认证访问，能告诉你多得多的东西——恰恰是银行真正担心的那件事：你的某个企业客户，能不能通过你的 API 看到甚至挪动另一个客户的钱。对一个多租户支付平台做交易对手审查，对 API 做认证后测试通常是更有用的证据。

一个不在场的人，能复现这些证据吗？

每一个发现都应该附有概念验证证据：发出的请求、收到的响应、必要时附截图，并且细节足够让一位没有在场的合格工程师复现出来。每个发现都应该按公认标准给出风险评分——常用的是 CVSS——再加上一段用普通语言写的业务影响说明，以及分步骤的修复指引。

这对交易对手之所以重要，原因与你的工程师无关。可复现的证据，是区分真实测试与“为了应付问卷而生成的文件”的关键。如果分析师看到的是一串模糊、没有证据的发现，他无从分辨二者，只能按后者来对待这份报告。

有没有带日期的修复与复测记录？

这是小团队最常漏掉的要素，因为它发生在测试人员离场之后。银行想看的报告，不只是最初的发现，而是最初的发现加上一份记录：哪些已经修复、何时修复、并且有独立的人核实过修复。实际操作中，这要么是一份更新版报告，多了一列修复状态；要么是一封单独的复测函，按编号引用原始发现，逐条记录为已关闭、部分关闭或已接受风险。

没有这份记录，分析师看到的就是一份列着你平台漏洞的清单，却没有任何证据表明它们已经消失。从交易对手的角度看，这比完全没做测试还糟糕，因为现在对方的存档里多了一份写明已知弱点的文件。

该测什么？哪些东西交易对手很少要求？

大部分成本和大部分价值都是在划定范围时决定的，所以值得就本文场景中这类平台，把常见的候选范围逐一过一遍。

• 外部网络边界。承载产品的环境中，一切从互联网可达的东西：负载均衡、API 网关、VPN 接入点、暴露在外的管理端口、被遗忘的子域名。几乎总在范围内；一次聚焦的外部测试，是最小的、可信的工作单元。
• Web 应用与 API。面向客户的应用，以及最重要的——银行将要调用、企业客户正在使用的 API。对支付平台来说，这是报告的核心：身份认证、租户之间的授权隔离、输入处理，以及业务逻辑层面的滥用，例如重放或篡改结算指令。
• 云配置。存储权限、身份与访问策略、日志、生产环境与其他一切之间的网络隔离。通常与外部测试一起审查，而不是单独做一次，而且小团队真正的风险敞口往往就在这里。
• 内部网络。假设已被入侵的测试——如果攻击者进入了一台员工笔记本或一台内部服务器，他能横向走多远？对于生产环境完全在云上、办公网络与之不通的金融科技公司，这一项在本次审查中的优先级可能较低；如果办公网络可以直达生产环境，那就不是了。
• 人员。社会工程与钓鱼模拟。有价值，而且越来越多真实事件正是从这里开始的，但审查技术对接的交易对手，很少把它列为准入条件。值得做；但通常不是解开这份问卷卡点的那一项。

实际的原则是：把范围圈定在触及这次合作及其所承载数据的系统上，再加上对方问卷中明确点名的内容。如果问卷写得含糊，就直接问银行的风险对接人，他们希望看到哪些系统被覆盖。一封邮件，就可能省掉一次测错对象后的返工。

为什么最便宜的扫描过不了关，最贵的项目又做过了头？

场景里的创始人和技术负责人，各对了一半。成本确实重要，彻底性也确实重要。但问题不是“测多少”，而是“哪一种测试能产出这位读者需要的证据”。

自动化扫描 vs. 圈定范围的渗透测试 vs. 范围过大的项目

• 自动化漏洞扫描：快、便宜，作为周期性控制措施确实有用。它按特征库检查已知漏洞和错误配置。它测不了你的业务逻辑，判断不了租户 A 能否读取租户 B 的交易，产出的是机器生成的报告，没有人对可利用性做出判断。大多数要求渗透测试的交易对手风险团队不会接受用扫描代替，而交上一份扫描报告，往往会让你在后续审查中失去信誉。
• 圈定范围的渗透测试：由人来执行，范围与这次合作相匹配，方法论明确写出，对扫描器标记出来的和它看不到的问题都进行人工利用，发现带 CVSS 评分和概念验证证据，并包含修复与复测环节。这才是问卷真正在要的东西，对这种规模的平台来说，通常能在时间线内完成。
• 范围过大的项目：完整的红队演练、大规模社会工程、物理入侵、每一个内部网段。其中一些本身很有价值。但对这位特定读者来说，大部分都是噪音——分析师会直接翻到 API 和外部边界的章节——而多出来的范围会把日程拖过截止日期，把预算推到一家 28 人公司不该为一份文件花的程度。

圈定范围的测试，不是另外两者之间的折中。它是唯一一个瞄准了读者的选项。

应该如何从截止日期倒推时间线？

从银行需要最终文件的那一天往回倒推，而不是从你希望测试开始的那一天往前排。对于本文场景，距离截止还有八周，计划大致如下。

第一周用于划定范围和签约：与银行确认他们希望覆盖哪些系统，与服务商商定范围和测试窗口，为每个角色准备测试账号，并确保生产环境的负责人知道测试何时进行。标准渗透测试的设计原则是不干扰业务运行，需要时可以把测试窗口安排在非办公时间，但测试进行期间，你这边仍然得有人能随时联系上。

测试本身的时长取决于范围。大致来说，一次聚焦的外部网络测试通常需要三到五天；外部、内部加 Web 应用的完整项目通常需要两到三周。服务商应当在提案阶段就给出时间与范围估算；没有这一项的提案，不要签。

接下来是所有人都低估的部分：修复。你的工程师需要实实在在的时间去修复发现的问题、测试修复效果、再部署上线。如果测试在第四周结束，而银行在第八周要文件，那么在复测之前，你大概只有两到三周的修复时间。修几个严重问题够用；如果发现的是 API 中结构性的授权问题，就不够了。这正是接下来两节之所以重要的原因。

为什么复测是小团队最容易忘记谈的那一部分？

几乎每一个第一次采购的人，都把注意力放在测试本身，把复测当作细节。可在交易对手看来，恰恰是复测把一份问题清单变成了“风险可控”的证据。

签约之前，要弄清三件事：复测是否包含在内，条件是什么？初次报告出具后，最晚多久可以安排复测？复测产出的是什么——一份修订版报告，还是一封引用原始发现编号的独立函件？

作为参考，Brocent 的年度测试套餐包含在初次发现修复之后的一次复测，用以确认漏洞已被关闭、且没有引入新的问题。如果你向任何一家服务商购买的是一次性项目，不要默认复测包含在内。去问，拿到书面答复；如果不含，就在测试开始之前把它谈进工作说明书——此时谈远比在发现结果出来、截止日期只剩两周时再谈要容易得多。

还要约定由谁来做复测。由你自己的工程师做的复测，不是独立证据。由执行原始测试的同一家服务商、对照它自己的发现编号来核查，形成的记录最干净。

截止日期前修不完的发现，该怎么办？

有时候，诚实的答案是：某个问题没法在期限内彻底修好。一个深层的授权问题，可能需要重新设计数据模型里租户之间的隔离方式；一个过时的组件，可能绑定在一次你无法控制的供应商升级上。这时的诱惑是希望分析师看不出来。他会看出来的，而由此造成的信任损失，会比那个问题本身更大。

行得通的做法由三件事组成。第一，一项能立刻降低风险的补偿性控制——把受影响的端点限制为只接受银行的 IP 段、在网关上增加一道授权检查、在重建完成前暂时关闭某项功能，或者针对攻击者必须采取的那种特定行为加强监控。第二，复测应当核实这项补偿性控制，并把该发现记录为“已缓解”而不是“已关闭”。第三，一份带日期的修复计划：要做什么、由谁做、何时完成、如何提供证据——最好再承诺在完成后分享一次进一步的复测结果。

风险团队对此早已习惯。他们不能接受的，是一个没有计划的未关闭严重问题，或者一份没有日期的计划。一个已缓解、有监控、定好六周内修复、并且有具体负责人的高危问题，在合作方的审查记录里是很正常的。

这份报告能拿给下一个交易对手用吗？

在本文场景中，银行是第一个提出要求的交易对手，但不会是最后一个。企业客户、第二家合作银行、某个支付网络、潜在投资人，都可能在一年之内问同样的问题。最好从一开始就为此做好准备。

完整的技术报告是敏感文件——说到底，它是一张“你的平台是怎样被攻击的”地图。大多数服务商和大多数交易对手都预期它只在保密协议下分享，有些项目条款还会限制向其他方转发。在把报告发给任何人之前，先查一下你和测试服务商之间的合同。一种常见且合理的做法是维护两份文件：完整报告，只发给真正需要技术细节的一方；以及一份由服务商出具的执行摘要或证明函，写明范围、日期、方法论和修复状态，但不含漏洞利用细节。很多审查方会接受摘要，只有当其中某一点引起疑问时，才会索要完整报告。

复用也有时效。一份在三月份被接受的报告，到了第二年二月未必还能被接受——如果你的平台在此期间上线了重大变更，或者下一个交易对手的政策要求六个月内而不是十二个月内的测试。把被测平台的日期和版本记录下来，等这个问题来了，你才答得上。

如何把一次性测试变成年度循环？

第一次测试几乎总是在压力下买的。第二次不应该这样。一旦你知道某个交易对手关系要求独立测试，你就知道明年它还会要求，而且很可能每次你对接口做了重大变更时也会要求。

年度循环有一个可预期的节奏：每年在同一时间点商定范围、测试、修复、复测，把更新后的报告和摘要归档，再向需要的人通报。它也会改变经济账。每年测试同一个平台的服务商，会逐渐熟悉它的架构，花在摸底上的时间更少，花在变化部分上的时间更多。你的工程师会知道哪几类问题反复出现，并从源头修掉。而交易对手每年收到的报告，会从一张快照变成一条趋势线——这正是风险分析师真正想看到的。

也正是在这个节点上，包含修复后复测的年度套餐，会比每次从头谈一个项目更划算。Brocent 的渗透测试服务覆盖外部网络、内部网络（假设已被入侵后的横向移动）、针对 OWASP Top 10 及以上内容的 Web 应用测试，以及社会工程与钓鱼模拟，并提供黑盒与白盒两种方式；每一个发现都附有 CVSS 风险评分、概念验证证据、业务影响说明和分步骤的修复指引。

但年度测试说到底仍是某一时点的一张照片。决定明年那张照片好不好看的，是另外五十一周里发生了什么。

常见问题

漏洞扫描和渗透测试有什么区别？

漏洞扫描是对已知漏洞和错误配置的自动化检查。渗透测试是由人主导的、尝试利用弱点的过程，包括扫描器看不到的业务逻辑缺陷，并提供实际可以做到什么的证据。扫描是很好的周期性控制措施；但一个要求渗透测试报告的交易对手，通常不会接受用扫描代替。

一次渗透测试需要多长时间？

取决于范围。一次聚焦的外部网络测试通常需要三到五天；外部、内部加 Web 应用的完整项目通常需要两到三周。在此之前要留出划定范围的时间，在此之后要留出修复和复测的时间；要从交易对手的截止日期往回倒推，而不是从今天往后排。

报告会是英文的吗？

把报告语言明确写进工作说明书，而不是想当然。如果交易对手的风险团队以英文工作，报告就应该从一开始用英文撰写；事后翻译的报告，可能恰好在分析师读得最仔细的地方——范围、严重程度、修复状态——引入歧义。

复测是否包含在内？

取决于你买的是什么。Brocent 的年度测试套餐包含在初次发现修复之后的一次复测。对于任何一次性项目，无论向哪家服务商购买，都要在测试开始之前书面确认是否包含复测、条件是什么；如果不含，就把它谈进去。

报告能分享给不止一个交易对手吗？

通常可以，但需要在保密条款下进行，并且要先查看你与测试服务商之间的合同。实际做法是：执行摘要或证明函可以较广泛地分享，完整技术报告只给需要细节的一方。记录好谁收到了哪个版本。

如果发现了严重问题怎么办？

能修的先修，通过复测核实修复效果；对于来不及修的，部署补偿性控制，并写下一份带日期、有具体负责人的修复计划。如实披露。一个已缓解、已排期的问题，在合作方的审查记录里很正常；一个被隐瞒的问题则不是。

多久应该重新测试一次？

只要该交易对手关系仍要求独立测试，至少每年一次；此外，在范围内系统发生重大变更之后也要测试——新的 API 版本、新的部署环境、重大的身份认证调整。也要核对交易对手自己的政策，有些要求的间隔短于十二个月。

报告由谁签署？

由测试服务商签署，而不是你。报告应当写明服务商、测试日期、报告版本以及测试负责人；任何证明函或复测确认，也应当由服务商以自己的名义出具。自己签署的文件不是独立证据——而独立，正是对方提出这项要求的全部意义所在。

让明年的报告保持干净的工作，究竟在哪里完成？

回到本文的场景。这家金融科技公司拿到了报告，修掉了大部分发现，缓解了其余的，银行完成了对接。十二个月后，同样的问题又来了。第二份报告是轻松还是痛苦，几乎完全取决于这中间发生了什么——而其中与渗透测试有关的部分少之又少。

第一次测试里的大多数发现并不稀奇：一个没打补丁的组件，一条管理路径上没有强制的多因素认证，一个权限比预期宽的存储桶，一项偏离了基线的配置，一个没人盯着的已知漏洞。这些都不需要一年一次的测试来发现，它们需要的是每周都有人盯着。

这种周期性的安全卫生，正是管理型IT外包服务存在的意义。Brocent 按用户计费的管理型IT外包服务方案建立在五大支柱之上——7×24 小时 NOC 监控、多语种服务台、安全治理、备份与灾难恢复，以及 vCIO——每个方案都包含 BCS Beam 终端代理：一项只读的安全与健康审计，按 CIS 对齐的基准检查设备，依据 CVE、CVSS、EPSS 以及 CISA 已知被利用漏洞清单对漏洞进行优先级排序和持续关注，并跟踪补丁状态。需要更多保障的企业，可以通过管理型安全服务把这套能力延伸到专门的检测与响应。Brocent 2007 年创立于北京，2016 年起设立香港办公室，2021 年起总部设在新加坡；我们的金融服务客户，经常要面对这类交易对手审查。

香港地区的方案价格按每用户每月公开：Startup（1–5 名员工）HK$855.14，Established（5–300 名）HK$1,247.40，Growth（10–500 名）HK$1,561.21，Enterprise 按需报价。一支 28 人的团队选择 Established 档，按公开价格计算为每月 HK$34,927.20——换来的是让下一份报告变短的那些日常工作。完整明细请见价格页面，或者联系我们，一起为今年的测试划定范围，并谈谈怎样让明年的测试更轻松。

测试是一张照片。而方案，决定了没人拍照的时候，你是什么样子。