# Zero Trust in the Software Supply Chain

Source: https://www.testifysec.com/blog/zero-trust-in-the-supply-chain/

Author: TestifySec

Published: 2022-09-15

Updated: 2026-10-06

Make producer identity, verification policy, and enforcement boundaries explicit.

Editorial update · October 6, 2026

Revised by TestifySec Editorial to remove unsupported outcome claims and explain the current product and trust boundaries. The original publication date and URL are preserved.

- [Current TestifySec docs →](https://www.testifysec.com/docs)
- [Trust architecture →](https://www.testifysec.com/docs/cilock/trust)

A software supply chain crosses several trust boundaries: source review, build execution, artifact storage, and delivery. A result accepted at one boundary should not become an unlimited grant of trust at every later boundary.

 

## What is zero trust?

 

The practical questions are who is requesting an action, what authority they have, and what evidence the decision requires. A familiar network location or repository name is not enough by itself.

 

## Identity of users and workloads

 

Authenticate the principal that receives authority. Keep that identity separate from an observed process label, environment variable, or agent name. A hash identifies bytes; it is not proof of the human or workload responsible for them.

 

Human presence, possession of a session credential, and headless workflow execution are also different claims. A system should describe the assurance it actually establishes.

 

## Policy

 

Define which producer, artifact, and results a decision requires. Protect policy changes separately from the work being evaluated. A policy signer, publisher, and gate activation actor have different responsibilities.

 

## Control

 

Evaluate the required evidence before the protected action. A signed record stored after a release is useful history, but it did not control that release. Define failure behavior for missing, stale, or incomplete evidence.

 

## Verification in a CI/CD system

 

Use limited credentials for untrusted work. Protect the observation and signing paths from the code being tested. Bind results to the exact artifact that will cross the boundary, then test both acceptance and rejection cases.

 

## Historical discussion of the retired SLSA draft

 

The original article referred to the SLSA v0.1 draft, which included Level 4. SLSA v1.0 removed Build L4; that old discussion is not a current level or a claim about CI/lock. The missing historical table from the earlier content migration has been removed rather than reconstructed as current guidance.

 

Use the [current SLSA specification](https://slsa.dev/spec/v1.2/) and the [environment support matrix](https://www.testifysec.com/docs/concepts/support-matrix) to evaluate the builder and capture environment. A tool name alone does not establish an assurance level.

 

## Open-source projects

 [in-toto](https://in-toto.io/) supplies attestation formats and a verification framework. [Sigstore](https://docs.sigstore.dev/about/overview/) supplies signing and verification tools and services. [SPIFFE](https://spiffe.io/) addresses workload identity. They solve related parts of the problem and require an explicit deployment and trust model. 

## Put the boundaries into a workflow

 

CI/lock captures the work, Pushgate checks the push, and the platform manages gates and technical control evidence. Read the [trust architecture](https://www.testifysec.com/docs/pushgate/trust-architecture) to understand what each component decides and which assumptions remain.