开展什么等活动向社会发布系统漏洞

很多厂商到现在还把漏洞当作家丑，开展捂着盖着生怕外人知道。活动结果呢？向社攻击者比用户先拿到细节，补丁还没影，布系利用代码已经在暗网叫卖了。统漏2021年Apache Log4j那个核弹级漏洞就是开展活教材——最早发现的研究团队按流程报了，可厂商动作慢，活动信息在圈内小范围传开，向社等官方公告出来时，布系全球已经有数百万台服务器被扫描。统漏所以问题根本不是开展“要不要公开”，而是活动“用什么方式公开”。

我见过最有效的向社一种做法，是布系搞“漏洞披露协调会”。听着像开会，统漏其实更接近一种带监督的谈判。安全研究员、厂商代表、CERT（计算机应急响应团队）的人坐一屋，研究员先讲漏洞怎么复现、影响范围多大，厂商当场给时间表。如果厂商耍赖说“三个月修不了”，CERT直接介入，定一个强制披露日期。这个机制逼着厂商动起来，也给了他们准备补丁的缓冲期。微软、谷歌这几年能比较顺畅地处理大量高危漏洞，跟这套流程成熟有很大关系。

还有一类活动叫“漏洞赏金日”，但别误会成那种常年开放的众测。我指的是集中式的、带媒体曝光的发布活动。比如某家云厂商选一个周五下午，把过去半年里积压的、已经修复完毕的漏洞清单一次性挂出来。每个漏洞配一段简短的技术描述，再加一个“致谢名单”——谁报的、什么时候报的、修复用了多少天。这招挺损的，等于把厂商的响应速度公开处刑。慢的会被社区骂，快的能赚口碑。我印象很深的是，有个做IoT摄像头的小厂，原本修漏洞拖了200多天，被公开致谢名单里“修复耗时”一栏标红之后，下一个季度的平均修复时间直接压到40天以内。面子比罚款管用。

更硬核的玩法是“漏洞马拉松”。一群安全研究员聚在一个物理空间里，连续48小时挖某个开源项目的漏洞。挖到之后不是私下交，而是现场写报告、现场验证、现场录入公共漏洞库。主办方会请项目维护者在线待命，能当场修的就当场合入代码。这种活动最大的价值是透明——所有过程直播，谁也别想暗箱操作。去年有个Linux内核的漏洞马拉松，一个研究员发现某驱动模块的释放后重用问题，从确认到提交补丁只用了6个小时。换作传统流程，光邮件列表来回扯皮就得一周。

当然，不是所有漏洞都适合大张旗鼓。涉及关键基础设施的，比如电网、医院系统，公开细节等于给攻击者递刀。这时候更合适的是“受限披露”：只向特定厂商联盟发布，附带法律约束。但即便是这种，也得有第三方监督，否则厂商很容易把“受限”变成“永不公开”。我认识一个做工控安全的朋友，他们发现某品牌PLC的认证绕过漏洞，报给厂商后对方要求签保密协议、无限期不公开。他们没签，转头把漏洞细节发给了ICS-CERT，由后者协调多个受影响厂商统一发补丁。虽然过程慢，但至少用户拿到了修复方案。

说到底，漏洞披露不是道德表演，而是一场跟攻击者抢时间的工程。发布活动的形式可以多样——协调会、赏金日、马拉松、受限联盟——但核心就两条：给厂商压力，给用户信息。缺了前者，漏洞会被埋；缺了后者，用户连自己怎么死的都不知道。