新加坡一家金融科技公司的网络保险续保，为何卡在一次漏洞扫描上

一家新加坡支付公司的网络保险续保，卡在了经纪人问的一个问题上——办公室里没人能当场答上来："你们上一次做漏洞扫描是什么时候，扫出了什么？" 没有扫描报告，就没有原价续保——直到他们真的做了一次。

网络保险开始向金融科技公司问一个不一样的问题

对一家新加坡持牌的金融科技或支付公司来说，网络保险过去几乎只是走个流程：填一份投保单，勾选"我们有防病毒软件、有做数据备份"，交保费，结束。但对于经手客户资金、支付凭证或账户数据的持牌金融业务而言，这套流程已经变了。

如今为金融科技和支付类公司承保网络险的保险公司，问的是"拿证据来"，而不是"打个勾就行"。"你们有没有防火墙"变成了"把你们最近一次的漏洞扫描报告给我们看看"。"你们有没有装防病毒软件"变成了"说说你们的补丁更新节奏"。这个转变背后的逻辑很简单：承保方的理赔数据显示，未修补的已知漏洞仍然是攻击者最常见的入侵方式，保险公司宁愿基于真实证据来定价（或拒保）这类风险，也不愿只凭企业自己的一面之词。

对新加坡持牌的支付或金融科技公司而言，这又叠加了另一重早已存在的压力：新加坡金融管理局（MAS）的科技风险管理指引要求受监管机构主动管理科技风险，其中就包括将定期漏洞评估作为整体安全态势的一部分。一家日常安全习惯已经不错的公司——有防火墙、终端防护、多因素认证、相对有纪律的补丁流程——仍然可能在保险公司面前拿不出任何东西，因为这些日常防护措施本身并不会产生"文档"。而漏洞扫描恰恰会。它是少数几种"整个产出就是一份带日期、可读的证据文件"的安全实践之一，而这份文件，恰好精准地回答了承保人正在问的问题。

新加坡作为亚洲领先的金融科技和支付枢纽之一，这个问题对数量庞大且仍在增长的 MAS 持牌支付机构、电子货币发行商及相关金融科技公司来说，是一个正在发生的现实。这类公司的核心业务往往就是资金的转移或托管——而这恰恰是承保人视为高风险、因此需要更多而非更少证据的业务类型。市场收紧后第一次续保网络险的公司，常常会发现证据门槛在自己没被明确告知的情况下已经提高了——经纪人只是开始索要去年这个时候根本不在对话范围内的文件。

具体情境：日常习惯不错，但没有持续、有记录的做法

想象一家新加坡持牌的支付或金融科技公司，员工在 40 到 80 人之间——工程、运营、合规、客服，再加一个小型财务团队。从日常层面看，这家公司的 IT 安全状况相当不错：笔记本电脑统一管理并加密，办公网络和云端边界都有防火墙，全员部署了终端防护，邮箱和核心支付/银行平台都强制启用了多因素认证，补丁也大体上会打上——只是取决于 IT 团队什么时候顾得上。

这家公司缺的是一套持续、有记录的漏洞扫描机制——一个按计划系统性检查外部暴露系统、内部服务器和网络应用中已知弱点的流程，并且每个周期结束都要留下一份带日期的报告。也许一年半前为了配合某个客户的尽职调查问卷，做过一次一次性渗透测试。也许某位已经离职的 IT 同事曾经跑过一次开源扫描工具，之后再没人看过那份结果。不管是哪种情况，当合规负责人去找"我们目前的漏洞状况"交给保险经纪人时，手头没有任何一份近三个月内、能对得上公司目前系统的报告，也没人能说清楚上一次扫描到底发现了什么、有没有修复。

这是一个相当普遍的缺口，并不代表这家公司粗心大意——恰恰相反，这是一家成长中的公司投入资源去阻止日常事故（防火墙、终端防护、多因素认证）之后，却从未指派专人去负责另一件独立的、持续性的工作：按计划检查这些防护措施是否存在已知弱点，并把结果记录下来。

这个缺口还会随着公司成长而悄悄扩大。一家只有一个办公室、一套云环境的 40 人金融科技公司，还比较容易在脑子里画出全景图；但一家 80 人、有混合远程工程团队、十八个月里陆续接入了好几个 SaaS 服务、有对外开放的支付 API、外加几台没人来得及下线的旧服务器的公司，就很难做到了。每新增一个系统集成、每上线一个云服务、每入职一名员工的笔记本电脑，都在悄悄扩大攻击者——或者保险公司问卷——眼中的"覆盖范围"。如果没有一套能自动覆盖当前所有在用系统的持续扫描机制，"没人检查过的东西"这份清单就会随着业务一起、悄无声息地变长，直到续保对话把所有人一次性推到必须正视它的地步。

