上周帮朋友公司做安全巡检，漏洞他们研发主管指着一份漏洞报告问我：“这上面全是扫描低危，加起来快三十条了，低危到底修不修？求修”我看了眼报告，SQL注入的漏洞预编译已经做了，剩下的扫描多是CSP头没配、X-Content-Type-Options缺失这类“小毛病”。低危他补了句：“领导说了，求修低危不用管，漏洞等下次大版本一起处理。扫描”

这话我听了不下百次。低危但低危漏洞真能攒着吗？求修拿CSP头举例——它确实拦不住直接攻击，可一旦某天你们某个前端库被投毒，漏洞或者某个老接口被人摸到反射型XSS，扫描CSP就是低危那道“最后防线”。防线平时看着没用，塌的时候才知道疼。

另一个现实问题：漏洞报告不是考试卷，错了只扣分。它更像体检单，低危项可能是高血压的前兆。我见过一个案例，某公司连续两年忽略一个“低危”的信息泄露漏洞——某个调试接口返回了完整的内存转储——结果第三年有人利用这个接口拿到了管理员session，整个后台被拖库。事后复盘时，那个漏洞在最初报告里确实只标了“低危”。

当然，我不是说所有低危都得立刻修。你得看业务场景。纯内网系统、无敏感数据、且物理隔离的，低危可以拉长修复周期，甚至接受风险。但凡是暴露在公网、涉及用户数据或支付流程的，哪怕一个“低危”的跨域配置错误，都值得当天处理。成本其实不高——改一行nginx配置的事，比年底应付等保检查时手忙脚乱强。

还有个容易被忽略的点：漏洞扫描器的“低危”判定标准参差不齐。有些扫描器把“检测到服务器版本号”都算低危，这种确实可以忽略。但另一些低危，比如“允许TLS 1.0”，在合规审计里会被直接放大成严重问题。你等得起，等保测评等不起。

我的建议很简单：别按“危”字分级一刀切。先花十分钟看每条低危的描述，凡是涉及“信息泄露”“配置错误”“加密强度不足”的，顺手修掉。凡是“版本号暴露”“Banner抓取”这类纯信息收集的，可以记入技术债。但记住，技术债有利息——等某天你们接入第三方支付或过等保时，这些低危会集体变成“整改项”，那时你加班改的每一行，都是在还当初偷的懒。

说白了，修低危不是技术问题，是态度问题。你对待小漏洞的态度，决定了攻击者对待你系统的“耐心”。