如何构建漏洞管理流程：从资产清单到复测闭环

审计人员提出一个简单的问题：请证明春季各大行业简报都报道过的那个 VPN 网关严重漏洞，你们已经修复了。团队打开工单系统：任务在三个月前就已关闭，备注写着"已安装更新"。工程师去核实时却发现，网关其实有两台。第二台很久以前为一个临时项目部署在备用机房，从未进入资产清单，扫描器不知道它的存在，至今也没有负责人。没有人给它打补丁——原因很简单，没有人知道它需要打补丁。

这是一个假设场景，并非对真实事件的复述。但其中每个细节都似曾相识：用关闭的工单代替经过确认的修复，没有负责人的资产，一台只认真检查"被告知的目标"的扫描器。这样的组织可能拥有昂贵的平台、每周的报告，甚至定期的渗透测试，却仍然没有漏洞管理流程。它所拥有的，只是一组偶尔交叉的活动。

下文讨论如何把零散的扫描和一次性修复变成职责清晰、可重复的循环：按风险而不是按报告里的颜色对发现项排序，以可证明的方式关闭问题，并判断何时需要平台或外部服务商。本文面向安全负责人、运维和应用安全团队以及采购人员。

为什么扫描器还不等于流程

漏洞管理流程既不是一个产品，也不是一份扫描计划。它是一个决策循环：了解自己有哪些资产，找出其中的薄弱点，判断什么最重要，修复或缓解风险，验证结果，并消除让同类问题反复出现的根源。扫描器只回答其中第二部分，而且只能部分回答。

NIST SP 800-115（2008）本身就给出了很好的提醒。该文件明确说明，它是对技术安全测试与评估关键要素的概述，而不是一套完整的测试计划。它描述了单次评估的各个阶段，即规划、执行和执行后阶段，但并不涉及组织在两次评估之间如何处理结果。而这部分内容——归属、优先级、例外和关闭控制——正是需要组织自己构建的流程。

范围应该包括什么

第一个设计决策是边界。成熟的流程覆盖基础设施、云端和本地主机、Web 应用、API，以及自研或采购的软件。每一次收窄范围都会带来可以预见的盲区。仅限于网络扫描的流程，会漏掉存在于代码和架构中的整类弱点：授权错误、业务操作逻辑、不安全的数据处理。仅限于代码审查的流程，则看不到生产环境中的配置漂移：一个开放的端口、一个被削弱的响应头、一个忘记关闭的测试接口。

范围不必在第一天就完整，但必须形成书面记录，而且排除项必须是有意为之。"我们暂不评估承包商的 SaaS 服务"是一个有负责人的决定；"我们不知道自己在使用承包商的 SaaS 服务"则是一个缺口。

一个实用的循环

实践中，可以把流程理解为五个相互衔接的步骤。这是作者的工作模型，而不是任何标准中的正式模型：SP 800-115 的阶段描述的是单次评估，而这个循环描述的是多次评估的结果如何转化为决策和变更。

1. 资产清单与负责人范围内的每项资产都有负责人、关键性等级以及是否对外暴露的标记。否则所有发现项都无处落地。
2. 评估根据资产类别选择扫描、测试和分析手段，并记录方法及其版本，使不同时期的结果可以相互比较。
3. 优先级排序将技术严重性与利用证据、业务关键性和资产暴露情况结合起来。输入数据变化时重新计算排名。
4. 修复或决策修复、补偿性控制、限期风险接受，或把误报、不适用情况或已退役资产作为有证据的关闭结果。
5. 复测与根因分析重复原始场景，并按需要加入相关变体，或采用有效的等效检查并说明限制。反复出现的弱点类别纳入开发和运维标准。

治理与角色：谁对整个循环负责

治理排在第一位，因为其他所有步骤都依赖于它。如果没有明确谁有权接受风险，任何棘手的发现项都会无限期地留在待办列表中——形式上处于打开状态，实际上无人接受。

流程策略应回答几个问题：范围包括什么；每项资产归谁负责；谁可以测试什么；各级风险应在多长时间内关闭；谁可以正式接受残余风险，期限多长。时限应由策略结合风险、运维能力以及适用的监管和合同义务来设定；不存在适用于所有组织的统一行业期限。

