漏洞扫描制度

上周三凌晨两点，漏洞某电商平台的扫描运维老张被电话叫醒——数据库被拖库了。事后排查发现，制度漏洞扫描报告里那条“高危：Apache Log4j2远程代码执行”已经躺了47天，漏洞状态栏写着“待修复”。扫描这不是制度个例。我见过太多公司，漏洞扫描工具买了最贵的扫描，报告每周准时生成，制度但漏洞依然像野草一样春风吹又生。漏洞

问题出在哪儿？扫描扫描本身不产生安全，产生安全的制度是“扫描→确认→修复→复验”这个闭环。可大多数企业的漏洞漏洞扫描制度，根本就是扫描个单行道。

先说扫描频率。制度很多制度写得像法律条文：“每季度进行一次全面扫描”。可现实是，新漏洞每天都在爆发，一个季度前的扫描结果，对今天的攻击面来说基本等于考古文献。我认识一个安全工程师，他偷偷把扫描任务设成了每周日凌晨自动跑，因为“真等季度扫描发现漏洞，黄花菜都凉了”。制度应该允许甚至鼓励这种“越界”行为——把最低频率定死，但别设上限。

再说漏洞分级。CVSS评分10分就是高危？未必。一个在内网管理后台的SQL注入，和一个暴露在公网的CSRF漏洞，哪个更致命？得分高的不一定先被利用。我见过某金融公司，把所有高危漏洞都列为“紧急”，结果修复团队疲于奔命，真正能被外部利用的漏洞反而排队等了两周。分级不能只看分数，得结合资产暴露面、业务影响和实际利用难度。

最要命的是责任归属。扫描报告出来了，漏洞列表清清楚楚，可谁来修？开发说是运维的锅，运维说是架构的问题，架构说这是历史遗留。最后漏洞在部门之间踢皮球，直到被黑才有人认领。制度里必须写明白：每个漏洞从发现那一刻起，就自动分配给一个“负责人”，可以是开发、运维或第三方，但必须有人签字确认。

还有复验环节。很多团队修完漏洞就完事大吉，根本不重新扫描确认。结果呢？修复不彻底，攻击者换个姿势又进来了。复验不是走流程，是要用同样的扫描工具、同样的参数，确认漏洞确实消失。如果修复引入了新问题，还得再走一轮循环。

最后说句大实话——制度写得再漂亮，不如一个能自动发工单、到期提醒、超时升级的系统。人总是会偷懒的，但机器不会。把漏洞扫描的每个环节都绑定到具体的人和具体的截止时间，比在制度文档里喊一百遍“重视安全”都管用。

漏洞扫描不是给审计看的花架子，它是网络安全的地基。地基不牢，上面盖多高的楼都得塌。别等被黑了才想起补制度——那时候补的，可能是自己的窟窿。