Binary Provenance, SBOMs and the Software Supply Chain for Humans

“What’s really running in prod?”

Every engineer will hear these immortal words on a long enough timeline (or career). It might be because a new security zero day was dropped, alerts fired from the depths of a vast microservice architecture, or you might just be looking to know what commit was actually tested. Either way, it often comes with the promise of a stressful day.

Let’s demystify three critical concepts for delivering secure, reliable software: binary provenance, software bills of materials (SBOMs) and the software supply chain.

These are not just industry buzzwords — and they’re also not industry buzzwords — they’re vital tools for ensuring software integrity and transparency in an era of increasing cyberthreats and complex development processes. Let’s explore how these concepts help trace code origins, understand software components and secure the development-to-deployment journey.

Here are the basics about digital fingerprints, tracking open source dependencies and supply chain security. By the end, you’ll be able to grasp what these terms mean, why they’re crucial for modern software development and how to start implementing them in your projects.

Let’s begin with binary provenance — knowing your software’s true origins.

Binary Provenance 

In software, binary provenance is the answer to the question, ” Where did this artifact come from?”

TRENDING STORIES

1. Why Broadcom Is Killing off VMware’s Standalone Products
2. Expo vs. Flutter: How to Choose the Right Mobile Framework
3. Dive: A Simple App for Viewing the Contents of a Docker Image
4. How to Get Started with HTTP/3
5. How to Manage Linux Storage

Say you find a Docker image running on a host. How can you trace its origin? How do you know it was built in CI? How do you know what source commit or even repo it comes from? How do you know it hasn’t been tampered with?

 Zoom

If all you have is the image, answering these questions can be extremely difficult. If you are lucky, you might be able to find some of the information in CI logs or container registries, but the hunt will take a lot of time.

So, what is the solution?

What if we got the build process to create records for every build we make?

 Zoom

The key to making this work is content-addressable storage. This is a fancy term, but its meaning is straightforward: the file’s contents (in our case, the docker image) are the identity*.* You might ask yourself: How does this work? Well, it’s pretty simple: We use a cryptographic hashing function like sha256 to create a digest for the artifact.

 Zoom

This approach has some very powerful properties:

• Zero trust: We don’t need to believe version numbers, image tags or metadata identify artifacts; the digest uniquely identifies the binary.
• Tamper-evident: If a single byte in the software changes, it will have a different identity.

Binary provenance ensures we can’t qualify one software artifact and deploy a different one. It also allows us to create a provable chain of custody from commit to build to production. This approach overcomes the limitations of relying solely on CI logs or container registries, which can be incomplete or manipulated.

Here’s how you can use OpenSSL to get the cryptographic fingerprint for a file:

 Zoom

And if you are using Docker images, you can query the digest from the command line:

 Zoom

When you create the provenance document, you probably want to store it in a system of record. There are many options for this, ranging from the open source sigstore project to artifact management systems and software delivery evidence management (SDEM) tools like Kosli. It is important that it is stored in a secure, append-only system.

Software Bill of Materials 

OK, so hopefully, now you have records of where your software is coming from. The next question to answer is, “What’s inside this software artifact?” This is where SBOMs can help.

SBOM stands for software bill of materials. It’s essentially a formal, machine-readable inventory of all the ingredients (components and dependencies) in your software recipe.

Software systems are built using vast amounts of open source components. In addition to your code, a typical software project contains many open source libraries and base container images. Consider this:

1. Security vulnerabilities can hide in any part of your supply chain. Licensing issues might be lurking in any of those dependencies.
2. Updates to third-party components can break your app in unexpected ways.

The software supply chain is all about understanding and managing these risks. It’s about having visibility into every ingredient in your software recipe.

 Zoom

The key benefit is transparency: SBOMs give you complete insight into your software supply chain. An SBOM contains a complete description of the component names, versions, licenses and other metadata for dependencies pulled into the build.

There are many SBOM formats, but the leading choices are SPDX and CycloneDX. There are many tools available for generating SBOMs. Here is an example from our own CI pipeline, which uses the open source anchore/sbom-action tool:

 Zoom

SBOM Formats

This will produce a file containing a complete package inventory in the Docker image. It looks like this (Please note: this is truncated and just an example of the sheer size of the file).

