漏洞管理即服务：买什么，如何评估服务商

设想一个假设场景。一家中型电商平台在一次令人信服的演示之后，签下了漏洞管理即服务合同：门户界面整洁，严重性图表清晰，还能对接工单系统。三个月后，情况变了样。开发人员每周收到一份数百行的导出清单，其中相当一部分是同一问题在不同主机上的重复条目。技术总监问公司是否更安全了，却没人答得上来，因为门户展示的是发现数量，而不是风险变化。半年前为合作伙伴临时搭建的测试子域名始终没有纳入监控，因为没人把它接入。还有一个"已关闭"的严重漏洞其实从未修复：管理员只是封禁了扫描器的 IP 地址，复扫结果便显示"未检出"。

这是虚构的故事，并非真实客户案例。但其中每个情节都源于合同签署前做出或没有做出的决定：范围包括什么，谁负责接入新资产，如何区分已确认的发现和扫描噪声，什么才算修复的证据，以及最终由谁接受风险。

漏洞管理即服务（vulnerability management as a service，VMaaS）包含不同的合同模式。本文采用的目标模式是：外部服务商负责循环中的约定部分，包括发现并确认弱点、确定优先级、协助修复，或在合同委托时执行修复，以及复测修复结果。下面我们讨论这个循环由哪些环节组成，如何用开放标准的语言描述它，如何区分真正的流程和仪表盘订阅，以及如何设计一次试点，在你自己的系统上看出差别。

VMaaS 名义下实际买到的是什么

同一块招牌下卖的东西差别很大：从附带月度 PDF 的云扫描器订阅，到由服务商维护资产清单、人工确认发现并复测修复的服务。名称本身不保证任何事情，因此更有用的做法是按结果而不是按工具来定义服务。

平台与流程

访问平台，意味着能够查看数据。流程则为数据确认、覆盖缺口识别和结果处置指定负责人及检查步骤；它不会自动保证数据正确或完整。如果新资产进不了平台，发现无人确认，"已修复"状态因为信号消失就被打上，客户得到的只是一幅不完整图景的漂亮可视化。演示时该问的不是"门户能做什么"，而是"门户上显示的每项操作由谁负责、在多长时间内完成"。

必须闭合的循环

NIST SP 800-115《信息安全测试与评估技术指南》的目标，是帮助组织规划和实施技术测试、分析结果并制定风险缓解策略。在形式上，该出版物把评估分为三个阶段：规划、执行和执行后，最后一个阶段包括分析、报告和缓解建议。它还说明自己并不是一套完整的测试计划。托管服务把这一次性流程变成反复运行的循环，这是编辑上的引申，而不是该文件的要求。只转发扫描器原始输出的服务，只覆盖了多个环节中的一个。

1. 资产接入资产已登记在清单中，有内部负责人、书面授权和清晰的测试边界。
2. 发现扫描提供覆盖广度，人工测试在业务逻辑和访问权限等关键处提供深度。
3. 研判与定级发现已确认、重复项已去除，优先级综合考虑严重性、利用数据和资产角色。
4. 修复负责人消除根因，反复出现的弱点类别被反馈到开发流程中。
5. 复测在约定条件下重复同一场景，并记录结果及其局限。

NIST 网络安全框架 2.0 的视角更宽：其目标是帮助组织理解网络风险并更好地管理风险。从这个角度看，VMaaS 是风险管理的一部分，而不是定期报告。好的服务能说明哪些资产受到影响、哪些弱点重要、哪些修复已逾期，以及受攻击面是否有所缩小。

资产接入与范围：服务在哪里与现实脱节

服务商不可能测试它不知道的东西。所以首先要讨论的不是扫描器，而是资产接入流程。谁把新服务、域名或云账号登记进清单？团队上线新 API 或迁移到另一个云区域时，服务商如何得知？服务商自己发现、但合同中没有的资产怎么处理：直接开始测试，还是先与客户确认？这些答案决定了半年后服务的范围是否仍与真实攻击面一致。

区分两种范围很有帮助。合同范围是服务商有权测试的对象。实际攻击面是攻击者能触及的一切，包括被遗忘的子域名、测试环境和承包商的服务。定期侦察外部边界可以缩小这一差距，但不能保证资产清单完整；如何开展这种侦察以及如何为此类发现排序，我们在外部攻击面评估一文中有详细介绍。但发现未知资产只是做出决定的理由，而不是自动获得的测试许可。

客户必须确认自己有权授权测试每一项资产。对托管在云服务商和 SaaS 服务商处的组件尤其如此：许多服务商有自己的测试规则，某些类型的测试需要征得其同意。每个接入的资产都需要一位内部负责人，由其接收发现、决定如何处理并对期限负责。

谁负责什么：角色与服务水平协议

