Software supply chain security: make the build verifiable

Follow code into the delivered file

A dependency, script or build environment change can alter an artifact without changing its product name. Understanding a release means examining the elements involved in producing it.

Software supply chain security includes access controls, dependency review, key protection, execution isolation and checks on distributed files. Provenance adds a record of production to those practices.

Software artifact integrity

Software artifact integrity addresses a concrete question: does the file being examined match the one identified by the reference record? A digest enables comparison; a signature protects the record containing that digest.

You also need reasons to trust the key and the recording process. A signed record does not repair a compromised build. Build protection measures and verifiable evidence serve complementary purposes.

Start with an existing step

Continuum Attest can run a declared pipeline or wrap an existing command. Choose a build, declare its inputs and outputs, enable signing and keep the receipt with the corresponding files.

Then try verification from another environment using approved public keys. This exposes missing materials: files, expected configuration or trust data. It makes portable evidence a concrete exercise.

Understand the formats

Build provenance describes production. An artifact attestation carries a verifiable statement. SLSA organizes security requirements; compatible exports are not certification.

Start with Trust is not evidence, then follow the CLI reference. The offline verification guide explains how to check evidence without access to the build platform.