Security
Software supply chain: evidence over implicit trust
Provenance, signatures and policy to know which code produced an artifact and under which process.
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

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.
Teaching case
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
| Situation | Choice | Tradeoff |
|---|---|---|
| Mutable image tag | Deploy and verify by digest. | Delivery must retain that exact reference. |
| Signature present | Validate issuer and expected identity. | Another signer does not satisfy the policy. |
| Emergency exception | Limit artifact, owner and duration. | Review and reconcile after recovery. |
Scroll the table to compare all three columns.
Put it into practice
Rehearse rejection before enforcement
- Submit missing evidence and an unauthorized signer.
- Change the approved digest and check rejection.
- Simulate verifier downtime and execute recovery.
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.
Continue reading
AI and agents
MCP agents: useful by design, safe by control
How to expose tools to an agent without turning every integration into an implicit permission.
Cloud and platform
The internal platform now serves teams and agents
Golden paths, self-service and policies for organizations where people and agents consume the same platform.