外包转移的是工作，而不是责任。CSF 2.0 的前提是组织自行管理自身的网络风险：接受风险、推迟修复或下线系统的决定始终由客户做出，即便发现和测试由承包商负责。这一点值得明确写进合同，否则就会出现一个对双方都方便的灰色地带：发现已经"移交"，却无人接手。

服务水平协议（SLA）也是同样的逻辑。VMaaS 没有一个通用修复期限：适用合同、法规或项目规则可能规定期限，内部目标还取决于资产暴露程度、利用数据和团队能力。SLA 应说明服务商承担的责任：从发现到确认和定级的时间、对复测请求的响应、出现主动利用迹象时的紧急通知，以及合同委托时由服务商执行的修复。其他修复动作和风险接受仍由指定的客户负责人承担。

下面比较几种常见的选择模式。这不是排名：每种模式都有适用条件，而且经常组合使用。

标准是描述范围的语言，而不是徽章

在 VMaaS 中，开放标准的价值不在于质量标志，而在于让范围和结果可以比较。每个来源各有其角色，混淆它们是合同含糊不清的常见原因。

OWASP Top 10 是关于最关键 Web 应用安全风险的意识文件。2025 版仍是报告中方便的通用词汇，但它不是测试规范。"我们覆盖 OWASP Top 10"这句话只是列出了风险类别，对测试深度只字未提。

OWASP ASVS（应用安全验证标准）填补了这一空白。该项目明确以统一市场上 Web 应用验证在覆盖范围和严格程度上的差异为目标。在 5.0.0 版中，每条要求都有数字编号；由于编号可能随版本变化，项目建议引用时注明版本，例如 v5.0.0-1.2.5。要求清单以 CSV、JSON 等机器可读格式发布。这意味着可以用一组具体要求来定义范围，导入自己的跟踪系统，并逐季度把发现映射到相同编号上。

OWASP WSTG（4.2 版）说明如何在实践中测试 Web 应用。SP 800-115 补充了项目层面：如何设计并持续运行技术测试流程。MITRE CWE 对弱点进行分类，即把零散发现归入类别的根本原因。

一个重要的提醒：ASVS 和 WSTG 覆盖 Web 应用与 API，本身并不定义全部基础设施范围。把发现映射到 ASVS 要求或 CWE 类别只是一种描述方式，并不能证明合规。渗透测试可以为特定适用要求在已记录条件下提供证据，但报告中每一行都带有编号，并不意味着该要求已被完整测试，也不意味着应用符合整个标准。渗透测试和托管服务本身都不是认证、鉴证或合规意见。

优先级排序：几个不同的问题，而不是一个分数

主要的运营难题是数量：无论团队还是服务商，都无法对每条记录给予同等关注，服务的价值很大程度上在于如何把清单缩小到对你的环境真正重要的部分。但不同指标回答的是不同问题，把一切压缩成一个数字的服务会丢失信息。

CVSS、EPSS、KEV 与资产暴露

CVSS 评分描述漏洞的技术严重性，即被利用后后果可能有多严重。EPSS 是 FIRST 推出的漏洞利用预测评分系统，估计漏洞在未来 30 天内被利用的概率；它不衡量对特定组织的业务影响。CISA 已知被利用漏洞目录（KEV）回答第三个问题：是否有在真实攻击中被利用的证据。它是很有价值的输入信号，但漏洞不在 KEV 中并不意味着安全，而为美国联邦机构规定的修复期限也不是普遍适用的法律要求。

第四个问题只有客户知道，服务商只有在获得背景信息后才能知道：攻击者能否轻易触及该资产，以及资产上存放着什么。一个假设的例子：外部登录服务中一个列入 KEV 的中危漏洞，可能比内部测试环境中一个既无敏感数据、也无互联网路由的"严重"漏洞更需要紧急处理。这是在说明思路，而不是规则。成熟的服务会解释是哪些因素决定了优先级，并允许客户对结论提出异议。不存在诸如"EPSS 高于某个值就一律紧急"的通用阈值：阈值由组织自行选择，服务商应说明其默认设置背后的假设。更多内容请参阅我们关于基于风险的漏洞优先级排序的分析。

从单个发现到根本原因

优先级排序的第二个层次是弱点类别。2025 版 MITRE CWE Top 25 列出了危险弱点，它们往往容易被发现和利用，可能导致系统被接管、数据被窃取或应用中断。与之配套发布的还有 CWE Top 10 KEV Weaknesses（依据 KEV 目录数据对弱点排序）以及"On the Cusp"清单（列出差一点进入主榜单的弱点）。

