代码评审会上，查漏老张盯着屏幕看了足足三分钟，洞方的问最后指着第47行说：“这里，面存空指针。查漏”会议室里没人吭声，洞方的问因为大家都知道，面存这个问题在测试环境已经出现过三次了。查漏查漏洞这件事，洞方的问最讽刺的面存地方在于——我们总是在找别人留下的坑，却对自己刚挖的查漏坑视而不见。

查漏洞的洞方的问第一道坎，是面存“查”的方式错了。很多人抱着“扫一遍”的查漏心态，拿工具跑一圈，洞方的问输出一份报告，面存然后对着高危漏洞截图发群里，这事就算完了。工具确实能扫出已知的CVE，但业务逻辑里的漏洞它看不见。我见过一个支付系统，开发把优惠券金额做了负数校验，却忘了校验购买数量——结果有人用-1件商品把账户余额刷爆了。这种漏洞，工具永远发现不了，因为它藏在代码的“意图”里，而不是“语法”里。

第二道坎更隐蔽：查漏洞的人，往往和写漏洞的人是同一批。自己写代码自己审，就像自己出题自己考，大脑会自动跳过那些“我知道这里没问题”的惯性区。有个团队做过实验，让开发者互审彼此的代码，结果发现的漏洞数量比自审高出40%——不是技术变强了，是视角变了。人类的大脑天生会为自己的决策辩护，这是本能，不是态度问题。

第三道坎，是查完之后的处理方式。漏洞报告写得像天书，全是CVSS分数和技术术语，业务部门看不懂，管理层觉得“反正没出事”。于是漏洞躺在Jira里，优先级从P0一路降到P3，最后被归档为“已知问题”。我认识一个安全工程师，他花了三周追一个反序列化漏洞，修复方案都写好了，结果产品经理说“这个功能下个季度要重构，先别改了”。三个月后，那个漏洞被勒索软件利用了。

还有个更让人头疼的现象：查漏洞变成了“表演”。为了应付等保检查，有些团队会在检查前突击补洞，把日志里的报错清空，把临时补丁打上，等检查组走了再回滚。这种操作，说难听点，就是给房子刷漆——墙里的电线都烧焦了，表面看着光鲜就行。可漏洞这东西，它不看你表演，它只看你代码里有没有后门。

说到底，查漏洞的问题不在技术，而在机制。工具能扫出已知的坑，但扫不出未知的坑；代码评审能拦住低级错误，但拦不住逻辑盲区；漏洞报告能记录问题，但推动不了修复。真正的漏洞，往往不是代码里的bug，而是流程里那些“没人负责”的灰色地带——比如测试环境和生产环境配置不一致，比如离职员工的账号三个月后才被禁用，比如第三方库的许可证过期了没人管。

我最后想说个具体的事。去年有个系统上线前做渗透测试，测出个中危漏洞——文件上传接口没限制类型。开发说“这个接口只有内部工具在用”，运维说“防火墙能挡住外网”，安全说“先上线吧，下个迭代修”。结果上线第二天，有人用这个接口传了个webshell，整个数据库被拖走。后来复盘时发现，那个“内部工具”的地址，早就被写在某个公开的GitHub仓库里了。

查漏洞最难的，从来不是找到漏洞，而是承认漏洞可能就在你眼皮底下——而且你正忙着解释它为什么不算漏洞。