答不上这个问题会带来什么后果

最直接、最看得见的问题就是续保本身。经纪人从保险公司那边带回一个要求：提供一份近期的漏洞扫描或评估报告，而公司手上却没有一份既够新、又够完整的材料可以交出去。接下来通常会发生以下几种情况，没有一种是好事：续保报价大幅上涨，把这部分未知风险计入保费；保单虽然续了，但针对"未修补漏洞导致的事故"附加了除外条款或分项限额；又或者承保人要求在固定期限内（往往是 30 天）完成一次扫描，作为承保生效的前提条件——一件本该提前规划的事，硬生生变成了消防式抢工。

在这个直接问题之下，还有三个几乎每次一深挖就会浮出水面的问题：

• 没人负责回答"我们上一次检查是什么时候"。 防火墙、终端检测响应（EDR）、多因素认证这类安全工具，通常都有明确的负责人，因为总要有人去采购和配置它们。但漏洞扫描往往没有，因为它是一项持续性的*活动*，而不是一次性的采购——而没有专人负责的持续性活动，会在无人察觉的情况下悄悄停摆。
• 把一次性渗透测试和持续性扫描混为一谈。 这两者在日常对话里常被当作同一回事来用，但它们回答的其实是不同的问题。渗透测试是一次时点性的、由人工主导的演练，用来证明一个熟练的攻击者真正能对某个特定目标造成多大破坏——很有价值，但它只是某个特定日期的一张快照。漏洞扫描则更全面、可重复、以自动化为主，针对已知弱点做持续检查，本应按计划运行。当保险公司问"你们目前的漏洞状况如何"，他们想要的是后者；无论那份十八个月前的渗透测试报告做得多好，都答不上这个问题。
• 没有整改闭环，扫出来的问题（如果有的话）就没了下文。 就算做过扫描，如果发现的问题清单只是躺在某个人的邮箱里、没有被跟踪落实，公司实际上是花钱把自己的风险敞口记录了下来，却并没有真正降低风险——这甚至可能比压根没扫描更被动，因为一个"已发现却未修复"的问题，反而更容易被保险公司或审计方追问"这个问题为什么还没关闭"。

Brocent 的看法：保险公司问的是一个具体、可回答的问题

对处在这种境地的公司来说，真正有用的重新框定是这样的：保险公司要的不是一套完美无缺的安全体系。他们问的是一个具体、范围明确、可以回答的问题——你能不能拿出当前的证据，证明自己主动在检查系统中的已知弱点，并且对发现的问题采取了行动？这比"证明自己绝对不会被黑"要小得多，对应的解决方案也同样具体、可实现：建立一套持续性的漏洞扫描机制，产出一份保险公司、审计方或客户尽职调查团队真正能读懂、能据此行动的报告。

真正靠谱的做法，不是在续保前一周临时抱佛脚。在保单到期前两周仓促委托的一次性扫描，技术上确实能产出一份文件——但这份文件同时也带着一个明显的时间戳，写着"我们是因为保险公司要求才开始做这件事的"，这在下一次续保时的分量，远不如一份已经是第四份、第五份、持续系列中的最新一份报告。更稳固、长期成本更低的做法，是把漏洞扫描当作公司已经在做的补丁管理或备份一样对待：一项长期、有专人负责的常规运营，而不是一次性的合规采购。

这也正是本文前面提到的"打勾 vs 拿证据"这个区分，会反过来对公司有利的地方。一家能拿出上个月的、带 CVSS 评分的扫描报告，再附一份简短说明"发现了什么、修复了什么"的公司，是在用日常运营纪律、而不是临时抱佛脚的姿态，直接回答保险公司真正想问的问题。这种差异，审阅材料的承保人是看得出来的——它决定了续保是顺利过关，还是被重新定价或拖延。

一套真正靠谱的漏洞扫描机制应该包含什么

一套真正能经得起保险公司、审计方，乃至 MAS 科技风险管理要求检验的漏洞扫描机制，需要几个具体、不可省略的组成部分。有必要讲清楚这些具体是什么，因为"我们有做扫描"这句话的含义可以千差万别——从一套真正严谨的项目，到一份从没人看过的自动化工具报告，都可以被这么描述。

