开源不等于安全，审计也不等于安全。这两个标签各自只覆盖了一部分威胁，把它们加在一起，仍然留下了几个关键的缺口。
可复现构建到底证明了什么
可复现构建解决的问题很具体：你下载到的二进制文件，是否真的来自那份公开的源代码。
传统软件发布中，开发者编译源代码，上传二进制到你下载的服务器。中间任何人——开发者本人、服务器管理员、CDN 提供商——都可以替换这个二进制，或者把恶意代码混入构建流程。你看到的源代码是干净的，但你运行的程序不是。
可复现构建试图消除这个信任缺口。它的逻辑是：同样的源代码，在同样的构建环境下，应该产出逐字节完全相同的二进制。任何第三方都可以重新构建并对比哈希，如果一致，说明发布者提供的二进制确实对应那份源代码。
Electrum 官方声明其可执行文件是可复现的，且由多个构建者独立签名。发布需要至少 ThomasV 和 SomberNight 两把密钥签名，脚本在公开展示前自动检查。
但可复现构建的覆盖范围有限。它证明的是"二进制与源代码一致"，不证明"源代码本身没有漏洞"。如果源代码里就藏着后门，或者随机数生成逻辑有缺陷，可复现构建照样会"通过"——因为重新构建出的确实是那份有问题的代码。
Wasabi Wallet 2.7.2 的 Linux tar.gz 曾被发现不可复现，原因是打包步骤没有规范化文件时间戳。虽然 .NET 编译用了 Deterministic=true，但打包环节的疏漏让独立验证无法进行。这个例子说明，可复现构建不是"开源了就自动具备"的属性，它需要发布方在工具链、打包、时间戳处理等每个环节都做到位。
审计的边界在哪里
安全审计的范围取决于审计方被允许看什么、被要求找什么。
以 Ledger 的第三方审计流程为例。审计实验室在 NDA 下获得 Ledger OS 的完整源代码和开发环境访问权限，审查重点包括：攻击者能否提取敏感信息，能否在没有用户同意的情况下执行未授权操作。审计报告需要签名，并公布在 Ledger 的 GitHub 仓库中。
但审计有自己的结构性限制。
审计是一次快照。 它审查的是某个时间点的代码状态。审计之后新增的代码、修改的逻辑、更新的依赖，不在审计覆盖范围内。Ledger 每个 OS 更新都会做审计，这意味着每次更新都需要重新审查。
审计范围由买方和审计方协商确定。 Ledger 开发者文档列出了审计必须覆盖的项，包括签名操作必须要求用户批准、盲签必须默认关闭且不适用于基础转账、编译过程不能有未处理的警告、静态分析工具（如 scan-build、CodeQL）必须通过且不能报告缺陷。这些要求很具体，但它们仍然是一个 checklist。审计方按清单检查，清单之外的问题可能被遗漏。
审计的深度受限于方法和时间。 CCSS 审计标准中有一条关键规则：整体等级等于最低项得分。 九个方面做到 Level III、一个方面只有 Level I，整体就是 Level I。这条规则承认了审计的系统性——单个环节的薄弱就足以拉低整体。
审计能发现已知类型的漏洞，但很难发现全新类型的攻击。TROPIC01 芯片的激光故障注入攻击就是一个例子：攻击者用激光脉冲精确打在芯片执行签名验证的瞬间，让无效签名通过验证。这种攻击需要物理接触设备、拆解封装、专业实验室设备和深度专业知识。任何常规的代码审计都难以预见这种基于物理侧信道的攻击。
缺口的实际后果
把可复现构建和审计放在一起看，仍然有它们覆盖不到的层面。
供应链攻击在构建之前发生。 慢雾分析过一起案例：用户在抖音购买的冷钱包，私钥在制造阶段就被恶意固件回传。恶意代码是一段 4KB 的程序，用来把助记词发送到固定 IP。这类攻击发生在设备出厂之前，可复现构建验证的是官方二进制——但如果设备本身在到达用户手中之前已经被替换或篡改，构建验证帮不上忙。
固件层的随机数缺陷可以绕过所有密码学保护。 Coldcard 的漏洞涉及助记词生成过程中的随机性预测：攻击者可以在数学层面推导出私钥，即使设备从未联网。代码审计通常不会逐行审查随机数生成器的熵源实现，可复现构建也不能告诉你生成出的私钥是否真的随机。
用户操作不在任何技术保障范围内。 Trezor 在披露 TROPIC01 芯片漏洞时明确表示，该攻击需要物理接触设备、拆解焊接、背面开盖、专业设备，且每次设备断电后都需要重新执行。攻击无法获取 PIN、资金或钱包备份，不能制作用于供应链攻击的篡改设备。但 Trezor 同时指出，钓鱼仍然是用户面临的最大外部威胁。
你实际应该检查什么
对于普通用户，可复现构建和审计报告不是需要逐项核对的清单。你不太可能自己去重新编译 Electrum 并对比哈希，也不太可能逐页阅读审计报告。
更实际的判断顺序：
第一，来源比审计报告优先。 从官方渠道下载钱包和固件。官网、官方 GitHub Release、授权经销商。第三方应用商店、电商平台的"原厂封条、低价抢购"是供应链攻击的高发入口。可复现构建的前提是你下载到了官方发布的那个二进制，下载渠道错了，后面全部无效。
第二，看项目是否主动披露漏洞。 Trezor 主动公布 TROPIC01 芯片的漏洞，并说明资金不受影响、用户无需操作。一个愿意披露漏洞的项目，比一个声称"从未被攻破"的项目更值得关注——前者让你能判断风险，后者让你无法判断。
第三，理解审计报告证明的是什么。 如果审计报告说"签名操作要求用户批准"，它证明的是审计时点的代码有这个行为，不证明未来的更新仍然如此。审计报告有时效性，看发布日期。
第四，钱包安全是分层的事情。 可复现构建保障"你运行的程序是公开代码编译的"，审计检查"公开代码在已知攻击面下没有明显漏洞"。这两项做到位，覆盖的是"软件本身没有被篡改、没有已知缺陷"这一层。供应链、随机数、用户操作、物理攻击是另外的层面，需要分别对待。
参考资料
- OpenSSF·可复现构建术语说明，页面发布或更新日期：页面未标明更新日期；核查日期：2024-06-15。
- Debian项目·rebuilderd软件包说明，页面发布或更新日期：页面未标明更新日期；核查日期：2024-06-15。
- Electrum官方网站，页面发布或更新日期：页面未标明更新日期；核查日期：2024-06-15。
- Portland Hodl·Coldcard固件开源仓库说明，页面发布或更新日期：页面未标明更新日期；核查日期：2024-06-15。
- Wasabi钱包GitHub·不可复现构建问题反馈，页面发布或更新日期：页面未标明更新日期；核查日期：2024-06-15。
- Ledger支持中心·第三方安全评估报告说明，页面发布或更新日期：页面未标明更新日期；核查日期：2024-06-15。
- Ledger开发者文档·安全审计要求说明，页面发布或更新日期：页面未标明更新日期；核查日期：2024-06-15。
- Certik博客·CCSS审计准备指南，页面发布或更新日期：页面未标明更新日期；核查日期：2024-06-15。
- Ledger Donjon安全实验室·TROPIC01激光故障注入攻击分析，页面发布或更新日期：页面未标明更新日期；核查日期：2024-06-15。
- Trezor官方·TROPIC01芯片漏洞披露说明，页面发布或更新日期：页面未标明更新日期；核查日期：2024-06-15。
- BTCC广场·冷钱包供应链攻击案例分析，页面发布或更新日期：页面未标明更新日期；核查日期：2024-06-15。
- 币安广场·Coldcard随机数漏洞相关说明，页面发布或更新日期：页面未标明更新日期；核查日期：2024-06-15。
- Trezor官方·TROPIC01芯片漏洞用户响应公告，页面发布或更新日期：页面未标明更新日期；核查日期：2024-06-15。
