漏洞管理怎么防：从代码到配置的四层

走例外的漏洞必须写补偿措施与到期日，否则会一直挂在那里没人管，季度评审时也翻不出来，例外会越积越多

四层防御的思路是：每层都不完美，但绕过的代价逐层上升。

先说结论

校验在入口，收敛在危险点，兜底在权限，发现靠监控。四层缺一不可。

• 第一层：白名单校验 + 类型转换
• 第二层：危险点收敛成统一封装
• 第三层：最小权限 + 沙箱
• 第四层：日志与告警，能发现异常
• 演练：定期用无害方式验证防御有效

四层分别挡什么

走例外的漏洞必须写补偿措施与到期日，否则会一直挂在那里没人管，季度评审时也翻不出来，例外会越积越多。

第一层：输入

同一个基础镜像的漏洞会在几十个服务里重复出现，按根因修一次能消掉几十条，镜像统一才好修。

白名单优于黑名单，因为黑名单永远漏。

第二层：危险点

扫描器报的版本号可能被发行版回补过，直接判漏洞会产生大量误报。

把「拼接」「解析」「执行」这三类操作收敛到少数几个函数里，审计面积会小一个数量级。

这个问题的几个防御事实

落到具体实现时，这几条最容易被忽略：

• 严重级别按 24 小时修完，前提是资产清单与责任人都是准确且最新的，否则 SLA 只是纸面上的数字，这条最难落地
• 扫描器报的版本号可能被发行版回补过，直接判漏洞会产生大量误报

第三层与第四层

权限这层的价值在于「降低成功后的收益」，而不是阻止成功。

监控这层，多数入侵是被日志抓到的，不是被 WAF 挡住的。

再补充几点

这几条不改变结论，但会改变你评估风险时的顺序。

• 漏洞管理的瓶颈通常不是修，而是「这一条到底影响哪个资产」说不清
• 平均修复时长要按级别分开统计，混在一起会被低危拉平看不出问题，目标按季度定更合理
• 只看扫描器分数，不看资产是否真的对外
• 工单点了已修复，没复测也没记录版本
• 所有漏洞一个截止日期，团队干脆放弃

防御的目标不是零漏洞，是让利用变得又贵又吵。