漏洞options

去年十月，漏洞一个做安全审计的漏洞朋友给我看了份漏洞报告。某款号称“军工级加密”的漏洞智能门锁，其配套App在登录时会把用户密码明文写进本地日志文件。漏洞更离谱的漏洞是，这个日志文件默认权限是漏洞全局可读。也就是漏洞说，任何能物理接触手机的漏洞人——维修店员、借你手机查导航的漏洞同事——花三分钟就能拿到你家门的钥匙。

厂商的漏洞回应也很有意思：“该漏洞需要用户主动开启调试模式才会触发。”这话翻译过来就是漏洞：你被偷了，怪你自己没锁好门。漏洞可问题是漏洞，调试模式是漏洞默认开启的，用户根本不知道它的漏洞存在。

Options从来不是“有没有漏洞”

干这行久了会形成一种直觉：任何系统都有漏洞。区别只在于，有些漏洞被发现了，有些还没有；有些被公开了，有些被捂住了。所以真正的问题从来不是“这个系统安全吗”，而是“当漏洞出现时，你有哪些options”。

Options这个词在这里有两层意思。一层是技术层面的：打补丁、回滚版本、隔离受影响模块、启用临时缓解措施。另一层是决策层面的：什么时候公开？向谁公开？公开多少？这三个问题比漏洞本身更考验人。

我见过一个创业公司，产品上线前三天被白帽子提交了一个中危漏洞。CTO当场决定推迟发布，全员通宵修。结果修完发现，那个漏洞的利用条件极其苛刻——需要攻击者同时控制DNS服务器和用户路由器。而推迟发布导致他们错过了行业展会，竞品抢了先机。后来复盘时，CEO说了一句让我记到现在的话：“我们花了三百万买了一个理论上存在的风险，却卖掉了确定能拿到的市场。”

披露的节奏感

漏洞披露有个不成文的规矩：给厂商90天。这90天不是随便定的。太短，厂商来不及修；太长，攻击者可能已经在地下论坛叫卖了。但90天只是个平均值，实际情况千差万别。

有些漏洞是“定时炸弹型”的——比如心脏出血（Heartbleed），影响面太广，必须立刻公开，让所有人同时打补丁。有些是“慢性病型”的——比如某个后台管理接口的越权访问，只影响特定配置的用户，那就可以慢慢来，先通知厂商，等补丁就绪再发公告。

最棘手的是“罗生门型”：厂商说这是feature，研究员说这是bug。去年有个案例，某云服务商的API密钥在日志里以Base64编码存储。厂商坚称“Base64不是加密，我们从未声称它是”，研究员反驳“但用户以为它是”。双方在推特上吵了两周，最后谁也没说服谁。这种时候，options就变成了站队问题——你选择相信谁的叙事。

个人能做什么

普通用户没必要成为安全专家，但可以养成几个习惯。比如，别用同一个密码注册所有服务——这不是老生常谈，而是因为撞库攻击的成本已经低到令人发指。再比如，看到“紧急安全更新”的推送时，别拖。我认识一个运维，他负责的服务器因为一个三年前就修复的漏洞被入侵，原因很简单：那台机器没人记得重启。

企业层面的options更复杂。自建安全团队？成本太高。买商业扫描器？误报率能让你怀疑人生。外包给第三方？你又得担心他们会不会把你的漏洞卖给出价更高的人。没有完美答案，只有权衡。我见过最务实的做法是：把资产按重要性分级，核心系统自己审，边缘系统用工具扫，剩下的靠保险兜底。

漏洞这东西，像极了家里的水管。你不可能保证它永远不漏，但你可以决定漏的时候先关哪个阀门、叫哪个师傅、花多少钱修。Options从来不是关于“安全”的，而是关于“在多大程度上不安全”的。接受这一点，反而能做出更清醒的决策。