Supply chain attacks on mobile software have grown alongside the expanding role of phones in daily life, from payments to government IDs to AI features. Google is responding with an expanded Binary Transparency program for Android, adding a public ledger that records cryptographic entries for its production apps so users and researchers can confirm that the software on a device matches what Google authorized for release.
The system applies to Google’s production Android applications released after May 1, 2026. Each app gets a corresponding cryptographic entry on a public, append-only ledger. Applications last updated before that date will not appear in the log.
What the ledger covers
Two software layers fall under the program at launch. The first is Google Applications, a set of production apps that includes Google Play Services and standalone Google apps shipped to support functionality across devices. The second is Mainline Modules, the dynamically updateable operating system components that run at elevated privileges as part of Android itself.
For Pixel owners, the new ledger works alongside Pixel System Image Transparency, which Google introduced in 2023. Together, the two systems let Pixel users verify that both the system image and the Google apps on their device are production software.
A certificate of intent
The program addresses a gap in how software trust has worked for years. A digital signature confirms who built a binary, yet it cannot confirm that the binary was meant for public release. Stolen signing keys, insider attacks, and internal development builds can all carry a valid signature.
In Google’s framing, signatures are a certificate of origin and binary transparency is a certificate of intent. If a Google-signed application released after May 1, 2026, does not appear on the ledger, Google did not release it as production software. Any attempt to deploy a one-off version becomes detectable through the public record.
Verification tooling is available in the Android Binary Transparency repository on GitHub, allowing anyone to check the transparency state of supported software types against the log.
Insider risk and the path to wider adoption
Two questions sit at the center of the program’s credibility: how Google handles insider risk inside the system itself, and whether the model can extend beyond Google’s own software.
Billy Lau, Information Security Engineer at Google, told Help Net Security that the company mitigates insider risk through “defense-in-depth” protocols that isolate code development from automated building and signing. “These safeguards ensure that no single individual has the access required to publish a binary without triggering comprehensive cryptographic verification and ensures that bad actors are unable to evade detection because of visibility,” Lau said. He added that the ledger itself acts as a deterrent by creating a public, tamper-evident record that makes any unauthorized software changes immediately visible.
On extending the program to outside developers, Lau confirmed work is underway. “We are actively working to extend Binary Transparency to third-party developers to strengthen the security of the global software supply chain,” he said. The path forward involves scaling the technical infrastructure and demonstrating the security value of log participation to partners. The stated goal is a verifiable ecosystem where transparency becomes a standard benefit for all developers and their users.
Download: Secure Foundations for AI Workloads on AWS