In this episode of ReversingGlass, Matt discusses the importance of using reproducible builds to manage an organization’s software supply chain security. Matt explains the complex nature of reproducible builds and why they are worth the investment for end-to-end security. 

Learn More

- Related blog: ESF steps up supply chain security guidance with call for binary analysis
- White paper: The Monsters in Your Software Supply Chain 
- Research report: The State of Software Supply Chain Security 2024

Episode Transcript

Hi everyone, welcome back to another episode of ReversingGlass. I'm Matt Rose, Field CISO at ReversingLabs. Today's episode is reproducible builds in SSCS. Reproducible Builds is like a graduate level course associated with software supply chain risk, where you're not just comparing one entity to the next version, you're comparing two separate entities along the same path in different ways. And I'm going to get into the exact details and make a little more sense of that in a second, I like to start with some sort of reference and we have our friends, the minions, Despicable Me. They're all very similar, but there's a little bit of difference.

So if you think about your build environment. How can you compare it if you don't always have two things to look at? So some minions have one eye, two eyes, mustaches, whatever it is. Do your builds have something different or are they exactly the same? So let's start a step back here and talk about comparing or diffing between two releases.

Typically you have a process, and this is very simplistic, where a developer writes an IDE, checks code in the source code repository, then your CICD orchestration pulls together some other info, maybe a binary repository. And then it's actually pushed, let's say, to your cloud infrastructure.

This is a CI/CD pipeline, a build pipeline, very simplistic. Addressing software supply chain security without a reproducible build, and I'll define that again in a second. This creates an entity where it's, let's say, v1, and then v1.1 comes out, then v1.2 comes out. From a software supply chain risk standpoint, you can basically then do a differential analysis of one pipeline coming in, creating a package, different versions of the package, to see what's changed.

It's great for looking at the package standpoint, but a litmus test for more advanced usage of software supply chain programs, again more of a graduate program, is you take this entity and you create the exact same infrastructure for your build. So you're not comparing the artifact of one pipeline versus itself, you actually have an additional flow. So if this pipeline somehow was compromised and something happens with this, you have an identical pipeline with the same IDE, source code, repository, binary, CI/CD, deployment to cloud mechanism. And then instead of comparing, you have this additional entity that is supposed to create the same process.

I'll just do it for example here, and then you compare the product of both build pipelines against itself. So think about Danny DeVito and Arnold Schwarzenegger in Twins. Are they exactly the same? No, they're not. That's what you're looking for. If one pipeline is compromised, it's highly doubtful that a secondary, more locked down pipeline is compromised as well.

So you can actually sniff out what is happening and what is a comparison, not just from one package to the next package via the pipeline, the same pipeline, you're actually comparing version 1.1 and 1.1 from two totally different pipelines. So then you get an understanding of if something was compromised.

If we think about software supply chain risk, this is the advanced course that organizations that are most susceptible or most concerned is probably the best way to put it, associated with their supply chains. That they're not only comparing the versions created by a pipeline, they're actually creating two separate pipelines and then comparing those entities because one is locked down, one is potentially compromised, and you basically lead to the path of identifying an unknown, maybe novel attack associated with the source code repository, something leaking in there, user credentials being compromised, compromise of the CI/CD build platform, the build platform that lives under CI/CD platform.

All these things are very important, but again, there is care and feeding involved, and there is a cost involved to replicate a build pipeline multiple times. Maybe one time, two time, but it's the process and the definition of reproducible build and how it relates and is a very advanced way and effective way to address software supply chain risk.

I'm Matt Rose. This is ReversingGlass. Hope you enjoyed the episode today of reproducible builds and software supply chain security. Thanks for watching.