• 基于已知 CVE 的匹配检测，并按真实可利用性排序。 一份只是罗列出所有理论上可能存在的漏洞的扫描报告并没有用——大多数公司面对成百上千条发现，根本无从判断哪些真正要紧。有用的扫描会把发现的软件和配置与已知的 CVE 数据库进行匹配，再用 CVSS 严重程度评分、EPSS（估算真实世界中被利用的可能性）、以及 CISA 已知被利用漏洞（KEV）名单等信号进行排序——这样一来，本月正在被实际利用的那五个问题会被排在报告最前面，而不是淹没在两百个纯理论性的条目当中。
• 持续性节奏——按月或按季，而不是按年。 漏洞扫描是对一个不断变化的目标拍下的一张快照：新的 CVE 每天都在被公开披露，一月份还很干净的系统，到三月份可能就出现了一个新披露、且正在被主动利用的弱点。按月或按季扫描（Brocent 的托管扫描方案是持续、常态化运行，而非单次时点检查）才能让这份"画面"始终保持最新，而不是等有人翻出来看的时候早已过时。
• 一份用大白话写、精确到每台设备或每项资产风险评分的报告。 扫描工具直接导出的原始数据，对经纪人、审计方，或者非技术出身的合规负责人来说，根本无从下手。一份真正值得交给保险公司的报告，应该包含人工撰写的执行摘要、按 CVSS 评分排序、并对应到具体资产的发现清单，以及足够的背景说明，让 IT 团队以外的人也能看懂发现了什么、严重程度如何。
• 一个整改闭环，而不是一份躺在邮箱里的报告。 扫描的意义在于修复问题，而不是记录问题。一套值得投入的机制，应该包含从"发现问题"到"确认修复"的可追踪路径——理想情况下还要有一次复扫来验证修复确实生效——这样公司才能诚实地说，不只是"我们做扫描"，而是"我们做扫描，而且我们会把发现的问题关闭"。

三种应对方式的对比

• 没有持续扫描（"等审计前再检查一下"）： 安全防护措施都在，但漏洞检查是被动触发的——通常是因为客户问卷、审计，或者保险续保逼到眼前才不得不做。任何时候手头都没有一份带日期的最新报告，临时压力下赶出来的东西也只是孤立一次性的，背后没有连续的历史记录。
• 每年一次的一次性渗透测试： 确实是一项有价值的演练，但它只是某个特定日期的一张快照，通过针对特定范围的人工测试完成，回答的是"在这一天，一个熟练的攻击者能对这个系统做到什么"，而不是"我们目前所有系统里存在哪些已知弱点"。十二个月后，到下一次续保时，这份报告对于一个期待近期证据的问题来说，已经是陈旧证据了。
• 按月出报告的持续漏洞扫描（Brocent 模式）： 一套持续、托管的扫描机制——根据范围涵盖外部、内部、认证态以及网络应用扫描——按计划运行，每个周期都产出一份带日期、按 CVSS 优先级排序的报告，配合可追踪的整改路径和复扫确认。这种模式能在保险公司或审计方每一次提出问题时，都用最新证据来回答，而不是只在某人恰好想起来跑一次工具的那一次。

这如何融入更完整的安全体系

漏洞扫描并不能替代公司安全体系的其余部分——它的作用是告诉你，安全体系的其余部分是不是真的在按预期发挥作用。Brocent 的漏洞扫描服务，作为新加坡托管 IT 服务方案"增值服务"板块中的一项独立可加购服务，按公司所拥有的资产数量确定规模，既可以按一次性评估交付，也可以作为持续托管服务、进行常态化扫描并定期出具报告。

对新加坡的金融科技或支付公司来说，这项服务通常会与另外两块内容配合使用：一是托管 IT 安全服务，负责日常监控、补丁管理和终端防护——这些正是一份扫描报告在检验其有效性的对象；二是 Brocent 更广泛的网络安全业务，涵盖围绕整个漏洞管理项目的风险评估、安全意识培训和事件响应规划，而不是替代它。这些服务都不是强制打包销售——公司可以只单独加购漏洞扫描，叠加在现有的 IT 支持安排之上，也可以与更完整的安全服务体系组合使用。扫描服务及其他所有增值服务的当前按团队规模定价，都公布在 Brocent 的价格页面上。正在为续保时间表做准备、或者只是想先了解按自身规模一套扫描项目大致要花多少、包含哪些内容的公司，可以通过联系页面直接与 Brocent 取得联系。

常见问题

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

