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 and the environment support matrix to evaluate the builder and capture environment. A tool name alone does not establish an assurance level.
Open-source projects
in-toto supplies attestation formats and a verification framework. Sigstore supplies signing and verification tools and services. SPIFFE 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 to understand what each component decides and which assumptions remain.
