```html

2023年3月，网络某三甲医院的安全信息科主任在例行巡检时发现，一台内网服务器的漏洞CPU占用率连续三天维持在90%以上。查了进程，管理是网络个叫“svchost.exe”的家伙在疯狂往外发数据。他第一反应是安全中了挖矿木马，断网、漏洞杀毒、管理重启，网络一套流程走完，安全CPU降下来了。漏洞但两周后，管理同样的网络现象再次出现。这次他留了个心眼，安全抓包分析，漏洞发现数据全流向了一个位于东欧的IP。再往下挖，根源是一年前上线的某款国产数据库管理工具——它的某个组件存在未修复的反序列化漏洞，而厂商早已停止维护。这台服务器上存着近三年的患者影像数据。

这就是漏洞管理最真实的模样：它不是买一套扫描器、每月跑一次报告就完事的。漏洞管理是一套持续对抗熵增的流程，核心在于“闭环”二字。发现、评估、修复、验证、复盘，缺一环，整个链条就是纸糊的。

很多团队卡在第一步就输了。资产台账不准，你连自己有什么都不知道，谈何管理漏洞？我见过一家电商公司，安全团队用扫描器扫了全网段，报告显示“零高危”。结果渗透测试的小伙子从一台被遗忘的测试服务器入手，十分钟就拿到了核心数据库的权限。那台服务器不在任何资产清单里，是两年前某次大促临时扩容留下的“僵尸”。漏洞管理的起点从来不是扫描，而是搞清楚你究竟有多少IP、多少域名、多少API接口、多少第三方组件。

评估环节最容易陷入“CVSS评分依赖症”。一个CVSS 9.8的漏洞，如果它位于一台与外网隔离、仅用于打印报表的Windows XP机器上，实际风险可能远低于一个CVSS 6.5但暴露在公网、且能直接触达用户订单数据的接口漏洞。资产重要性、网络可达性、利用难度、业务影响——这四个维度得揉在一起看。我习惯用“攻击者视角”做二次判断：如果我是黑客，我会先打哪个？答案往往和扫描器给出的优先级不同。

修复才是真正的泥潭。运维说“业务不能停，窗口期排到下个月”，研发说“这个组件升级会引发兼容性问题，得改代码”，采购说“厂商的补丁要额外收费”。安全团队夹在中间，手里只有一份漏洞报告，没有资源调配权。怎么办？我的经验是：把漏洞翻译成业务语言。不要说“CVE-2024-XXXX高危”，要说“这个漏洞如果被利用，支付接口会中断4小时，按去年日均流水算，损失约XX万”。数字比评级更有说服力。

验证环节常被跳过。补丁打了，服务重启了，扫描器再扫一遍显示“已修复”。但有没有可能只是端口关了？有没有可能补丁被回滚了？有没有可能攻击者已经留了后门，而漏洞本身只是入口？我坚持在修复后做一次针对性验证——用POC脚本实际打一次，或者人工检查关键配置项。确认漏洞真正不可利用，才算闭环。

最后说个容易被忽略的点：漏洞管理不是安全团队一个部门的事。某车企的做法值得参考——他们把漏洞修复率写进了每个研发团队的季度OKR，安全团队只负责提供工具、标准和验证。修复慢了，扣的是研发的绩效，不是安全的。责任归位，流程才转得动。

漏洞永远修不完。今天修了Apache的RCE，明天Log4j又爆了。但一套跑得通的闭环流程，能让你在下一个漏洞爆发时，不慌。

```