为什么你扫出来的漏洞，开发总说“修不了”？

原创

北京昊网
北京昊网

北京昊网网络安全与数字化服务

2026年10月10日 07:00
北京

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

关注公众号，共话网络空间安全。

做安全的人，几乎都遇到过这个场景。

你扫出来一个漏洞，整理好报告，标好风险等级，附上修复建议，发给开发。开发看了一眼，回你一句：“这个修不了。”

你追问为什么，他给你几个理由：业务逻辑就是这样设计的；改了会影响其他功能；这个版本太老了，升级不了；老板要求先保业务，安全的事往后放。

你觉得他在推诿，他觉得你在找麻烦。两边都不痛快。

这个问题，表面上是沟通问题，实际上是认知问题。安全和开发对“漏洞”这件事的理解，根本不在一个频道上。

今天把这件事拆开讲清楚。

一、开发和安全的视角，差在哪里？

开发看一个漏洞，看的是“修它的成本”。

改一行代码，要重新测试、重新上线、重新验证。这个过程中，可能会引入新的bug，可能会影响其他功能，可能会耽误项目进度。如果这个漏洞在开发看来“没那么严重”，那他的第一反应就是——能不能不修。

安全看一个漏洞，看的是“被利用的风险”。

这个漏洞能不能被利用？利用之后能造成多大影响？有没有已知的攻击案例？有没有外部攻击者在扫描这个漏洞？

两个视角都有道理，但关注点完全不同。开发关注的是当下的交付，安全关注的是未来的风险。风险是概率，交付是确定的。在确定性和概率之间，大部分人会优先保确定性。

所以开发说“修不了”，很多时候不是真的修不了，是他算了一笔账，觉得修的代价比不修的风险更大。

二、开发说“修不了”，通常有四种情况

第一种：真的修不了。

比如系统是十年前采购的，用的是已经停止维护的框架，厂商都不在了，补丁也没地方打。比如业务逻辑就是允许用户上传文件到服务器，你让他禁止上传，业务就废了。

这种情况，不是开发不想修，是客观上没有修复条件。

第二种：不知道怎么修。

你告诉他“存在SQL注入”，他知道要修，但不知道具体怎么改。你告诉他“要做参数化查询”，他可能没写过，或者用了ORM框架不知道怎么处理。你告诉他“要加CSRF Token”，他可能不理解原理，不知道加在哪里。

这种情况下，开发不是不配合，是你的修复建议不够具体，他不知道怎么落地。

第三种：觉得不值得修。

你报了一个中危漏洞，他评估了一下：这个漏洞利用条件苛刻，需要攻击者先拿到内网权限，而我们已经有网络隔离了，所以风险可控。他算完这笔账，觉得修它的性价比不高，所以往后排。

这种判断，在有些场景下是合理的，在有些场景下是侥幸。关键在于，他有没有把这个判断和风险说清楚，而不是简单一句“修不了”。

第四种：不想修。

这种情况也存在。有些人就是嫌麻烦，觉得安全的事是额外负担，能拖就拖，能推就推。

但这种情况，往往是因为你在他的认知里，是一个“只会提问题的人”，不是一个“能帮他解决问题的人”。

三、怎么让开发愿意修？

第一步：把漏洞讲清楚，不要只给一个“高危”。

开发最烦的，就是你给一个红彤彤的“高危”，但说不清楚到底怎么回事。

你需要告诉他：这个漏洞在哪里，攻击者怎么利用，利用成功之后能拿到什么，现实中有没有类似的攻击案例。最好能复现一遍，把复现过程录下来，让他直观地看到问题。

“你的登录接口存在SQL注入，攻击者可以绕过密码验证直接登录管理员账号，我演示了一遍，你看这个视频。”

这比你发一份扫描报告里的“SQL注入 高危”有用得多。

第二步：把修复方案写具体，不要只给一个方向。

你告诉他“要修复SQL注入”，这是方向。你告诉他“在某个文件的某一行，把拼接SQL改成PreparedStatement，这是修改前后的代码对比”，这是方案。

开发需要的是可执行的方案，不是正确的废话。你能把方案写到他能直接照着改的程度，他修起来的阻力就小了一大半。

第三步：帮他算清楚风险，不要只讲“安全要求”。

开发关心的是交付，你跟他讲“这不符合安全规范”，他没有感觉。你跟他讲“这个漏洞如果被利用，业务数据泄露，公司被监管处罚，项目组要背责任”，他就有感觉了。

把漏洞和业务影响、合规风险、公司代价挂上钩，他才会真正重视。

第四步：在他忙的时候帮他一把。

如果修复确实需要时间，而你又能提供一些临时缓解措施——比如加一条WAF规则、调整一下访问控制策略、加一段监控——这些可以帮他争取时间，也让他看到你在帮他解决问题，而不是只给他派活。

四、有些漏洞确实修不了，怎么办？

不是所有漏洞都能修。遇到确实修不了的，不要卡在那里反复催，而是要换一种思路。

第一，评估风险，给出补偿性措施。

漏洞修不了，但风险可以管。加WAF规则拦住攻击流量，做网络隔离限制影响范围，加强日志监控确保一旦被利用能第一时间发现。这些补偿性措施虽然不如根治，但能把风险降到可接受的范围。

第二，写清楚风险，让业务方确认。

你不能替业务方做决定。把漏洞的风险、影响、补偿措施写清楚，提交给业务方确认。如果他们决定接受这个风险，那就让负责人签字确认。这样出了问题，责任是清晰的。

第三，纳入长期规划。

有些漏洞现在修不了，不代表永远不修。把它记下来，纳入长期的安全建设规划。等系统升级的时候、等业务重构的时候，一并解决。

五、总结

开发说“修不了”，不一定是真的修不了，往往是修复的成本和风险没有被算清楚。

作为安全工程师，你的价值不是“发现问题”，而是“推动问题被解决”。

把漏洞讲清楚，把方案写具体，把风险算明白，把障碍帮开发搬开。做到这几点，开发再说“修不了”的时候，你们两个就可以坐下来，认真讨论一个双方都能接受的方案。

安全不是安全团队一个人的事。让开发愿意配合你，本身就是安全工程师的核心能力之一。

学网络安全，找北京昊网，就业薪资有保障，带你刺年薪，10-40万！

详细咨询：黎歌｜18500324210（同微信）

签订《就业服务协议》，未达成就业标准，全额退费。