Skip to content
← Back to blog

Security

Software supply chain: evidence over implicit trust

Provenance, signatures and policy to know which code produced an artifact and under which process.

Published on November 18, 20258 min read
SLSASigstoreDevSecOps

An artifact can pass tests and still differ from what the approved pipeline produced. Supply-chain security links source, build process, dependencies and artifact through verifiable evidence.

SLSA organizes provenance requirements to make undetected tampering difficult and help consumers apply policy.

Editorial visual

Evidence from source to production

Topic illustration
Software supply chain with source, isolated build, artifact, signature, transparency record and admission
Every step adds a verifiable claim; admission checks the chain before executing the artifact.

Sigstore supports identity-linked signing and transparency. A useful pipeline builds in isolation, emits SBOM and provenance, signs the image and verifies everything before deployment.

Adoption can begin with high-risk services through inventory, pinned dependencies, pipeline permission review and admission verification.

Define the attack to stop

Threats include compromised dependencies, stolen CI credentials, persistent runners and artifacts replaced after approval. The model determines the evidence required. Signing an image does not prove the repository was reviewed when the build process is not linked in a verifiable way.

Provenance and SBOM serve different jobs

Provenance explains who and how something was built; the SBOM lists components. Both need to be attached by digest to the immutable artifact. Generating them without preserving that relationship creates documents that are difficult to verify. Managed, ephemeral builders reduce undetected changes.

Sign with short-lived identity

Sigstore links a signature to workflow identity without distributing permanent keys. The transparency log adds time evidence. Policy should validate issuer, expected identity, repository, workflow and digest; checking only that a signature exists accepts the wrong signers.

Enforce policy progressively

Start by observing and reporting, then warn and finally block critical services. Exceptions need owners and expiry. Rollout should measure failures, recovery time and coverage so security becomes an everyday capability instead of a manual ceremony.

Trust evidence

Maturity arrives when production can prove where its running software came from. SLSA and Sigstore do not replace review, isolation or least privilege; they connect those practices so policy can verify them.