制度漏洞项目

去年冬天，制度我在一个做社区团购的漏洞小公司里待了三天。他们的项目财务系统有个功能：用户可以申请退款，但退款金额那一栏，制度居然可以手动输入，漏洞而且没有上限校验。项目运营小姑娘跟我说，制度有人买了三十块钱的漏洞橘子，申请退三百，项目系统照样通过，制度钱直接打到对方微信零钱。漏洞她发现的项目时候，那个人已经操作了七次。制度

这就是漏洞典型的制度漏洞——不是代码写错了，是项目规则设计时压根没想过有人会这么干。开发人员默认“用户不会乱填”，运营默认“系统会拦住”，财务默认“运营会审核”。三个默认叠在一起，就成了一个谁都不管的真空地带。

我后来跟他们的技术负责人聊，他说修这个漏洞只花了二十分钟，加一行判断就行。但发现它用了四个月。四个月里，那个用户一共薅走了八千多块。金额不大，可这件事有意思的地方在于：漏洞被发现之后，他们内部吵了一周，争论的焦点不是“怎么补”，而是“这钱该谁赔”。运营说财务没复核，财务说技术没做校验，技术说产品需求文档里没写这条规则。你看，漏洞暴露的不只是代码问题，还有组织里那些模糊的责任边界。

我见过更隐蔽的。一家做企业培训的公司，销售签单之后可以自己修改合同里的“服务期限”。本来是为了方便处理客户临时变更，结果有销售把一年的服务期改成三年，照样拿全款提成。等交付团队发现的时候，客户拿着合同要求兑现三年服务。这个漏洞在系统里躺了两年多，因为修改记录不弹窗、不通知、不审计。没人看，就等于没有。

制度漏洞有个特点：它往往不在你盯着的地方。你给收银台装了八个摄像头，后门仓库的出货单却没人签字。你给代码做了静态扫描，业务逻辑里的“合理但不合规”的操作却扫不出来。我管这个叫“灯下黑效应”——越是被默认安全的环节，越容易出事。

还有个案例挺荒诞。某地政务系统里，办居住证需要上传租房合同，但系统不验证合同真伪，也不跟房管局数据打通。结果有人用同一份合同给二十多个人办了证。后来是被一个片警发现的，他辖区里突然多出十几个“同住”的陌生人。这个漏洞的技术修复方案很简单，接口对接就行。但拖了三年没做，原因是“涉及跨部门协调”。你看，制度漏洞有时候不是技术问题，是人的问题——谁都不愿意多干那一步。

我自己的观察是，大部分制度漏洞的寿命都比想象中长。因为发现它需要运气，承认它需要勇气，修补它需要跨过部门墙。而利用它的人，往往比设计它的人更懂规则。他们不破坏系统，只是在系统的缝隙里跳舞。你甚至不能说他们违法——他们只是做了规则允许、但设计者没想到的事。

回到那个社区团购公司。最后他们没报警，也没让员工赔，只是把漏洞补了，然后加了一条新规：任何退款超过订单金额的，自动触发人工审核。那个运营小姑娘跟我说，新规上线后，她每天要多点二十几次“通过”。但她觉得踏实。“至少我知道钱是怎么出去的。”她说。

这句话我记了很久。制度漏洞的本质，可能就是“你不知道钱是怎么出去的”——不管是真金白银，还是信任、权限、责任。补漏洞不难，难的是让所有人看见那个洞。