Zero Trust Supply Chain Security

Background

Let’s say you’re walking down the sidewalk outside of your office, and you find a USB thumb drive sitting on the ground. I hope everyone knows that you should absolutely not take that drive inside your office and plug it into your workstation. Everyone in software should (rightly) be screaming no right now! Real attacks have happened this way, and security orgs across the world hammer this into all employees as part of training.

Zero Trust

Traditionally, network and workload security relied on trusted “perimeters”. Firewalls, internal networks and physical security provided defense against attackers by keeping them out. This type of architecture is simple and effective when all assets are in one place, the firewall doesn’t need many holes and all hardware is on the same physical network.

Photo by Simon Maage on Unsplash

The Challenge With Zero Trust Supply Chain Security

Supply-chain security is very similar to network security and identity management. Instead of authenticating people or systems, we need to authenticate artifacts. There are multiple systems in use today, but all rely on cryptographic signatures and some form of PKI.

Photo by USGS on Unsplash

Getting Started

The problem statement was simple — why can’t you run a random binary package or container that you find on the sidewalk? Why is there no way to determine where any given container came from? Basic questions, like who built it, from what source, and how? Some great projects like In-Toto and The Update Framework have been working on this problem for years, but they were still missing a few parts that we set out to solve in Sigstore.

  • an easy to use signing system
  • a central discovery and storage system for build attestations
  • automatic build system integrations.

The Pieces

Sigstore makes signing of arbitrary artifacts dead simple with the cosigntool, including built-in support for cloud KMS systems, physical HSMs, yubikey devices, and Sigstore’s free code-signing CA based on Open ID Connect.

Tracing a Container

For this experiment, we’re going to trace an application container all the way back to the lowest level base image (FROM SCRATCH). We’ll verify signatures and attestations about every step in this build process, across multiple build systems run by different organizations!

Step 1: The Application Container

The demo starts with a container image built using the ko build tool inside of a GitHub Action. We’ll verify the signatures on this application image, which are signed using an ambient token made available by the GitHub Actions platform. This token is bound to a specific invocation of the action at a specific commit, which we can lookup in the transparency log.

Step 2: The Base Image

So now we’ve verified the application image and the commit used to build it. We can keep going though, and look for more turtles on the way down. Most containers are built from a base image, which can also be attacked! Thanks to a recent change in the OCI, image build tools can include an annotation that points to the specific base image and digest used during a build.

Wrapping Up

Aeva Black summarized the concept very well during my talk:

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store