2023年某天，网络一位安全研究员在某个电商平台的安全支付接口里发现了一个逻辑漏洞——通过修改订单金额参数，可以把1999元的漏洞商品改成1元下单。他花了二十分钟写了份报告，上报提交给平台SRC。管理三天后收到回复：“经评估，网络该问题风险较低，安全暂不处理。漏洞” 又过了两周，上报这个漏洞在暗网上被人标价出售。管理平台连夜发补丁，网络但损失已经产生了。安全

这种事不是漏洞孤例。漏洞上报这条链路，上报远比大多数人想象的管理脆弱。发现漏洞的人、接收漏洞的人、修复漏洞的人，三方之间只要有一环掉链子，整个安全防线就等于纸糊的。

上报渠道：别只留一个邮箱

很多企业官网底部挂一个 security@xxx.com 就觉得自己尽到责任了。实际上这个邮箱可能半年没人看，或者被当成垃圾邮件自动过滤。我见过一家公司的安全邮箱，发过去的漏洞报告石沉大海，后来一问，那个邮箱的负责人早就离职了，账号还在但没人接管。

靠谱的做法是至少提供两条路径：一个专用的漏洞提交平台（比如基于开源的缺陷管理系统的定制页面），加上一个应急联系人的即时通讯方式。平台的好处是自动记录时间线，谁在什么时候看了、回复了什么，都有据可查。即时通讯则用于紧急情况——比如正在被利用的0day。

另外，别搞那种“仅限注册用户提交”的门槛。白帽子未必想在你的平台上注册账号，填一堆个人信息。越简单的提交入口，越容易收到真实报告。

收到报告之后，先别急着下结论

开头那个案例里，平台犯的错是把“风险低”当成了“不用管”。逻辑漏洞单看危害确实不如远程代码执行那么炸裂，但它可以被批量利用。一个1元下单的漏洞，如果脚本一跑，十分钟能下几千单。

收到报告后的第一件事不是评估，是确认收到。哪怕你还没看懂，也先回一句“已收到，正在核实”。白帽子最怕的不是被拒绝，是沉默。沉默意味着他不确定你有没有看到，于是可能把漏洞公开到推特上，或者卖给中间人。

核实阶段要拉上真正懂业务的人。安全团队觉得“只是个越权查看订单”，业务团队可能知道那个订单里包含用户身份证号。视角不同，定级天差地别。

修复和反馈：别让白帽子寒心

修复周期拉得太长是常态。一个中危漏洞从确认到上线补丁，走完流程花两个月不算稀奇。但至少要做到两点：一是给白帽子一个预期时间，比如“预计两周内修复”；二是修复上线后主动通知他，别让他自己来问。

积分和奖金当然重要，但更关键的是态度。我认识一个白帽子，他给某大厂报了六个漏洞，每个都认真写了复现步骤和修复建议。结果六个里有四个被标记为“重复”，两个被标记为“不接收”。他后来再也不给那家厂商报漏洞了。而那些被他漏掉的漏洞，最终出现在了别人的报告里——带着更高的标价。

漏洞上报管理不是什么高深的技术活，它更像是一种信任维护机制。你认真对待每一份报告，白帽子就愿意继续帮你守门。你敷衍一次，可能就永远失去了一个免费的守夜人。

那个电商平台后来改了流程，现在他们的SRC页面写着“24小时内必回复”。但愿这次是真的。

(责任编辑：综合)