Adding Asset Transparency to your product can add additional protections against key material compromise and user concerns about side builds by an attacker.
Most software update systems today use public key cryptography to protect users. The software publisher signs a release using a long-lived signing key that is embedded in all copies of their software. Then the publisher's update servers signals to user's instances that an update is available. After receiving the update payload the user's instance of the software verifies the payload against the signing key.
This system provides protections from a number of mistakes and attacks:
- Distribution server attacks- if an attacker gets access to the CDN or webserver that is distributing the updates they cannot trick
- Man-in-the-middle attacks- public key verification allows a MitM attacker to deny an update but protects against modifications
- Accidental releases- often signing a release requires multiple engineers to be involved
However, this system cannot protect, or even help detect, a situation where both the signing key is compromised and an attacker can control the software that users download (via MitM or distribution server).
In order to protect against these sorts of attacks Asset Transparency can be added as a third leg to update security. With Asset Transparency you can put in a constraint, along side the signature verification, that the digest of the received update matches the URL entry in the public transparency log.
As a bonus, for very paranoid users, this also protects from potential "insider attacks" where the software publisher makes a special release that is designed to attack only their infrastructure- it at least requires that that release show up in a public log and is readable by the Asset Transparency servers as well as the user's own.