漏洞管理流程图（从扫描到验证关闭）
漏洞管理流程图模板：扫描范围与覆盖、认证扫描、分流与误报、CVSS与利用评分、SLA分级、复扫验证、例外与逾期升级。
什么是漏洞管理流程图（从扫描到验证关闭）流程
漏洞管理是在整个资产范围内发现已知弱点、判断哪些真正重要、推动它们被修复并加以证明的常态化运营循环。它的触发是一份计划，而不是一个事件：扫描窗口针对资产台账开启，下游的一切都取决于这份台账是否准确。下面这张图跟随一个完整周期，从头走到尾：先议定扫描范围与凭据覆盖率，再运行认证扫描；供应商公告与扫描器自身的输出并行到达；发现被去重并确认；评分把严重程度、可利用性与资产上实际承载的内容结合起来；到期日与具名责任人随之绑定；一次变更承载修复；复扫要么关闭这条发现，要么让它重新开启；登记册与各项指标，就是管理层在下一个窗口开启前要审阅的内容。
这张图画的是这套体系，不是修复本身。一名系统负责人在单张工单里做的事——对照自己的环境验证发现，在补丁、升级、配置调整与下线之间做选择，测试并部署——属于漏洞整改流程，它挂在图中唯一画出的那一步“实施补丁、配置调整或补偿控制”上。供应商补丁本身，连同其适用性评估、非生产环境测试、分环部署与回滚，属于补丁管理，是这套流程消费而非包含的另一个独立周期。而完整的安全例外流程——业务理由、补偿控制、随风险评分而变化的审批层级、登记册条目与续期复核——位于“例外是否已附失效日期获批？”这个决策之后，而不是在它内部。让这些边界保持可见，正是防止一张图试图同时充当三张图的办法。请把接下来的内容当作起点，按你们自己的安全策略、监管义务与合格安全从业者的判断去调整它。
四个判断撑起这套流程。“范围内每台资产都可扫描吗？”排在最前面，因为覆盖缺口是不可见的：没有扫描模板能触达的资产不会产生任何发现，一块干净的仪表盘和一片未被扫描的资产，在报告上看起来一模一样。“是已知被利用还是严重程度为‘严重’？”是优先级的分岔点，它放在分析师的泳道里，因为利用证据是分析师掌握的，而它开启的紧急通道则属于安全管理层，只有他们才有权限打断其他工作。“能在SLA内完成整改吗？”被刻意放在系统负责人 / IT 运维的泳道，而不是分析师的泳道——必须做出变更的人，才知道这个窗口是否真的存在——它的否定分支通向由安全管理层拥有的例外决策，因为接受风险是一种管理行为，而不是工程行为。“复扫显示发现已关闭吗？”把流程交回分析师手中，让关闭建立在证据之上，而不是建立在有人把工单标记为完成之上。
本流程图涵盖的内容
本模板包含
- 五条泳道——漏洞分析师、系统负责人 / IT 运维、变更经理、安全管理层与供应商——横跨六个阶段：范围与发现、扫描与接收、分流、优先级与分派、整改与验证，以及报告与复核
- 任何扫描之前的一道覆盖闸门：“范围内每台资产都可扫描吗？”把缺失的凭据和未部署的代理送回去修正，因为一台扫描器无法与之完成认证的资产，几乎报不出任何东西，却依然被计为已扫描
- 汇入同一队列的两条接收路径：扫描器自身的输出，以及在“发布公告与修复版本”这一步到达的供应商公告，使两次扫描窗口之间公开披露的内容不会一直无人认领，拖到下一个周期
- 多数流程图会压缩成一个方框的分流一对：“发现在资产上得到确认了吗？”把未确认的结果导向“作为误报并附证据关闭”，这是一个封闭的终点，却依然要求理由、失效日期与审批人
- 评分与到期日作为两个分开的动作：“按CVSS、可利用性与资产价值评分”产出评分，“是已知被利用还是严重程度为‘严重’？”把紧急工作与常规分级区分开来，直到那之后才指定并问责一位整改责任人
- 基于证据的关闭，带两个循环与一条出口：“复扫显示发现已关闭吗？”会把仍然存在的一切重新打开，“能在SLA内完成整改吗？”通向“例外是否已附失效日期获批？”，逾期的发现会在指标发布之前被升级
何时使用本模板
- 你们正在起草或重写一套漏洞管理标准，需要一张图看清谁扫描、谁评分、谁整改、谁接受剩余风险
- 发现的账龄不断超过到期日，却没人能说清它们卡在分流、分派、变更窗口，还是复扫这一环
- 你们正在选型或更换扫描器，希望在配置扫描策略、凭据存储、资产分组与SLA分级之前先议定这套流程
- 安全团队和IT运维在什么才算“已整改”上意见不一，因此复扫、例外路径与升级路径都需要写明并落实到具体责任人
- 审核员或客户的安全问卷要求提供一份成文说明，讲清漏洞如何被识别、评分、整改与验证
运作方式
把泳道改成你们的角色
用你们组织中真正存在的角色，替换漏洞分析师、系统负责人 / IT 运维、变更经理、安全管理层与供应商。在小团队里，分析师和系统负责人往往是同一个人：把这两条泳道合并，而不要画一次只存在于纸面上的交接。即便如此，也要让安全管理层保持独立，因为例外与升级分支需要一个不同时兼任整改人的权威。
写下你们的扫描范围与覆盖规则
写明哪些资产在范围内、它们如何从台账或CMDB进入范围、哪些用凭据或代理扫描、哪些不用，以及每个分组多久扫描一次。记下例外情况以及谁有权批准。覆盖率是让项目里其他一切数字都有意义的那个数字，所以把它画在图上，而不是留在没人会去看的工具设置里。
定义发现如何评分
写明你们使用的严重程度量表以及分数的来源，然后写明你们在它之上再加什么。严重程度分数描述的是技术影响；利用证据与资产背景描述的，是这周你们究竟应该有多担心。把你们实际使用的组合写下来，为每个输入命名，并记录谁有权推翻某个评分，以及这个推翻依据什么证据。
设定SLA分级并让计时开始
把你们自己的整改到期日画在图上，删掉占位符。与必须遵守每个分级的人商定它，并明确说明计时从何时开始，因为发现日期、工单日期与供应商发布日期，会对同一批资产得出截然不同的账龄报告。写明紧急通道在实践中意味着什么，以及谁有权开启它。
议定例外与升级路径
决定谁有权批准一项例外、需要附带什么证据、它最长可以存在多久，以及在它存续期间必须运行什么补偿控制。然后议定没有例外却已逾期的一切该如何升级：通知谁、在什么账龄触发、之后仍无变化会怎样。两条路径都需要一位具名的人，而不是一个共用邮箱。
确定什么能证明一项发现已经关闭
关闭应当建立在对受影响资产的复扫之上，而不是建立在工单被标记为完成之上。写明哪次扫描能证明这一点、它在修复后多快执行，以及当复扫仍然报告这项发现时会发生什么。记录一项补偿控制究竟是关闭了发现，还是只是降低了它，因为这两种约定会产生截然不同的登记册和指标。
用一条真实发现走一遍流程
取上一周期的两项发现——一项按时关闭，另一项逾期或最终成为例外——沿着图把两者都走一遍。人们描述过、却没有画出来的每一步，以及画出来了、却在实践中被悄悄跳过的每一步，都是你们在把这套流程发布给其他人之前，值得处理的发现。
常见问题
漏洞管理流程包含哪些步骤？
扫描周期针对资产台账开启，范围与凭据覆盖率在任何扫描运行之前就已确定；扫描器触及不到的资产会被修正并复查。计划中的认证扫描随之运行，两次扫描之间到达的供应商公告会汇入同一队列。发现先去重并补充利用数据，再对照资产确认，未获确认的一律连同证据作为误报关闭。已确认的发现按严重程度、可利用性与资产价值评分，被导向紧急通道或标准到期日分级，并指定给一位具名的整改责任人。这位责任人要么在到期日之前完成整改（必要时通过变更窗口），要么申请一项附失效日期的例外。复扫确认关闭，或让工作重新开启。最后，登记册被更新，逾期的发现被升级，覆盖率、账龄与关闭率指标被发布，管理层在下一个周期开始前复核这一趋势。
漏洞管理与补丁管理有什么区别？
漏洞管理是在整个资产范围内发现弱点、为它们评分，并把它们推向经过验证的关闭的那个循环——无论最终采用哪种处置方式。补丁管理是这些处置方式之一：一个把供应商发行的版本拿来评估是否适用、测试、排期并部署的运营循环。NIST 关于企业补丁管理规划的指南（SP 800-40 第4版）从另一个角度说明了同一件事：它把打补丁定位为预防性维护，视其为应对软件漏洞所带来风险的多种方式之一。这带来的实际后果是，一个只用已安装补丁数量来衡量的漏洞项目，会低估自己的成效，因为配置调整、升级、下线与补偿控制同样能关闭发现，而且有些发现根本没有补丁可装。
CVSS 评分足以确定整改优先级吗？
CVSS 由 FIRST 维护，把技术严重程度评为0.0到10.0分，其3.1版的定性分级是：低 0.1至3.9、中 4.0至6.9、高 7.0至8.9、严重 9.0至10.0。2023年发布的4.0版保留了基础评分，并新增了明确的威胁与环境两组指标。CVSS 有意不会告诉你的是：这个漏洞被利用的可能性有多大，或者某个具体资产对你究竟有多重要。团队通常会再加两个信号：一是像 EPSS 这样的利用概率评分，同样由 FIRST 提供，估算某个漏洞在未来三十天内在现实世界中被利用的概率，并且每天重新计算；二是实际被利用的证据，例如 CISA 的已知被利用漏洞（KEV）目录。资产背景是第三个输入，也是只有你自己才掌握的一个。这正是本图先评分、再依据“是已知被利用还是严重程度为‘严重’？”来分流，而不是简单按分数给列表排序的原因。
漏洞扫描应该多久执行一次，这个流程该由谁负责？
各框架的要求并不一致，所以请以适用于你们的那一个来定频率，而不是套用某条通用规则。ISO/IEC 27001:2022 附录 A 的8.8控制项，即技术漏洞管理，要求获取所用系统中技术漏洞的相关信息、评估暴露程度并采取适当措施，但并未规定具体间隔，把节奏留给你们自己的风险评估。PCI DSS 第4版对持卡人数据环境的规定更为明确：内部漏洞扫描至少每三个月一次，并在任何重大变更之后再次进行，均以认证扫描方式执行，外部扫描则由一家经批准的扫描服务商（Approved Scanning Vendor）完成。许多组织的扫描频率远高于这个最低要求，因为多扫一次的成本很低。至于归属，通常的划分正是本图所画的那样：安全团队负责发现、评分与报告；系统负责人负责整改；管理层负责例外与升级。一个连整改也由安全团队负责的项目往往会陷入停滞，因为分析师既没有变更权限，也不承担运营风险。
漏洞管理流程应当产出哪些记录？
要多到足以在一年之后、不打开扫描器的情况下重建任何一项发现。实践中这意味着每项发现在登记册中都有一条记录，载明受影响的资产、发现日期、评分及其依据、指定的责任人、到期日、选择的处置方式与关闭证据。与之并列的还有扫描配置与覆盖率证据，让审阅者能看清哪些在范围内、哪些经过了认证；关闭清单，为每一项误报记录理由与复核日期；例外登记册，载明理由、补偿控制、审批人与失效日期；以及关闭每一项发现的那次复扫的输出结果。报告是最后一类记录：覆盖率、相对到期日分级的账龄，以及关闭率随时间的变化，连同趋势变化时管理层做出的决定。审阅者通常会拿登记册去对照扫描器，而不是反过来，所以工具里存在、登记册里却没有的、说不清来由的发现，才是最常见的问题。