一句话总结

Snapchat 12.4 中重构的 Keymaster 检查没有被我们的自动差分捕捉到，因为改动在原生库里而不是 Java 类里。人工刻画耗时 34 小时，客户共丢失 1,847 个账号，全部返还并重建，成本约 9.1 万美元。此后我们在金丝雀流水线中加入了原生库差分与持续 Keymaster 模糊测试。

发生了什么

Snapchat 12.4.1 于 2025 年 11 月 14 日 UTC 09:12 发布，我们的爬虫 09:19 抓到。自动差分 10:04 完成，报告无重大变化——11 个 Java 类被修改，全部在无关包中。

改动在 libsnapattest.so 这个原生库里。我们当时的差分流水线只比对反编译后的 Java 与字符串表，不反汇编原生库。所以我们什么都没看到，直到 21:40 客户开始报封号，才启动人工排查。

时间线

时间（UTC）事件
11 月 14 日 09:12Snapchat 12.4.1 发布
11 月 14 日 09:19爬虫抓取
11 月 14 日 10:04自动差分报告无重大变化
11 月 14 日 21:40首批客户封号报告
11 月 14 日 23:15宣布事故，启动人工排查
11 月 15 日 14:20定位到原生库为改动面
11 月 16 日 08:50完成新 Keymaster 检查的刻画
11 月 16 日 19:30补丁构建并通过回归测试
11 月 16 日 22:15全量 OTA 完成

影响

  • 312 位客户共 1,847 个 Snapchat 账号被封。
  • 其他平台未受影响。无数据丢失，无服务中断。
  • 所有受影响的设备月费按 Ban Shield 条款返还，所有身份免费重建。
  • 轨云直接成本：返还与工程投入约 9.1 万美元。

根本原因

差分流水线存在覆盖盲区。我们 2023 年建它时，认证逻辑还在 Java 里；2025 年初 Snap 把它挪到原生代码之后，我们从未重新审视这个假设。这是一次很直白的工程失误，责任在我们。

我们改了什么

  1. 自动差分加入原生库反汇编，覆盖全部 27 个追踪应用。
  2. 金丝雀流水线加入持续 Keymaster 模糊测试——我们现在每 4 小时用已知检测模式语料库探测一次自己的认证面。
  3. 封号报告阈值告警：60 分钟内出现 5 条同类报告即直接呼叫值班工程师，不再经过客服分派。
  4. Ban Shield 保障从 Scale 扩展到 Growth——因为受影响最重的客户在 Growth 套餐，当时并不在保障范围内。我们仍然追溯给了补偿。

接入原生差分后，我们用当前流水线重跑了 v3 那次发布。检测会在 T+1:10 触发，补丁大约 18 小时内发出。

我们公开难看的数据，因为不这么做的话，就等于要求你凭信仰相信好看的那些。