漏洞控制

去年某开源组件爆出反序列化漏洞那天，漏洞控制我正蹲在客户机房调防火墙策略。漏洞控制手机震了十几下，漏洞控制群里有人甩出PoC链接，漏洞控制配文就俩字：“炸了。漏洞控制”两小时后，漏洞控制这个组件在全球至少二十万台服务器上被扫出存在利用痕迹。漏洞控制而它的漏洞控制维护者，一个四十多岁的漏洞控制德国人，在GitHub issue里回复：“我上周刚提交了修复，漏洞控制但下游有三百多个项目没合并。漏洞控制”

这就是漏洞控制漏洞控制的真实处境——它从来不是技术问题，或者说，漏洞控制不只是漏洞控制技术问题。

很多人以为漏洞控制就是漏洞控制打补丁。CVE编号一出来，安全团队连夜推更新，运维批量重启，完事。这套流程在理想环境里能跑通，但现实是：你根本不知道资产清单上那台2015年的CentOS 6服务器上跑着什么业务，开发说“早不用了”，业务部门说“每个月还在出报表”。这台机器就成了漏洞的温床，而它甚至不在CMDB里。

我见过一家电商公司，安全部门发现Struts2漏洞后发了高危通告，要求48小时内修复。结果拖了三个月。原因特别朴素：那套系统是外包做的，外包公司倒闭了，源码在某个离职员工的移动硬盘里。最后他们用WAF硬扛，规则写了十七条，误杀率飙升，业务部门投诉到CEO那儿，安全负责人被骂了一顿。

漏洞控制的核心矛盾在这儿：修复成本永远高于利用成本。攻击者只需要找到一个入口，防守方要堵住所有出口。一个CVSS 9.8的漏洞，利用代码可能只有二十行，而修复它需要协调开发、测试、运维、业务四个部门，走变更流程，做回归测试，凌晨两点发版。这还没算上那些“修了但没完全修”的情况——比如开发把版本号改了，实际依赖没更新，扫描器扫出来是绿的，一打就穿。

更麻烦的是人的惯性。我接触过不少团队，他们的漏洞管理还停留在Excel阶段。安全工程师每周导一次扫描报告，标红高危项，发邮件给各系统负责人。然后呢？然后就没有然后了。邮件已读不回是常态，催急了对方回一句“排期到Q3了”。你没法用KPI考核一个不归你管的人。

有个做法我觉得挺有意思。某金融公司把漏洞修复率做进了各业务线负责人的季度OKR里，权重占15%。安全部门不再追着人跑，而是每周出一次排名，抄送CTO。排名垫底的团队要在一个月内提交整改计划。三个月后，他们的平均修复周期从47天降到了9天。手段不新鲜，但有效。漏洞控制说到底是资源分配问题，当修复漏洞的优先级高于其他任务时，事情才推得动。

技术层面反而简单些。资产测绘先做清楚，别信CMDB，用主动扫描加流量分析交叉验证。SBOM（软件物料清单）能上就上，至少知道每个应用里塞了哪些第三方库。WAF和RASP当补偿控制可以，但别当长期方案，那玩意儿维护起来比修漏洞还累。还有，别迷信CVSS评分，一个内网才能访问的漏洞和一个公网直接RCE的漏洞，优先级差着量级。

最后说个观察。漏洞控制做得好的团队，往往不是安全工具最贵的，而是沟通成本最低的。安全工程师能直接找到开发负责人，开发负责人愿意为安全排期，运维愿意在变更窗口配合。这种协作关系比任何自动化平台都值钱。工具能告诉你哪里有洞，但补洞的永远是人。