漏洞管理最核心的漏洞动作不是扫描，是管理确认。很多人以为买套扫描器、主工作内每周跑一次、漏洞导出报表就算完事，管理这基本等于白干。主工作内我见过一家做电商的漏洞中型公司，扫描器每天报警两百多条，管理安全团队三个人根本看不过来，主工作内最后只挑“高危”处理，漏洞结果真正被利用的管理是一个被标记为“中危”的Struts2漏洞——因为扫描器版本库没更新，它把远程命令执行判成了信息泄露。主工作内漏洞管理的漏洞第一道坎永远是：你看到的漏洞，和攻击者能用的管理漏洞，中间差着一条河。主工作内

资产梳理是这条河的桥。你不知道自己有多少台机器、跑着什么服务、哪个端口对外，那扫描结果就是一堆无根浮萍。我习惯把资产库比作户口本，漏洞是户口本上每个人的体检报告。没户口本，体检报告就是废纸。实际操作中，最头疼的是影子资产——开发自己开的测试机、运维临时搭的跳板、市场部买的SaaS服务。这些玩意儿扫描器扫不到，但攻击者一找一个准。有个做金融的客户，生产环境护得跟铁桶似的，结果被一个离职员工留下的AWS测试实例给捅穿了，那实例上跑着旧版Jenkins，未授权访问。

漏洞评级不能只看CVSS。CVSS是通用分，但你的业务场景才是决定优先级的关键。一个内网Redis未授权，CVSS可能给9.8，但如果那台Redis只监听127.0.0.1，实际风险约等于零。反过来，一个对外Web的XSS，CVSS才6.1，可要是它出现在登录后的转账页面，能直接偷token，那它就是P0。我判断优先级就三条：能不能从公网摸到、需不需要认证、能不能直接拿到数据或权限。三条全中，放下手里所有事，立刻修。

修复环节最容易扯皮。安全说“高危，24小时内修”，开发说“排期满了，下个迭代”。这时候别拿CVSS压人，拿利用链说话。把PoC跑一遍，录个屏，告诉开发：“这个接口不用登录就能删库，我演示给你看。”大部分开发看到实际效果都会改。如果还不改，那就走风险接受流程——让业务负责人签字，白纸黑字写清楚“我知道这个漏洞可能造成什么后果，我决定不修”。这招比任何强制手段都管用，因为没人愿意背锅。

复测不是走过场。开发说修好了，你得亲自验证。我遇到过开发把前端校验加上了，后端接口照样裸奔；也遇到过改了配置文件但没重启服务，漏洞还在。复测要按原利用路径再打一遍，别信“已修复”三个字。另外，修完的漏洞要归档，记录修复方式、时间、验证人。这不是为了写报告，是为了下次出同类问题时能快速定位——比如某个中间件漏洞反复出现，说明你们的镜像基线有问题，得从根上治。

最后说度量。别只看“修复率”这种虚荣指标。真正有用的是：从漏洞公开到你们完成修复的平均时间、同一漏洞重复出现的次数、以及有多少漏洞是被外部通报才发现的。最后一个指标最扎心，它直接反映你的发现能力。如果超过三成的漏洞是甲方或SRC告诉你的，那你的扫描策略和资产覆盖肯定有盲区。漏洞管理没有终点，只有循环：发现、确认、评级、修复、复测、度量，然后回到发现。每转一圈，你的盲区就小一点。