审计报告：范围、方法、发现与整改

审计报告最容易造成的误解是把它当成一次性结论：既然通过了，就永远安全。事实上任何结论都绑定三件事——覆盖哪些模块、用什么方法、对应哪个版本。本文按这个顺序组织，读者可以在读结论之前先确认这三项是否与自己关心的场景匹配。

还有一处需要提醒：审计结论的强度与参与方数量正相关。本报告由内部团队执行，因此即便结论全绿，也只能说明这套方法没有发现问题，不能说明问题不存在。这个区别在涉及资金与合规的场景里尤为重要。

三段式阅读法

• 第一段：范围 第 02 节列出 4 个已覆盖模块与 2 个未覆盖模块，未覆盖部分不计入结论。
• 第二段：方法 第 03 节说明取证方式与样本量，黑盒复核只能证明行为，不能证明未来版本不变。
• 第三段：结论 第 04 节按模块列出发现与整改状态，偏差项与其处理时限逐条对应。
• 附加段：局限 第 06 节说明方法本身的边界，读完再决定结论能不能用于自己的判断。

如果只想知道一句话结论：在 2026 年 6 月至 10 月的 3 轮核验中，已覆盖的 4 个模块未发现未整改的高危偏差，5 项偏差项全部在 30 日内完成整改并复验；未覆盖的 2 个模块不在这句结论之内。

本轮核验覆盖 4 个模块：客户端、接入层、出口层与业务库。每个模块给出具体的检查项数量与样本量。未覆盖的 2 个模块是支付链路与供应链，原因分别是涉及第三方机构流程与超出团队取证能力，两者在报告中单独标注为“不计入结论”。

范围声明还有一个常被忽略的作用：它让后续轮次的对比有意义。第 1 轮只覆盖客户端与业务库，第 2 轮加入接入层，第 3 轮补齐出口层；三轮的偏差项数量看似下降，但样本范围在扩大，因此不能在数量上做简单对比，只能比较同一模块内的变化。

为什么供应链没有覆盖

供应链核验要求对构建环境、依赖来源与产物签名做端到端追溯，通常需要独立机构参与。快喵目前只做到两件事：依赖清单公开与安装包摘要公示。这两件事能证明“你拿到的包与公示的包一致”，但不能证明“构建过程没有被污染”，因此不把它写进覆盖范围。

• 依赖清单 客户端依赖的开源库与其版本随版本公示，便于核对已知问题。
• 产物摘要 安装包 SHA256 随版本发布，用户可自行校验下载完整性。
• 未做 构建环境的可复现性与依赖来源的逐层追溯，属于未覆盖项。
• 后续 若引入独立机构参与，会把结论并入下一轮报告而不改写历史报告。

本轮使用三种方法：白盒代码与配置审阅、黑盒受控连接复核、库表结构核对。三者互补：白盒能发现设计层面的问题，黑盒能验证实际行为，库表核对能确认承诺在数据结构上是否成立。样本量方面，受控连接共执行 600 次（3 轮各 200 次），覆盖 6 个平台组合。

样本的代表性同样重要：若 200 次连接全部来自同一运营商与同一时段，结论就只能覆盖那个组合。本轮在设计上要求每个平台组合至少 30 次、三种网络环境各占三分之一，并且刻意包含了 12 次弱网连接，用于观察超时路径下的写入行为。

一次受控连接复核做什么

1. 隔离环境在无其他设备的隔离网络内安装同版本客户端，关闭所有后台更新与同步。
2. 建立连接发起 200 次连接，覆盖 5 个目标站点与 3 种网络环境，逐次记录会话标识。
3. 抓取写入在业务库侧开启写入捕获，记录每次连接产生的全部写入操作与字段值。
4. 逐项核对把写入结果与字段表逐项比对，任何超出字段表的写入都记为偏差项。
5. 复验整改后重复同样流程，确认偏差项消失且未引入新的写入。

这一步的关键在第四步：核对的对象是“写入了什么”，而不是“代码想写入什么”。两者的差异正是多数隐私承诺失效的地方——代码里写着不留存，但某个统计上报顺手把目标地址带进了错误日志。

5 项偏差全部属于“实现与文档不一致”，没有出现“架构性缺陷”。其中 3 项与日志字段有关，1 项与证书校验的异常分支有关，1 项与删除任务的时间窗有关。每项都记录了发现时间、影响范围、整改方式与复验结果。

五项偏差里最值得复盘的是 D-02：证书校验的异常分支里存在一个“继续访问”入口，触发条件是一个极少出现在正常网络中的错误码。它没有在实际场景中被触发过，但它证明了“不留后门”不能只靠约定——只要代码里存在一条绕过路径，就会在某次排障中被重新启用。

为什么把偏差项公开

公开偏差项会让报告看起来“不好看”，但它同时是最有力的证据：一份永远没有问题的报告，读者无法判断它究竟检查得多细。快喵VPN 选择公布编号、问题、影响范围与复验结果，而非只给一句“未发现重大问题”。

