去年有个做电商的漏洞朋友找我，说服务器被挖矿了。管理查了半天，步骤入口是漏洞一个两年前的Log4j漏洞。补丁其实早就发了，管理但他们的步骤资产清单里压根没记录那台机器。这事不复杂，漏洞却暴露了漏洞管理最要命的管理问题：你连自己有什么都不知道，谈什么修复。步骤

漏洞管理不是漏洞装个扫描器就完事。它是管理一套流程，六个步骤，步骤缺一环就漏风。漏洞

第一步：资产盘点，管理别偷懒

扫描器扫出一堆IP，步骤你以为覆盖全了？云主机、容器、第三方API、员工自己搭的测试站——这些经常在清单之外。我见过一家公司，安全团队管着800台服务器，结果运维那边偷偷开了200台云实例跑业务。扫描器根本没扫到。资产盘点得跟财务对账一样，动态更新。CMDB不是摆设，得有人维护。

第二步：扫描，但别只看评分

CVSS 9.8的漏洞不一定比7.5的急。要看资产暴露面。一个内网测试机的Log4j，和一个公网支付网关的Log4j，优先级天差地别。扫描频率也得讲究：核心业务每周扫，边缘系统每月扫。别天天全量扫，扫描器自己都能把网络搞瘫。还有，认证扫描和未认证扫描结果差很多，别图省事。

第三步：定级，别让CVSS牵着走

漏洞定级要结合三个东西：漏洞严重性、资产重要性、利用难度。一个需要物理接触才能利用的高危漏洞，在云环境里可能根本不可达。我习惯用“可利用性”打分：PoC公开了吗？在野利用有吗？攻击链需要几步？把这些跟业务负责人聊清楚，他们才知道为什么要熬夜修。

第四步：修复，分清“能修”和“该修”

不是所有漏洞都能打补丁。老旧系统厂商早就不支持了，你怎么办？虚拟补丁、WAF规则、网络隔离，都是手段。关键是跟运维达成共识：修复窗口期多长？回滚方案有没有？我见过安全团队发工单要求“24小时内修复”，运维直接回“你行你上”。后来改成一起排期，效率反而高了。修复不是甩锅，是协作。

第五步：验证，别信“已修复”三个字

运维说补丁打了，你就信了？重新扫一遍，或者手动验证。有个案例：管理员打了补丁但没重启服务，漏洞依然存在。验证要独立做，不能靠工单状态。自动化验证脚本能省不少事，但关键系统最好人工确认。漏报比误报更可怕。

第六步：度量与迭代，别做无用功

每月统计：平均修复时间、漏洞重开率、扫描覆盖率。这些数字不是给老板看的，是给自己找问题的。如果MTTR从30天降到7天，说明流程顺了。如果重开率超过10%，说明修复质量有问题。我见过团队只盯着“关闭数量”，结果把漏洞标记为“风险接受”就算完事。那是自欺欺人。

这六步走下来，漏洞管理才算闭环。工具能帮你省力，但判断和沟通省不掉。那个被挖矿的朋友后来把资产清单接入了CMDB，扫描器每天自动比对。上个月又出一个新漏洞，他们两小时就定位到了所有受影响机器。他说：“以前是盲人摸象，现在是拿着地图打仗。”

漏洞永远修不完。但你知道自己有什么、什么最急、谁去修、修没修好——这比买最贵的扫描器管用。