低危漏洞为什么没有修复的必要

去年年底，低危的必我帮一个做电商的漏洞朋友看他们公司的漏洞修复流程。扫描报告拉出来，修复高危漏洞十几个，低危的必中危几十个，漏洞低危那一栏密密麻麻，修复三百多条。低危的必他问我：“这些低危的漏洞，是修复不是可以不管？”我说你先别急，我看看具体是低危的必什么。翻了十几页，漏洞大部分是修复“HTTP响应头缺少X-Content-Type-Options”“Cookie未设置Secure属性”“服务器版本信息泄露”这类东西。我合上报告跟他说：这三百多条里，低危的必真正值得动手的漏洞，大概不超过五条。修复

这不是个例。几乎所有做过漏洞管理的人都会走到同一个结论：低危漏洞的修复优先级，应该无限趋近于零。原因不复杂，但值得掰开说。

低危漏洞的定义本身就决定了它的尴尬位置。CVSS评分在0.1到3.9之间，意味着利用条件苛刻、影响范围有限、或者需要攻击者已经具备相当程度的访问权限。一个需要本地物理接触才能触发的信息泄露，和一个远程未授权就能拿shell的高危漏洞，放在同一张表里用同样的流程去管理，本身就是资源错配。

我见过太多团队把大量精力花在“清零”低危漏洞上。每周安全例会，负责人盯着那几百条低危项，要求开发排期修复。开发那边本来就人手紧张，业务需求压得喘不过气，结果被拉去改Cookie属性、加响应头。改完一轮，扫描器再跑，又出来一批新的。循环往复，安全团队觉得自己在干活，开发团队觉得在浪费时间，两边都累。

更关键的是，低危漏洞的修复往往伴随着不成比例的风险。改一个全局的HTTP安全响应头，可能影响CDN缓存策略，可能让某些老旧的内部系统调不通接口。加一个Cookie的Secure标记，如果测试环境没同步配好HTTPS，登录直接挂掉。这些改动本身引入的故障概率，未必比那个低危漏洞被利用的概率低。安全圈有句话：每一次变更都是一次潜在的故障注入。为了修一个CVSS 2.5的漏洞，搭进去半天排查线上问题，这笔账怎么算都不划算。

有人会说，那万一低危漏洞被组合利用呢？理论上当然存在这种可能。但组合利用的前提是攻击者已经突破了外层防御，拿到了某个入口。到了那个阶段，你缺的从来不是那一个低危漏洞的修复，而是整体纵深防御的缺失。把低危漏洞当成必须堵上的口子，是一种安全上的洁癖，不是务实。

我自己的做法是：低危漏洞只做分类，不做排期。把那些真正有实际利用场景的挑出来——比如某个接口确实会返回敏感信息、某个配置确实能被外部直接读取——单独评估。剩下的，记录在案，接受风险，定期复审。这不是偷懒，是把有限的安全资源投向真正能降低风险的地方。

安全管理的本质是风险管理，不是漏洞清零。一个团队如果能把所有高危和中危漏洞的修复周期控制在两周以内，它的安全水位就已经超过绝大多数公司了。至于那三百条低危，让它们安安静静躺在报告里，天塌不下来。

本文地址：http://www.79wt.cn/news/474d9899427.html