NIST 网络安全框架 2.0（CSF 2.0）适合作为编写此类策略的依据。NIST 将 CSF 2.0 定位为帮助组织理解并改进网络安全风险管理的工具。框架包含用于描述当前状态和目标状态的配置文件（Profiles）、面向常见任务的快速入门指南，以及把框架与其他 NIST 资源关联起来的参考资料。漏洞管理也应如此：作为有决策、有负责人的风险流程，而不是报告生成器。

缺少就会让循环瓦解的角色

最低限度的角色配置如下。流程负责人对整个循环及其指标负责。资产负责人对清单准确性以及各自系统的风险决策负责。内部或合同约定的修复团队执行变更。被授权接受风险的人员批准有期限的例外。关闭验证需要有足够的客观性；对于重大风险，把验证者与修复执行者分开是合理做法。

在小公司里，一个人可能身兼数职。如果独立验证者与风险不相称或确实无法安排，应以可复现证据、风险负责人批准或同事复核来补强自查。任何人都不应在毫无验证的情况下关闭自己的工单。

测试授权

授权同样属于治理。任何扫描和测试都必须在书面许可下进行，许可中应明确边界、时间、联系人和安全限制。SP 800-115 特别重视规划阶段，正是因为许可和交战规则（Rules of Engagement）需要在工作开始前确定。

一个实践细节：许可必须来自每一个有权批准对相关资产和环境进行测试的一方。云服务商、托管商、负责系统维护的承包商、SaaS 服务的所有者——各方都可能有自己的规则。CIO 的同意并不会自动覆盖组织并不拥有的基础设施。

资产清单与发现：无法保护你不知道的东西

流程的基础是带有指定负责人的资产清单。它不是平台上线时填写的一张表格，而是一份定期核对的清单：有什么，归谁，对业务有多关键，能否从互联网访问。"核对"是关键词。真实来源通常不止一个：CMDB、云控制台、DNS、证书登记、网络设备数据。它们之间的差异，就是潜在的"第二台网关"。

外部攻击面值得单独审视，因为从内向外的清单看到的是组织认为属于自己的东西，而攻击者看到的是实际会响应请求的东西。关于如何从外部评估攻击面并对发现项排序，可参阅我们关于外部攻击面评估的文章。

扫描、测试和分析是不同的工具

SP 800-115 为设计、实施和维护技术测试提供了实用建议。它对流程的价值在于描述了不同技术的优势与局限：漏洞扫描、渗透测试、分析和审查。这有助于根据资产类别选择技术和频率，而不是用同一个扫描器、同一个周期处理所有对象。

例如，自动化版本和配置检查可以为大量办公终端提供可重复的覆盖，并发现补丁滞后。对于带有支付逻辑的公开 API，单靠扫描器无法完整验证授权和业务逻辑；重大版本发布前后可能还需要人工测试。对于稳定的内部系统，应根据风险、变化和义务设定深度评估周期。这种选择是成本、频率和深度之间的权衡，值得按资产类别写入策略。

Web 应用与 API：带版本号的方法

对于 Web 应用和 API，OWASP Web 安全测试指南（WSTG）仍是主要的公开测试参考之一。在编写原始材料时，4.2 版是稳定版本，5.0 版仍在开发中；在把版本号写入合同之前，应先确认当前状态。比版本号更重要的是思路：如果在测试计划、合同和报告中固定方法的确切版本，不同年份的结果就可以相互比较。

OWASP ASVS 负责需求一侧。该标准规定了可验证的应用安全需求，并为测试技术安全控制提供依据。ASVS 5.0.0 建议在引用需求时包含版本号，例如 v5.0.0-1.2.5，因为不同版本之间的编号可能变化。需求列表以 CSV、JSON 等机器可读格式发布，可以导入工单系统或漏洞管理系统，把每个发现项关联到具体需求。这样，"登录表单中的漏洞"就变成了一个可验证的陈述：某版本的某条需求未被满足。

配置漂移

