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.

José Higinio Sosa3 min read
SLSASigstoreDevSecOps

The central idea

A signature matters when policy checks the expected signer, exact artifact and evidence of how it was built.

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.

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.

An image signed by the wrong workflow

An image has a valid signature from a test workflow that should never publish to production. Admission that only checks for a signature accepts it. Trust requires an expected identity and provenance policy.

Bind the image digest to the repository, revision and build evidence. Provenance describes construction; an SBOM lists components. Neither proves correctness or absence of vulnerabilities. Review, isolation and dependency analysis remain necessary.

Rehearse verifier outages as well. A blocking policy needs a known recovery procedure. Scope emergency exceptions to an artifact, environment, owner and expiration. Start in observation mode and inspect rejections before expanding enforcement.

Choices and their tradeoffs

Situations, choices and limitations
SituationChoiceTradeoff
Mutable image tagDeploy and verify by digest.Delivery must retain that exact reference.
Signature presentValidate issuer and expected identity.Another signer does not satisfy the policy.
Emergency exceptionLimit artifact, owner and duration.Review and reconcile after recovery.

Scroll the table to compare all three columns.

Rehearse rejection before enforcement

What to verify: Incorrect evidence is rejected and recovery leaves no permanent bypass.

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.