网络产品安全漏洞 对发现并通报

2023年8月，网络某安全团队在GitHub上公开了一个国产OA系统的产品0day漏洞。从提交到厂商修复，安全整整拖了47天。漏洞这47天里，现并该漏洞的通报利用代码已经在多个境外论坛流传。厂商为什么不急？网络因为压根没有强制约束。

这就是产品当下网络产品漏洞治理最拧巴的地方：发现漏洞的人不敢轻易通报，该接通报的安全人不紧不慢，而真正被漏洞威胁的漏洞用户，从头到尾不知情。现并

谁在发现，通报谁在通报

漏洞发现者大致分三类。网络第一类是产品安全公司的研究员，他们靠这个吃饭，安全通报流程相对规范。第二类是独立白帽，靠兴趣和声望驱动，通报渠道全凭运气——找得到SRC就提交，找不到就挂到推特或GitHub。第三类是黑产和境外情报机构，他们发现了不会通报，直接卖或者直接用。

问题出在第二类和第一类之间。白帽发现漏洞后，如果厂商没有公开的SRC（安全应急响应中心），或者SRC响应速度极慢，白帽就会选择公开披露。这种“被迫公开”在圈内被戏称为“按闹分配”——不公开就没人在乎。2022年，某国产数据库的漏洞就是白帽在微博上曝光后，厂商才在24小时内紧急发补丁。之前通过邮件通报，两周没回音。

通报之后，然后呢

假设漏洞成功通报给了厂商。接下来的剧本往往更让人无语。厂商内部先评估影响范围，再排期修复，最后发版本。这个过程短则一周，长则数月。期间漏洞信息在厂商内部流转，任何一个环节的疏忽都可能导致泄露。2021年，某头部社交平台的漏洞在修复前被内部人员泄露给黑产，造成大量用户数据被拖库。通报了，反而加速了泄露。

更常见的情况是，厂商修复了，但不通知用户。你用的路由器、摄像头、NAS，固件更新日志里写着“优化系统稳定性”，实际上可能修的就是一个远程命令执行漏洞。用户不知道，就不会主动升级，设备继续裸奔。厂商的逻辑是：说多了怕引起恐慌，也怕暴露自己产品有多烂。

通报机制的裂缝

国内目前没有类似美国CISA（网络安全和基础设施安全局）那样的强制漏洞通报平台。工信部有漏洞共享平台，但接入的多是运营商和大型央企。中小厂商、开源项目、个人开发者，基本靠自觉。2023年CNVD（国家信息安全漏洞共享平台）收录的漏洞中，有超过三成是“已公开”状态才被收录——意思是白帽先公开了，平台才跟进。

这就形成了一个怪圈：白帽觉得通报没用，不如公开；厂商觉得白帽公开是“黑公关”，更不愿意配合；用户夹在中间，既不知道漏洞存在，也不知道该骂谁。

一个具体的观察

我跟踪过某款国内销量很大的智能门锁的漏洞处理过程。白帽通过邮件通报，厂商安全部门回复“已收到”。三个月后，漏洞细节在境外论坛出现。白帽再去问，厂商说“正在修复”。又过了两个月，固件更新推送，但更新说明只写了“提升用户体验”。白帽在推特上吐槽，厂商公关反过来指责他“不负责任地公开未修复漏洞”。

这件事里，白帽、厂商、用户三方都觉得自己是受害者。白帽觉得厂商拖延，厂商觉得白帽添乱，用户觉得被蒙在鼓里。真正的问题不在任何一方，而在于没有一套透明的、有约束力的通报流程。谁该在什么时间点做什么，没人说得清。

能怎么办

短期看，厂商至少该把SRC的响应时间写进服务条款。48小时确认，7天给出修复计划，30天发布补丁——做不到就公开说明原因。白帽这边，可以参照Google Project Zero的90天披露政策：通报后给厂商90天，到期自动公开。这个做法有争议，但至少让各方都有预期。

长期看，漏洞通报需要法律层面的“安全港”条款。白帽善意通报漏洞，只要不利用、不扩散，就不该被厂商反手告一个“非法侵入计算机系统”。现在很多白帽不敢通报，怕的就是这个。2022年有个案子，白帽发现某政务系统漏洞后通报，结果被当地网安约谈，理由是“未经授权测试”。虽然最后没处罚，但寒了太多人的心。

漏洞不会因为你不通报就消失。它只会从白帽手里，悄悄转移到黑产手里。通报机制的意义，不是让厂商难堪，而是让用户有机会在漏洞被利用之前，把门锁上。