关键不在于对照排名，而在于形成反馈。MITRE 建议把根本原因反馈到开发生命周期和架构中，以消除整类缺陷，例如与注入或内存安全相关的缺陷，并指出命令注入之类的弱点会吸引攻击者的注意。如果服务每月都报告同一种注入在不同模块中的新实例，那么针对共用输入处理机制的一项任务比十张单独工单更有用。同时要注意，CWE 分类的是弱点，并不估计某个具体 CVE 被利用的概率，也不能替代利用数据和资产背景。

测试深度：自动化能提供什么，哪里需要人

SP 800-115 逐一介绍了各种技术手段及其优势和局限。对客户的启示是：服务说明中应能看出哪些手段用于哪些资产，以及每种手段无法发现什么。

自动扫描提供广度和可重复性：已知存在漏洞的组件版本、配置错误、缺失的安全响应头。依据 WSTG 的人工测试在需要理解系统预期行为的地方提供深度：业务逻辑、角色和租户之间的访问隔离、单独看来无害的操作链。工具在这里有帮助，但结果通常需要人来解读；如何委托这类测试，我们在业务逻辑安全测试一文中做过介绍。自动化与人工工作的比例应写进工作说明书。ASVS 是一个方便的工具：请服务商标注哪些要求自动测试、哪些人工测试、哪些不在范围内。

深度的另一部分是确认：未经验证的扫描器输出会把筛除误报的工作转嫁给开发人员，并损害对服务的信任。请询问服务商如何确认发现，在发现卡片中记录什么（复现条件、受影响组件、不含多余敏感数据的证据），以及如何标注无法确认的条目。

授权与交战规则

任何测试都必须获得明确的书面授权，而且授权应来自每一个有权批准对相关资产和环境开展工作的主体。合同或附件应规定范围、时间窗口、双方联系人、测试人员可能接触到的数据的处理方式，以及立即停止工作的条件。服务商的商务方案和本文都不构成授权，本文也刻意不包含任何利用说明。

如果你正在准备这样的框架，并想与 Pentest.red 讨论第一轮应纳入哪些系统、测试深度如何，可以通过渗透测试范围沟通表描述任务。这足以让双方就资产、限制条件和预期证据展开具体讨论。

服务应当解释而不只是罗列的 Web 发现

相当一部分 Web 发现源于配置而非代码。HTTP 协议本身不在请求之间保存状态，因此应用会自行添加状态，通常是通过携带标识符的 cookie，服务器据此在自己一侧查找会话。这是正常的架构，但会话的签发、保护和终止由应用负责，问题常常出现在这里，也常出现在响应头和跨源规则中。

MDN 介绍了报告中经常出现的几种机制。内容安全策略（Content Security Policy）规定页面可以加载哪些资源，有助于缓解跨站脚本、数据注入等攻击。CORS 告诉浏览器是否允许其他来源的脚本读取响应；危险配置可能在用户浏览器中暴露带凭据的响应，但它不能替代服务端授权。对于某些跨源 no-cors 请求，跨源资源策略（Cross-Origin Resource Policy）可以不让请求上下文获得响应体，却不一定阻止请求本身发出。权限策略（Permissions Policy）限制网站代码可以使用的浏览器功能和 API。MDN 还提供 HTTP Observatory，用于初步自查配置。

好的报告会从每项发现所降低的风险来解释它，并在适用时将其关联到注明版本的 ASVS 要求。它会区分"缺少一个增加纵深防御的响应头"和"可被利用的注入"，并考虑资源的用途。对允许其他来源公开读取的响应采用宽松 CORS，与让攻击者控制的来源读取已认证用户响应并不是一回事。CORS 管理浏览器对响应的读取，不能决定服务器应授权哪些资源；这两个问题需要分别检查。

CISA Secure by Design 关于跨站脚本、操作系统命令注入和目录遍历的警示，指出了更可取的做法：在源头消除整类缺陷，而不是逐个修补症状。

复测与修复有效的证据

如果服务商只重复信号，而不重复最初确认发现的场景，复测就可能流于形式。回想开头的虚构例子：扫描器之所以看不到漏洞，是因为它被封禁了，而不是因为问题已修复。"未检出"状态只意味着某项特定检查在特定条件下没有产生信号。

因此，复测结论必须限定在实际重复过的内容上。如果最初的发现是以某一角色用户身份通过人工场景确认的，复测就应在约定条件下重现同一场景，而不是只从外部地址跑一遍自动扫描。确认的修复表明该场景不再奏效，但并不意味着风险永久消失，也不意味着相邻路径已被封堵。如果服务商还测试了绕过变体，报告中应能看到。更多内容见我们关于漏洞修复管控的文章。

下表可帮助你验收服务结果：每项声明背后应索取什么证据，以及该证据不能说明什么。

漏洞管理外包的取舍

VMaaS 可以提供内部团队常常缺少的东西：专业的测试能力、稳定的工作节奏和独立视角。但外包也有容易被忽视的代价：业务背景的缺失、对服务商工具和格式的依赖、你的弱点地图由第三方保管，以及工作重心偏向产出报告而非降低风险的风险。以上是专业判断，而不是测量结果，值得在试点中检验。

