“弥补漏洞”和“填补漏洞”，弥补听起来像是漏洞一回事。但仔细想，还填这两个词指向的补漏动作逻辑完全不同。弥补，弥补是漏洞把已有的破损处修复到能用的状态；填补，是还填把原本空缺的位置塞进东西。一个针对的补漏是“坏了”，一个针对的弥补是“缺了”。绝大多数人在实际工作中，漏洞根本没分清这两者。还填

去年我参与过一个后台系统的补漏权限模块重构。上线三个月后，弥补安全团队报了一个越权访问的漏洞问题：普通用户可以通过修改URL参数看到其他用户的订单详情。团队里的还填第一反应是“赶紧修”。于是有人在接口层加了一段判断——当前登录用户ID与请求参数中的用户ID不一致时，返回403。代码合并，测试通过，上线。漏洞被“弥补”了。

但两周后，同一个模块又出了新问题。这次是导出功能，同样能拉到别人的数据。原因很简单：导出接口走的是另一条链路，压根没经过那个判断。之前那次修复，只是在一条路上设了卡，其他路照样畅通。这就像发现墙上有个洞，拿块木板钉上去，却没检查墙是不是还有别的裂缝，或者这面墙本身就没砌完整。

这时候我才意识到，那个越权问题不是“漏洞”，而是“缺口”。漏洞是系统本来有防护，但防护失效了；缺口是系统在设计时就没把这块纳入防护范围。前者需要弥补，后者需要填补。把缺口当漏洞来补，结果就是打地鼠——冒一个打一个，永远打不完。

区分这两者有个很实用的判断方法：问一句“这里原本有没有做防护的意图”。如果代码里能看到开发者试图校验权限、过滤参数、限制频率，只是逻辑写错了或者被绕过了，那是漏洞。如果那段代码里压根没有任何相关处理，空白一片，那就是缺口。前者的修复是纠正，后者的修复是补全。纠正可以局部动刀，补全往往需要重新审视整个设计。

我见过更典型的例子。一个电商团队发现优惠券可以被重复领取。查代码，发现领取逻辑里有个判断：用户已领取数量大于等于限领数时拒绝。看起来没问题。但并发请求下，两个线程同时读到“已领取0张”，都通过了判断，都执行了插入。这是漏洞——有防护意图，但防护有缺陷。修复方式是加锁或改原子操作。同一个系统里，另一个问题是：分享链接的奖励金没有做任何防刷机制，用户自己点自己的链接也能拿钱。这不是漏洞，这是缺口。设计时就没想过“有人会自己点自己”。填补它需要引入设备指纹、行为分析、风控规则，是一整套东西。

很多团队把这两类问题混在一个流程里处理，用同一个“修复-测试-上线”的循环去应对。结果就是缺口永远补不完，漏洞反复出现。更麻烦的是，当缺口被当成漏洞“弥补”之后，它会给人一种“已经修好了”的错觉。实际上只是把最明显的那个入口堵上了，旁边的窗户还开着。

我的判断是：面对一个安全问题，先别急着写修复代码。花十分钟翻一翻相关模块的设计文档和代码历史。如果发现防护逻辑从来就没存在过，那就别用“弥补”的思路去应付，老老实实承认这是个设计缺口，从需求层面重新评估。弥补漏洞是战术动作，填补缺口是战略动作。搞混了，付出的代价不是多写几行代码，而是永远在救火。