Confidence at Source

Binaries are often built from publicly available source code, trusting that the repo offers the authoritative version. But what if someone with access to a repository added malicious code and created a new release, falsifying the release tag so that it appeared valid?

Using a Binary Transparency model, a hash of the repo can be submitted to a tamper-evident log for every official release. This is exactly what the golang project does with sumdb - tagged releases are signed into the log and can be checked for authenticity.

Any attempt to falsify the release tag is now discoverable through comparison with the relevant log entry.

Modern software relies heavily on dependencies, and this has been a common attack vector for exploits in recent years. What if a rogue developer takes ownership of the source repository of a dependency in order to introduce a backdoor?

A possible Binary Transparency response would require a third party to check for known vulnerabilities in the package’s dependencies and record this assurance, within a tamper-evident log.

Now that this information is discoverable, anyone relying on this dependency could check the log for these assertions, and the existence of a public record will actively discourage attempted hijacks.

If the dependency is itself a binary which is packaged and distributed as part of an application, how could a developer be confident that this hasn’t been tampered with?

The producer of the library uses a Binary Transparency strategy to maintain their own tamper-evident records of code reviews, together with confirmation of build reproducibility by trusted third parties for each release.

During the build process, the provenance of the library is checked using the hash of the binary, and the build continues successfully only if these quality assurance attestations are discoverable.

Software used to automate the build process is another source of vulnerability. A hacker could introduce malicious code into a pipeline prior to building a release, by manually patching the code, or modifying the pipeline software itself to insert malicious code at build time.

Using Binary Transparency it is possible to discover that this is happening before relying on a build. The developer submits details of their build to a tamper-evident log, which is used by third parties to confirm build reproducibility using the same pipeline.

Failure to reproduce the build would ring alarm bells and allow such a compromise to be brought to light in good time.