数字签名能证明软件是谁写的，但证明不了软件是不是本该被发布的那一个——这个漏洞，谷歌现在要用一套公开账本补上。

一、问题：签名 intact，软件有毒

打开网易新闻 查看精彩图片

供应链攻击的狡猾之处在于，它能骗过现有的大部分验证机制。攻击者不需要伪造签名，只需要在软件从开发者到用户的某个环节动手脚，把恶意代码塞进正经的安装包。

DAEMON Tools 的案例很典型。Windows 安装包从官方网站下载，数字证书也是开发者的，看起来一切正常。但安装包里被塞了一个轻量级后门，进而投递名为 QUIC RAT 的植入程序。

谷歌对此的评价很直接：「仅依赖二进制签名已经不够了，签名无法保证这个特定的二进制文件是作者打算向公众发布的那个。」

数字签名是「来源证明」，二进制透明则是「意图证明」——这是谷歌对两者区别的核心定义。

二、方案：公开账本，人人可查

谷歌的解法是把 Certificate Transparency（证书透明度）的思路搬到软件分发上。证书透明度要求所有 SSL/TLS 证书必须记录在公开、只追加、可加密验证的日志中，以便发现错发或恶意证书。现在这套逻辑被复用到安卓应用。

具体机制是：为每个生产版本的 Google 应用生成对应的加密条目，写入公开账本。2026 年 5 月 1 日之后发布的谷歌生产级安卓应用，都将包含这条记录。

目前覆盖范围包括：Google Play 服务、独立 Google 应用，以及 Mainline 模块——后者属于操作系统组件，可以在常规发布周期外动态更新。

谷歌的说法是：「如果软件不在账本上，那就不是谷歌发布的生产版本。任何试图部署'一次性'版本的行为都将被检测到。」

这套系统同时向用户和研究者开放验证工具，可以检查支持类型软件的透明度状态。

三、溯源：从 Pixel 到全安卓

这个扩展并非从零开始。2021 年 10 月，谷歌推出 Pixel Binary Transparency，为 Pixel 设备建立公开加密日志，记录官方工厂镜像的元数据，确保设备只运行经过验证的操作系统软件。

现在的扩展是把这套机制从 Pixel 专属推向整个安卓生态，且聚焦在谷歌自家应用层面——不是强制所有第三方开发者接入，而是先用自己的产品验证模式可行性。

选择 2026 年 5 月作为强制时间点，给现有发布流程留出了技术迁移窗口。

四、为什么是现在

供应链攻击的频率和隐蔽性都在上升。软件更新渠道被投毒、数字签名保持完好、分发渠道看似正规——这三点叠加，让传统安全检测手段失效。

谷歌的账本方案把验证权分散出去：任何人都能查，任何异常都能被独立发现。这改变了过去「只能信任官方渠道」的单点模式。

对安卓生态来说，这相当于给谷歌官方应用建立了一套可审计的发布轨迹。研究者可以交叉验证，企业可以纳入合规检查，高敏感用户可以自己确认设备上的谷歌软件是否「对版」。

五、局限与后续

当前覆盖范围明确限定为「谷歌生产级应用」，第三方开发者是否、如何接入，原文未提及。验证工具的具体使用门槛、账本查询的实时性，也还有待观察。

但可以确定的是，2026 年 5 月之后，谷歌安卓应用的每一次生产发布都会留下不可篡改的公开记录。这对供应链攻击者意味着：即使攻破了发布管道，也无法隐藏「这个版本从未被官方登记」的事实。

对科技从业者来说，这套机制的价值在于提供了一个可复用的安全架构模板——公开可验证的日志、加密防篡改、分散式审计——这三要素组合，可能成为软件分发基础设施的新基准。