Artifact Binary Provenance

Introduction

We define software identity by using the cryptographic hash of the software itself, specifically the SHA256 digest of the software binary. This approach ensures that any change, even a single byte, results in a unique identity for the software. This guarantees that we cannot qualify one software artifact and deploy a different one. Additionally, it allows us to create a provable chain of custody from commit through build to production.

Recorded Evidence Details

To ensure the integrity and traceability of our software, we record the following evidence:

• The SHA256 hash of the artifact (docker image, zip file, etc.)

• A human-readable name

• The git commit that produced it

• The git repository state (clean, unstaged files, etc.)

• A URL to the build log

• The build environment information

• The software bill of materials

Alternative Identification of Artifacts

In CI displays, filenames, and docker image tags, it is helpful to use human-friendly identities like server or git source commits. These are useful for navigating version control and CI systems but are not reliable enough for security and compliance. We use labels for humans and SHAs for machines.

Implementation of this control

We record every official build in our CI system to ensure all necessary information is captured and verified for each build.