内容摘要：安全圈子里有个老规矩：发现漏洞先闷声报给厂商，等补丁上线了再公开细节。这套流程叫“负责任披露”，听起来很完美，直到你遇上那种三个月都不回邮件的厂商。 去年我参与过一个开源项目的漏洞测试。那是个被几百家

安全圈子里有个老规矩：发现漏洞先闷声报给厂商，开展等补丁上线了再公开细节。活动这套流程叫“负责任披露”，向社听起来很完美，布系直到你遇上那种三个月都不回邮件的统漏厂商。

去年我参与过一个开源项目的开展漏洞测试。那是活动个被几百家公司用着的库，我们挖到一个能直接拿到服务器权限的向社洞。按规矩发邮件，布系对方项目组两周后回了句“知道了”，统漏然后就没下文了。开展又过了三周，活动我同事在技术群里看到有人讨论这个库的向社异常流量——已经有黑产在用了。我们手里攥着完整的布系利用代码，厂商却还在排期修一个“低优先级”的统漏bug。

这时候你怎么办？继续等？等来的可能是大规模数据泄露的新闻头条。

所以我们干了件有点出格的事——直接办了一场公开的漏洞演示活动。场地就在一个社区咖啡馆，拉了块幕布，投影仪接上笔记本，现场演示如何通过那个漏洞读取服务器上的配置文件。台下坐着三十多个开发者，一半是那个项目的用户，另一半是来看热闹的。演示到一半，有人当场在群里@了项目维护者，说“你们看这个”。维护者半小时后就打来了电话，语气从“你们想干嘛”变成了“我们马上修”。

这就是公开披露的威力。它不是把漏洞扔到推特上任人围观，而是把技术细节摆到受影响的人面前，逼着他们做出选择。厂商的不作为，本质上是在赌没人会发现——而公开活动直接掀了这张赌桌。

当然，这么做有代价。那次活动之后，我们被某些“安全正统派”骂了，说我们破坏行业规矩。但骂我们的人没看到的是，那个漏洞在活动结束后的第三天就出了补丁——比厂商原计划提前了整整两个月。两个月，足够黑产把几万台服务器洗一遍。

公开披露不是目的，是手段。它应该被用在那些沟通失效、厂商装死、或者漏洞影响面已经失控的场合。安全研究员的职责不是当厂商的免费外包，而是保护最终用户。如果私下沟通这条路走不通，那就把问题摆到阳光下——让用户自己决定要不要继续用这个产品，让厂商面对他们本该面对的问责。

那次活动之后，我养成了个习惯：每次发现漏洞，先看厂商的响应速度和历史记录。那些对安全问题敷衍了事的，我会直接跳过私下沟通环节，把报告写好，然后找个合适的公开场合放出来。不是我不讲规矩，而是规矩得对双方都有效才行。

现实点说，公开披露就像核威慑——你得让对方相信你真的会用，谈判才有意义。而真正按下按钮的时候，务必确保你的技术分析足够扎实，演示环境足够真实，不然丢人的是你自己。