• 可复核 读者可以据此判断核验的细致程度，而不必信任一个形容词。
• 可追踪 同一类问题再次出现时，可以直接对比整改方式是否一致。
• 可追责 偏差项与其整改时限绑定，超时会成为下一轮报告的开篇内容。

流程共 5 步，从登记到关闭平均耗时 11 天。关键设计是“双人复核”与“复验必须换人”：提出整改的成员不能执行复验，避免自证。第 3 轮的 5 项偏差全部走完流程，平均耗时 9.6 天，最长 18 天。

1. 登记发现即登记编号与影响范围，进入公共清单，不允许私下修复后不记录。
2. 定级按影响范围与可利用性定级，高危 7 日、中危 30 日、低危 90 日。
3. 整改由模块负责人提交改动，说明根因与修复方式，不接受只改表象。
4. 复验由未参与整改的成员按原方法复测，并额外做一次相关回归。
5. 关闭复验通过后关闭并写入报告，复验未通过则回退到整改并重新计时。

本报告的局限有 4 条，且每一条都可能被误读。第一条最重要：核验属于自查，没有独立第三方参与，因此结论的证据强度低于外部审计；第二条是时间点性质，结论只对应执行时的版本；第三条与第四条分别是范围与方法的边界。

还有一个结构性局限需要点名：本报告的核验对象是快喵自己的模块，因此无法回答“节点托管方的物理安全如何”这类问题。托管方可能具备读取内存的能力，而这一点既不能被抓包证明，也不能被库表核对否定，只能作为已知风险写入范围声明。

四条局限

• 自查性质 无独立第三方参与，缺少外部背书，证据强度低于机构审计。
• 时间点 结论对应具体版本与日期，跨版本引用需要重新核验。
• 范围缺口 支付链路与供应链未覆盖，不能据此推断其安全性。
• 方法边界 黑盒复核与抓包无法观察到节点内部的中间状态，只能证明出入两端的行为。

第四条值得展开：抓包能证明“用户侧看到的密文”与“出口侧发出的密文”，但无法证明节点在内存中如何处理这些字节。要覆盖这一段，需要节点侧的运行时可观测性或更严格的 enclave 方案，目前两者都未采用，因此报告不对节点内部状态作任何结论。

把局限写进正文还有一个副作用：它让整改变得可以商量。当一条结论被明确标注“仅适用于 HTTPS 站点”时，读者就不会在没有 HTTPS 的场景里误用结论，团队也不会因为个别反馈而被迫扩大结论范围。

三轮的偏差项数量依次为 2、2、1，平均整改耗时从 8.5 天升到 12 天再降到 7 天。数量下降本身不足以下结论，更有意义的是类型分布：第 1 轮集中在日志字段，第 2 轮转向定时任务与统计接口，第 3 轮只剩节点侧的内存队列。这条迁移路径说明检查的深度在推进。

• 2026-06-15第 1 轮：日志字段清理覆盖客户端与业务库，发现错误日志带目标域名与证书校验异常分支两个问题，8.5 天内整改完成。
• 2026-08-20第 2 轮：时间窗与统计接口引入库表结构核对，发现设备哈希清除延后与聚合统计含会话时间戳，平均 12 天完成整改。
• 2026-10-16第 3 轮：节点侧内存新增内存检索项，发现转发队列保留 5 秒内容，改为元数据队列后 7 天复验通过。

为什么样本量不是越大越好

受控连接的样本量受限于人工核对成本：每一次连接产生的写入都要逐条比对，200 次已需要约 6 小时。把样本加到 2000 次并不会显著提高发现率，因为偏差项多集中在特定代码路径上，覆盖路径比增加次数更有效。这也是第 3 轮把一部分样本转为内存检索与导出比对的原因。

下一轮要补的三件事

• 依赖来源追溯 把依赖清单扩展到构建环境，逐步接近可复现构建。
• 节点内部可观测 为节点侧增加可核对的运行时不变量，减少黑盒方法的盲区。
• 跨版本回归 把三轮的检查项固化为一套回归脚本，版本发布时自动执行。

术语表

白盒审阅

直接阅读代码与配置，判断设计是否符合文档的方法。

黑盒复核

在不看实现的前提下，通过运行行为验证承诺的方法。

偏差项

实现与文档不一致的具体条目，须登记编号并整改复验。

双人复核

关键操作需两名成员分别确认，用于避免自证。

故障注入

人为构造异常以验证降级路径的方法。

可复现构建

相同源码在相同环境下产出字节一致的包，本报告未覆盖。

证据强度

一种方法能支撑的结论范围，黑盒复核弱于白盒审阅。

归零复验

整改后按原方法重测并要求偏差项完全消失。

检查项清单

读者可执行的三步

1. 查版本对照把自己的客户端版本与报告轮次对照，确认结论是否覆盖当前版本。
2. 查导出内容导出账号数据，核对是否只包含字段表中的字段。
3. 查删除行为注销测试账号，在承诺的时限后尝试登录，确认数据已被删除。

三步自查里最容易被跳过的是第三步：注销测试账号需要等待删除时限到期，多数人不会真的等。但它是唯一能验证删除承诺的方法，其余两项只能验证“记录了什么”，无法验证“删掉了什么”。