配置弱点需要轻量但持续的检查。MDN 文档介绍了浏览器端的安全机制，每种机制都有各自的责任边界，分析发现项时值得理解清楚。内容安全策略（CSP）限制页面可以从哪里加载脚本和其他资源。CORS 决定浏览器中的脚本能否读取来自其他源的响应——它不是服务器端授权，宽松的 CORS 策略也不能代替权限检查。跨源资源策略（CORP）可以阻止其他源获取某些 no-cors 响应的内容，但不一定能阻止请求本身。权限策略（Permissions Policy）控制页面对浏览器功能的访问。

MDN 还推荐使用 HTTP Observatory 检查网站配置。这类检查自动化成本很低：它不能替代测试，而是发现版本间漂移的早期传感器。

漏洞优先级：严重性、利用情况与上下文

仅凭严重性评分高，并不能让一个发现项成为优先事项。如果只依赖它，团队会得到数百个"严重"任务，并按到达顺序处理，而面向互联网的服务器上真正危险的问题则会淹没在列表中间。

可行的优先级排序结合四类信号：技术严重性、真实利用的证据、资产的业务关键性，以及资产的暴露程度，例如能否从不可信网络访问。这些信号回答的是不同的问题，混为一谈是危险的。

关于此表有几点说明。EPSS 是概率估计而不是承诺：数值低并不意味着漏洞永远不会被利用。不在 KEV 中并不能证明漏洞安全——目录记录的是有利用证据的漏洞，而不是所有正在被利用的漏洞。与 KEV 相关的修复期限主要针对美国联邦机构，并非适用于所有组织的普遍要求。

MITRE 方面指出，某些弱点类别（例如命令注入）对攻击者特别有吸引力，并发布了基于 KEV 数据的弱点排名。这对根因讨论很有帮助，但要记住：CWE 分类的是缺陷类型，而不是某个具体漏洞被利用的概率。如何把这些信号转化为可复现的排序方法，详见我们关于基于风险的漏洞优先级排序的文章。

优先级分级是一项设计决策

把信号归纳为少数几个级别会更方便。下面是一种设计建议，而不是行业规范；每个级别的时限应由风险负责人确定。

紧急级可以包括利用证据、可从不可信网络访问和资产关键这三个条件的组合。但这不是封闭筛选器：活跃失陷迹象、事件响应要求，或监管和合同期限，都可能在条件不全时仍把发现项提升到紧急通道。加急级：内部资产上存在已知利用，或外部关键系统上存在高严重性问题。标准级：高或中严重性，但没有利用迹象；除非相关义务另有要求，这类修复随正常发布周期进行。计划级：低严重性或存在有力的补偿性控制；批量修复或书面记录的风险接受。

级别越多，模型越精确，但执行越复杂。这里的四级框架便于落地，每个组织仍需根据自身风险和义务校准。

重新计算优先级

优先级不是发现项的固有属性，而是输入数据的函数，而输入数据会变化。漏洞被加入 KEV、服务获得了外部地址、系统开始处理支付——未关闭发现项的排名都应自动重新计算。如果优先级只在登记时人工指定一次，一个月后它描述的就已经不是你的现实了。

修复：补丁、配置、补偿性控制或风险接受

每个发现项都需要有记录的结果：通过更新、代码或配置完成修复；采用可验证的补偿性控制；由负责人限期接受风险；或经确认后以误报、不适用情况或已退役资产为由关闭。例外和风险接受不等于已修复，而"挂着，直到有人处理"也不是一种结果。

当无法快速修复时，补偿性控制是一个坦诚的选择，例如厂商尚未发布更新而系统又不能停机。但它必须具有可验证的机制。"我们限制了访问"只是一句声明；"某条防火墙规则只允许管理员地址访问该端口，并已通过某项测试验证"才是一项可以在复测时确认的控制。

不会变成永久的例外

例外是带有截止日期的决定。它记录发现项、原因、补偿性控制、风险负责人、批准人以及到期时间。到期后不能默默延期：要么问题已修复，要么用同样的问题重新审议例外。还值得单独跟踪连续多次延期的例外：它们通常反映的不是某个具体漏洞，而是需要提升到预算层面讨论的架构债务。

如何组织修复和例外的跟踪，使任何发现项的决策历史都能被还原，详见我们关于漏洞修复管控的文章。

不必担心停机的变更