也有一些事情不会因外包而改变。CISA 在 Secure by Design 项目中指出，网络安全的负担不成比例地落在了用户和小型组织身上，而不是技术生产商身上，并坚持供应商应在管理层面对其产品安全负责。对客户的启示是：托管服务有助于管理风险，但不能替代软件供应商修复自身缺陷。通过采购和合同向供应商施压仍然必要。

如果你在权衡 VMaaS 与发展自建项目，不妨先了解这样的流程在内部如何运作、哪些部分最容易交给承包商，这正是我们建立漏洞管理流程指南的主题。合理的答案往往是混合模式：内部负责流程和风险决策，外部服务商负责发现、确认和复测。

向服务商提出的问题及其平台安全

服务商本身就是一项数字服务，会保存你的详细弱点地图，因此对它的期望与对任何软件供应商相同。CISA 在 Secure by Design 和 Secure by Demand 材料中呼吁默认安全的产品，即多因素认证、日志记录和单点登录不额外收费。对服务商门户而言，这就成了一个具体问题：面向用户的 MFA、SSO 和审计日志是否包含在基础方案中，还是作为附加项另行销售？

集成需要单独讨论。把发现导出到工单系统或 SIEM，应通过权限最小、有效期有限的服务凭据进行，而不是使用员工的共享账号。MFA 是针对人的控制措施；对机器集成而言，更重要的是窄权限、密钥轮换以及快速吊销的能力。平台日志应记录用户和集成的操作，但不得保存密钥、令牌以及证据中多余的敏感数据片段。日志访问应受限，其完整性应得到保护，并应预先规定保留期限。

建议向每位候选服务商提出相同的流程问题，以便比较答案。范围包括哪个 ASVS 版本和哪些要求，引用是否注明版本？使用了哪些 WSTG 和 SP 800-115 技术手段，其声明的局限是什么？如何确认发现，EPSS、KEV 和资产背景如何纳入定级？是否以 CWE 术语报告根本原因？是否包含复测，复测结果如何记录？能否以 CSV 或 JSON 等机器可读格式导出全部数据，包括合同终止时？漏洞数据保留多久，如何确认已删除？

如果服务商使用 AI 进行发现的初步研判或起草报告，请询问人员如何审核结果、如何发现和纠正模型错误，以及你的数据是否会被用于训练第三方系统。

如何开展试点并做出决定

本文引用的开放标准不会为服务商排名或比较价格，也不提供一个通用于 VMaaS 的修复期限；其他义务可能为特定组织规定期限。决定要建立在自己的验证之上，步骤顺序很重要。

先从目标开始：你想降低哪些风险，哪些系统对此最重要。CSF 2.0 的资源，包括快速入门指南和概要（Profile），可以帮助你用风险管理的语言表述这些目标。接着设定验证基线，即针对典型应用、注明版本的一组 ASVS 要求，并请服务商用 WSTG 和 SP 800-115 的术语描述其方法及局限，同时解释其定级模型。

然后，在一个有代表性的应用上开展限时、经授权的试点，最好是你的团队对其弱点已有自己判断的应用。比较已确认的发现、其质量以及对开发人员的有用程度，而不是行数。只有在各方案已统一到相同范围和相同严格程度之后，才比较价格：ASVS 正是为这种统一而创建的。此后衡量的不是发现数量，而是已确认的修复和反复出现的弱点类别的减少。

警示信号在这一阶段就能看出来："符合 OWASP Top 10"却不对应具体要求，把未经验证的扫描器输出当作发现，没有复测和书面授权流程，引用标准却不注明版本，以及承诺实际上要由客户负责达成的通用期限。

对有代表性系统的独立渗透测试可以作为此类试点的基准：它显示人工测试能发现什么，并为比较服务结果提供参照。如果你需要这样的测试，或需要在其他承包商工作之后复测修复，可以了解我们的渗透测试服务，并通过范围沟通表描述你的系统。

结论：如何选择漏洞管理即服务

如果漏洞管理即服务能闭合整个循环，即从资产接入和有计划的测试，经过确认和定级，到经过验证的修复，就值得购买。范围应以注明版本的 ASVS 要求表述，方法以 WSTG 和 SP 800-115 的术语表述，优先级则综合严重性、利用数据、CWE 根本原因和你自身资产的背景。风险决策的责任仍在你这里，合同应体现这一点。

先确定范围和验证要求，再评估方法、定级、复测和平台安全，最后才比较价格。在你自己的系统上开展一次精心规划、经过授权的试点，能揭示任何演示都无法展示的东西：这项服务究竟是在降低风险，还是只是在产出报告。