去年秋天，公开我帮一家做电商SaaS的漏洞小公司排查漏洞。他们的测试技术负责人递过来一份“渗透测试授权书”，上面写着允许对生产环境做公开漏洞测试。公开我问他，漏洞你知道这六个字在法律上意味着什么吗？测试他愣了一下，说“不就是公开扫扫漏洞吗”。

问题就出在这。漏洞公开漏洞测试，测试重点不在“测试”，公开在“公开”。漏洞一旦你把测试目标、测试方法、公开甚至部分结果放到公开渠道，漏洞性质就变了。测试很多团队栽跟头，不是因为技术不行，是因为没搞清这条线。

我见过最离谱的案例，是某安全团队在GitHub上开了一个repo，专门记录他们对某政务云平台的漏洞挖掘过程。每发现一个SQL注入，就提交一次commit，附带截图和payload。三天后，当地网信办直接找上门。团队负责人还辩解：“我们没利用漏洞，只是记录。”记录本身就把未修复的漏洞细节公开了，等于给黑产递刀子。

公开漏洞测试有一个基本前提：你得先确认目标资产的所有者书面同意你“公开”。注意，是同意公开，不是同意测试。这两份授权书差别巨大。测试授权只允许你在限定范围内操作，公开授权则涉及信息披露的时机、范围、脱敏程度。大多数甲方签的合同里，只写了前者。

那是不是完全不能做公开测试？也不是。开源项目就是典型场景。Linux内核、Apache这些，漏洞邮件列表本身就是公开的。但人家有成熟的协调披露机制——先私下报告给维护者，给90天修复期，到期再公开细节。你直接往推特上发0day，那不叫测试，叫勒索。

我自己的做法是：任何涉及生产系统的测试，先签三份东西。测试授权书、数据处理协议、公开披露范围确认函。第三份最容易被忽略。里面要写清楚：哪些信息可以公开、什么时候公开、公开前是否需要甲方二次确认。有一次甲方法务把“公开”改成了“内部通报”，我直接拒了那个项目。因为对方想让我免费挖洞，还不让说。

技术层面也有坑。公开测试经常用到自动化扫描器，比如Nuclei、Xray。这些工具会留下大量请求日志。如果你在公开的CI/CD流水线里跑扫描，日志会被推到公开的构建记录里。攻击者不需要自己扫，翻你的日志就能拿到漏洞指纹。我见过一个团队把扫描结果直接输出到GitHub Actions的artifact里，任何人都能下载。这相当于把钥匙插在门上，还贴了张纸条说“欢迎光临”。

另一个细节是时间戳。公开测试报告中如果包含精确到秒的请求时间，攻击者可以结合目标系统的日志规律，推断出维护窗口。我通常会建议客户把时间戳模糊到小时级别，或者直接去掉。有人觉得这是小题大做，直到他们被人在凌晨三点精准打穿。

说回开头那家SaaS公司。我最后没签那份授权书，因为他们的法务坚持要在报告里附上完整的请求响应包。我给他们讲了一个真实案例：某白帽子公开了某OA系统的未授权访问漏洞，附了完整的HTTP请求。三天后，全网出现批量利用脚本。那个白帽子被公司开除，还赔了钱。法务听完，沉默了一分钟，然后把“公开”两个字从合同里删了。

公开漏洞测试不是不能做，但得明白：你公开的每一个字节，都可能变成别人手里的武器。授权书上的每一个字，都值得你逐字读三遍。别等到网信办打电话来，才想起自己忘了看合同附件。