修复本身也有运维风险：团队常因担心停机而推迟更新。CISA 的《安全软件部署》（Safe Software Deployment）指南描述了一个在每个阶段都进行测试和度量的部署流程。这一逻辑同样适用于内部运维：如果安全修复经过一条可靠、可回滚的变更流水线，推迟修复的冲动就会减弱。

修复在测试环境中成功应用，并不自动意味着它在生产环境中同样有效：配置、数据和负载都可能不同。通常应在发现问题的环境中重复原始场景。如果主动验证会带来不可接受的风险，可以采用有效的等效检查或配置证据，但必须在结论中说明环境差异和限制。

根因：处理弱点类别

逐个修复发现项是必要的，但还不够。最有力的杠杆是消除整类缺陷，让它们不再出现。

MITRE 在介绍 2025 年 CWE Top 25 时正是强调了这一作用：理解根因可以反馈到开发生命周期和架构中，帮助消除整类问题——例如与内存安全和注入相关的问题——从而减少部署后需要处理的漏洞数量。除主列表外，MITRE 还发布了接近入选排名的弱点。对于那些典型发现项恰好位于主列表之外的团队，这份清单很有用。

CISA"设计即安全"（Secure by Design）的材料体现了同样的逻辑。该机构发布了消除特定漏洞类别的指南——跨站脚本、操作系统命令注入、目录遍历——以及迁移到内存安全语言的路线图指南，包括外部开源依赖。对于自研软件，结论很实际：反复出现的发现项应当转化为安全编码标准、模板、库以及构建流水线中的检查。OWASP Top 10 的 2025 版仍是广泛认可的开发者安全意识基线，但它只是意识基线，而不是完整的需求清单。

一个假设的例子：某团队连续三个版本都在不同的报表表单中收到注入类发现项。它可以每次只修复具体字段；也可以把手工拼接的查询替换为参数化的数据访问层，在静态分析中加入规则，并把相应检查写入验收标准。前一条路关闭的是工单，后一条路关闭的是一类问题。差异会体现在下文讨论的复发指标中。

复测与关闭证据

关闭的工单并不等于已修复的漏洞。关闭时应重复原始场景，并在相关时检查相近的绕过变体；如果方法及其限制有记录，也可以采用有效的等效检查。扫描器发现项可重新扫描，Web 发现项可按方法重复相应测试，适用于应用或 API 的需求缺口可对照具体 ASVS 要求核查。ASVS 有助于规定应用验证的覆盖和严格程度，但不是整个基础设施的关闭标准。

SP 800-115 将测试与若干控制族相对应，包括审计与问责、评估、授权与监控以及风险评估。因此，认真收集的证据在审计中也会有用，但证据本身并不构成认证或合规意见。

应将证据作为敏感数据对待。日志和服务器响应中可能包含令牌、个人数据和内部地址。尽量减少保存内容，清除密钥，限制访问，保护完整性，并规定保存期限。

还有一个边界：复测确认的是在既定条件和范围内的某项具体修复，而不是风险永久消失。如果一个月后服务被重新配置，之前的结果并不能说明新状态。如何设计此类检查并表述结论，详见我们关于渗透测试修复验证的文章。

用独立测试检验流程本身

定期的独立测试，例如经授权的渗透测试，可以在检查系统的同时为流程质量提供证据。如果测试人员发现计划内评估遗漏的问题，应检查覆盖范围、测试时点、技术选择和系统变化；单个结果不能证明只有一种原因。渗透测试不是认证或安全意见，而是对约定边界和条件下已测试场景及其结果的记录。如果你想讨论此类独立检查应包括哪些资产和哪些证据，可以先与 Pentest.red 团队一起梳理渗透测试范围。

指标：衡量流动，而非数量

应衡量发现项在循环中的流动和结果，而不是数量。有用的指标包括：纳入定期评估的已登记资产比例；按优先级划分的修复时间；未关闭发现项的时长分布；有效例外的数量及其到期时间；首次复测即确认关闭的比例；按 CWE 类别统计的发现项复发情况。这些是推荐指标而非行业基准，目标值由你的策略来设定。