{"spdxVersion":"SPDX-2.3","dataLicense":"CC0-1.0","SPDXID":"SPDXRef-DOCUMENT"," 
name":".","documentNamespace":"https://anchore.com/syft/dir/1ab221f8-e13a-4f54- 
9887-856f86a4aae5","creationInfo":{"licenseListVersion":"3.23","creators":["Org 
anization: Anchore, Inc","Tool: 
syft-1.4.1"],"created":"2024-06-17T11:51:18Z"},"packages":[{"name":"./.github/w 
orkflows/binary_provenance.yml","SPDXID":"SPDXRef-Package-github-action-workflo 
w-.-.github-workflows-binary-provenance.yml-ca0fa1f79b340d36","supplier":"NOASS 
ERTION","downloadLocation":"NOASSERTION","filesAnalyzed":false,"sourceInfo":"ac 
quired package info from GitHub Actions workflow file or composite action file: 
/.github/workflows/release.yml","licenseConcluded":"NOASSERTION","licenseDeclar 
ed":"NOASSERTION","copyrightText":"NOASSERTION","externalRefs":[{"referenceCate 
gory":"SECURITY","referenceType":"cpe23Type","referenceLocator":"cpe:2.3:a:.\\/ 
.github\\/workflows\\/binary-provenance.yml:.\\/.github\\/workflows\\/binary-pr 
ovenance.yml:*:*:*:*:*:*:*:*"},{"referenceCategory":"SECURITY","referenceType": 
"cpe23Type","referenceLocator":"cpe:2.3:a:.\\/.github\\/workflows\\/binary-prov 
enance.yml:.\\/.github\\/workflows\\/binary_provenance.yml:*:*:*:*:*:*:*:*"},{" 
referenceCategory":"SECURITY","referenceType":"cpe23Type","referenceLocator":"c 
pe:2.3:a:.\\/.github\\/workflows\\/binary_provenance.yml:.\\/.github\\/workflow 
s\\/binary-provenance.yml:*:*:*:*:*:*:*:*"},{"referenceCategory":"SECURITY","re 
ferenceType":"cpe23Type","referenceLocator":"cpe:2.3:a:.\\/.github\\/workflows\ 
\/binary_provenance.yml:.\\/.github\\/workflows\\/binary_provenance.yml:*:*:*:* 
:*:*:*:*"},{"referenceCategory":"SECURITY","referenceType":"cpe23Type","referen 
ceLocator":"cpe:2.3:a:.\\/.github\\/workflows\\/binary:.\\/.github\\/workflows\
\/binary-provenance.yml:*:*:*:*:*:*:*:*"},{"referenceCategory":"SECURITY","refe 
renceType":"cpe23Type","referenceLocator":"cpe:2.3:a:.\\/.github\\/workflows\\/ 
binary:.\\/.github\\/workflows\\/binary_provenance.yml:*:*:*:*:*:*:*:*"}]},{"na 
me":"./.github/workflows/docker.yml","SPDXID":"SPDXRef-Package-github-action-wo 
rkflow-.-.github-workflows-docker.yml-273b2ab88b16b339","supplier":"NOASSERTION 
","downloadLocation":"NOASSERTION","filesAnalyzed":false,"sourceInfo":"acquired 
package info from GitHub Actions workflow file or composite action file:

• Where did this software originate?
• What is included in the package?

Now, you can answer important questions about security vulnerabilities, identify outdated dependencies, and monitor licensing and compliance issues.

Software Supply Chain 

Now that we know about binary provenance and SBOMs, how do these fit into the bigger picture of software delivery? This is where the concept of the software supply chain comes in.

 Zoom

Think of the software supply chain as the journey your code and all its dependencies take from idea to production. Modern software delivery is a factory of integrated tools, processes and human activities.

The software supply chain is all about traceability. It gives you visibility into every ingredient in your software recipe and every step of the journey.

You’ll notice that binary provenance and SBOMs produce metadata around a single step on this journey. These metadata files are often called attestations. A comprehensive supply chain will provide centralized records for every step you value, including code reviews, security scans and even runtime events.

Conclusion 

Binary provenance, SBOMs and the software supply chain are intrinsically linked, and each plays a crucial role in modern software development and security.

Binary provenance provides the foundation, ensuring we can trace and verify the origin of every software artifact. SBOMs build upon this, offering a detailed inventory of all components within our software. The software supply chain ties it all together, giving us a comprehensive view of our code’s journey from inception to deployment.

These concepts don’t exist in isolation — they work together to enhance security, improve efficiency and build trust. By implementing these practices, you’ll be able to respond swiftly to vulnerabilities, deploy with greater confidence and maintain transparency throughout the development process.

And you’ll always know what’s in prod.