Skip to content Skip to navigation

Software supply chains are increasingly vulnerable, with security measures such as digital signing not providing sufficient grounds for trust on their own.

To build greater confidence and trust, we can capture information about activity throughout the software production process, and create an immutable and tamper-evident record which can be viewed and verified by others.

This is Binary Transparency.

Threats in the Pipeline

Binary Transparency can be used to mitigate many threats and risks within the pipelines used to produce software. The key element is the use of a verifiable data structure, such as a tamper-evident log, to store information about pipeline activity, which is then discoverable by others.

Access to this information can drive further processes: alerting people and systems to malicious behaviour, discouraging bad practice and insider exploits, and enabling validation of the integrity of software artifacts.

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.

Hidden Vulnerabilities

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.

Trusting Dependencies

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.

Build System Integrity

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.

Detecting Key Misuse

Digital signatures are assumed to show the identity of the software producer, but is it possible to be more confident that the keys for signing have not been stolen?

Within a Binary Transparency framework, the event of signing would be committed to a tamper-evident log. Trust in the signed binary is now dependent on the signature as well as the verifiable log entry.

To distribute illicitly signed software, a bad actor now needs to publicly log the signing of the illicit release, as well as stealing the key. An insider exploit which manages to write the new signing into the log could be detected by the software producer monitoring the log for unexpected signing events.

Confidence on Device

With activity from the software supply chain cryptographically logged, it is now possible for devices to enforce a policy prior to execution.

For example, before installing a new firmware image or executing an application the device can ensure that these checks above have taken place.

Binary Transparency replaces blind trust with a verifiable record that can be used to confirm the activities that have resulted in the software being deployed, providing a firm foundation for trust.

Next Steps

Any software producer can apply the principles of Binary Transparency to identify and target vulnerabilities within their existing pipelines, avoiding the need for extensive re-engineering.

Here are some further resources for finding out more about implementing Binary Transparency within your software supply chain.

  • transparency.dev

    Learn more about the general concepts of transparency and how to design verifiable systems.

  • Certificate Transparency

    How tamper-evident logs having been helping secure the certificate supply chain.

  • SLSA

    A framework for identifying and managing threats and risks within the supply chain which incorporates Binary Transparency concepts.

  • Firmware Transparency Demo

    Code examples on GitHub for how to apply transparency patterns to the problem of firmware updates.

Your browser is outdated and may not display all features of this site.