把发现项关联到 CWE，可以看到趋势，并检验根因工作是否有回报。注入类或内存处理错误类的复发率下降，比发现项总数下降更能证明进展。向管理层汇报时，应使用与 CSF 2.0 成果一致的风险语言：多大比例的关键资产处于受控状态，有多少紧急发现项的未关闭时间超过了策略规定，哪些例外将在下个季度到期。

有害的指标

避免为了报告而设的指标。当覆盖范围扩大时——接入新的网段、开始测试 API——发现项总数会上升。如果用这个数字来评价团队，就等于惩罚你希望鼓励的行为。另一个类似的陷阱是对所有发现项一起计算平均修复时间：十几个低级别的快速关闭会掩盖一个已经挂了一个月的紧急问题。因此，修复时间应按级别查看，而不是看平均值。

根据既定流程选择平台或服务商

工具和承包商最好在流程确定之后再选择。否则，工具的默认设置就会成为你的流程：它的优先级模型、它对"已关闭"的定义、它的指标。平台帮助你执行流程，但不能替代关于负责人、例外和证据的决策。

CISA 发布了面向软件客户的《按需安全》（Secure by Demand）指南，帮助在采购中向供应商提出问题。澳大利亚 ACSC 与 CISA 联合发布的关于选择安全且可验证技术的指南，直接面向采购组织。两者都可以作为问题来源，而不是强制性要求清单。

向供应商提出哪些问题

评估平台或外部服务时，应要求可验证的答复，而不是承诺：

• 使用哪些方法及其版本，例如 SP 800-115、具体的 WSTG 版本和 ASVS 5.0.0；
• 在任何工作开始之前，如何记录授权、边界和交战规则；
• 优先级排序是否考虑利用证据和资产上下文，而不仅仅是严重性评分；
• 发现项是否关联到 CWE，以及适用的应用和 API 发现项是否关联到带版本号的 ASVS 需求；
• 提供哪些导出格式以及与你的工单系统的集成；
• 是否包含用于确认关闭的复测，以及在什么条件下进行；
• 证据保存多长时间、归谁所有、如何保护。

对你所运行的产品也应采用同样的严格标准。CISA 推行自愿性的"设计即安全承诺"（Secure by Design Pledge），包含七项目标，签署方需就这些目标发布进展报告。签署并不是认证，但这类报告是有用的输入信号。在"设计即安全"的材料中，该机构还强调产品应默认安全，多因素认证、日志记录和单点登录等基本安全功能不应额外收费。

自建、外包还是混合

模式的选择取决于三个因素：资产规模和多样性、员工在测试和修复方面的能力，以及自研软件的规模。资产规模较小、自研代码较少的组织，通常可以依靠平台加定期外部测试。拥有多个开发团队的产品型公司，一般需要在内部掌握根因工作，因为这项工作存在于开发生命周期之中。

权衡如下。把发现和测试交给承包商，可以获得专业能力和独立视角。合同也可以把部分修复执行工作委托给承包商，但组织仍对资产和风险接受决策负责，并需要验证已完成的工作。完全自建的方案带来控制力和上下文，但需要稳定的团队。混合模式是划分治理、优先级、修复、测试和验证职责的一种方式；具体分工应由风险、能力和合同边界决定。关于托管服务可以委托哪些工作，可参阅漏洞管理即服务。

如果混合模式更适合你，可以与 Pentest.red 讨论外部部分：哪些资产类别应纳入渗透测试，你的工单系统需要什么样的证据、以什么格式提供，以及如何组织修复后的复测。关于负责人、时限和风险接受的决定仍由你的组织做出。

从哪里开始

漏洞管理流程不是围绕扫描器构建的，而是围绕归属、授权、基于风险的优先级、经过验证的关闭以及从根因中学习而构建的。

从范围和负责人开始：写下你评估什么、谁对什么负责，并至少用两个独立来源核对资产清单。然后引入考虑利用情况和资产上下文的优先级排序，以及带截止日期的例外规则。要求每次关闭都有依据；对于已修复的漏洞，还应进行复测，并开始按弱点类别统计复发情况。当这些基础就绪后，选择系统或服务就变成了为清晰的流程挑选执行者，而不是让执行者替你定义流程。到那时，审计人员关于第二台 VPN 网关的问题，你在对方开口之前就已经有了答案。