漏洞扫描是自动化、覆盖面广、可重复执行的——它按计划对一组确定的系统进行系统性检查，比对已知漏洞数据库并报告发现结果。渗透测试则是人工主导、时点性的演练，测试人员会主动尝试利用弱点，以证明针对特定目标的真实影响。扫描回答的是"我们目前所有系统里存在哪些已知弱点"，渗透测试回答的是"在这一天，一个熟练的攻击者能对这个特定系统做到什么"。大多数两者都需要的公司，会持续做扫描，同时定期（通常每年一次，或系统发生重大变化时）做渗透测试。

扫描到底应该多久做一次？

按月或按季，而不是按年——如果公司希望保险公司、审计方或客户来问的时候，结果依然是新鲜的。新的漏洞每天都在被披露，所以一年一次的扫描，在它本应覆盖的这一年里，大部分时间都已经过时了。Brocent 的托管扫描方案是持续运行，而不是单次检查，就是为了让存档的报告始终保持最新。

一份扫描报告能满足保险公司的要求吗，还是他们想要更多东西？

这取决于保险公司和保单规模，但一份带日期、按 CVSS 评分的漏洞扫描报告——说明检查了什么、发现了什么、修复了什么——正是大多数网络保险承保人在要求提供"主动漏洞管理证明"时想要的证据。规模更大的保单或风险等级更高的公司，有时还会要求在持续扫描之外，定期配合一次渗透测试；两者是互补关系，不是相互替代。

扫描具体会检查哪些内容？

范围取决于扫描对象，但一次规范执行的评估通常会覆盖对外暴露的系统（攻击者从公开互联网上能触及的部分）、内部网络和服务器基础设施，在相关的情况下，还会包括认证态检查，以及针对 OWASP Top 10 常见网络应用漏洞类别的网络应用/API 扫描。云环境——比如 Microsoft 365、Azure、AWS 的配置——也可以纳入扫描范围，因为配置错误正是运行云端基础设施的金融科技公司最常见的暴露来源之一。

扫描发现的问题由谁来修复？

扫描本身只负责发现和排序问题——修复是另外一个环节。根据合作方式的不同，可以由公司自己的 IT 团队来处理发现清单，也可以作为托管服务的一部分，由外部团队跟踪修复进度直至确认解决，并通过复扫加以验证。不管哪种方式，重要的是要有一条从"发现问题"到"确认修复"的、可留痕的路径，而不是一份发出去一次、再没人过问的清单。

按我们这个规模，这大概要花多少钱？

价格会随扫描范围内的资产数量而变化，也取决于是一次性评估还是持续托管服务——一家 40 到 80 人规模的精简型金融科技公司，做外部加内部扫描的报价，和一家跨多个站点的大型企业级项目，是完全不同的量级。Brocent 的价格页面公布了当前各档次的定价及包含内容；想拿到一个准确的数字，最直接的办法是通过联系页面提供资产数量和合规目标，获取当期报价。

这会取代我们已经有的防火墙、多因素认证、终端防护这些安全措施吗？

不会，也不是为此而设计的。漏洞扫描检查的是这些防护措施是否配置正确、其背后的系统是否存在已知的、未修补的弱点——它是一层验证机制，而不是防护措施本身的替代品。一家日常安全习惯扎实、但没有持续扫描的公司，起点确实比两者都没有的公司要好，但它依然缺少那一份关键的证据文件——一份带日期、有证据支撑的报告——而这恰恰是保险公司、审计方或客户尽职调查问卷真正想看到的东西。

我们保单周期还没到续保，现在开始有意义吗？

有，而且可以说这正是比较理想的开始时机。在保单周期中段就启动持续扫描机制，意味着到下一次续保对话发生时，公司手头已经积累了好几个月带日期的报告，而不是保单到期前两周才临时委托的一份孤立报告。这也意味着，首次扫描发现的问题——对第一次做扫描的公司来说，通常数量会比较多——早在保险公司或审计方可能要求查看证据之前，就已经在被处理和关闭。

结语

保险公司要求提供当前的漏洞扫描证据，问的不是一道刁钻的题目，也不是要求公司变成一家安全成熟度截然不同的企业。他们要的是一项具体、持续、定义清晰的实践——基于 CVE 匹配的扫描、按计划运行、用通俗语言出具报告、再配合可追踪的修复——而 Brocent 在新加坡的很多金融科技和支付类客户，在保险公司、审计方或客户问卷直接问到之前，都还没有建立起这套机制。把它建成一项长期的常规运营，而不是续保前的临时抱佛脚，才能让"等审计前再检查一下"变成一个公司每次被问到都能自信作答的问题。