Stackbook Logo
security-complianceemerging · medium operational burden

Artifact Signing and Supply-Chain Verification

Also known as: sigstore-cosign, slsa-provenance, sbom-verification

Intent

Prove where a build artifact came from and that it is unmodified, and refuse to deploy anything that cannot be verified.

Problem

Compromised dependencies, build servers or registries can inject malicious code that deploys as if it were legitimate. Without provenance, operators cannot tell a genuine image from a tampered one.

Forces

  • •Builds pull in many third-party dependencies
  • •Registries and CI systems are attack targets
  • •Long-lived signing keys are hard to protect
  • •Verification must be enforced automatically at deploy time

Solution

Overview

Supply-chain security shifts trust from where an artifact is stored to evidence about how it was built. A signature binds a digest to an identity; provenance records the source, builder and inputs; an SBOM lists components so new vulnerabilities can be traced.

Adopt it incrementally: first generate SBOMs and pin dependencies, then sign images in CI, then run verification in audit mode in the cluster, and finally enforce. Measure with SLSA levels as a roadmap and track how many production workloads are verified versus exempt.

How it works

CI (ephemeral, OIDC identity)
  build image from locked deps -> digest sha256:abc
  cosign sign  registry/app@sha256:abc   # keyless, logged in Rekor
  attest provenance + SBOM
Deploy:
  admission policy:
    verify signature, issuer == our CI workflow identity
    verify provenance: source repo main branch, builder trusted
    deny if unsigned, tag-only reference, or policy fails

Reference images by digest so what is verified is exactly what runs.

Pitfalls

  • Signing but never verifying. The check at admission is the control.
  • Verifying tags, which can be repointed.
  • Long-lived private signing keys on developer laptops or CI variables.
  • Treating a valid signature as proof the code is safe; scan and review dependencies too.
  • Fail-open admission policies and permanent exceptions.
  • Unpinned dependencies and mutable base images.

Key takeaways

  • Sign by digest, verify at deploy, and fail closed.
  • Prefer keyless, identity-bound signing with transparency logs.
  • Attach provenance and SBOM, and enforce policy on them.
  • Pair with pinned dependencies and hardened, ephemeral builders.

✓ When to Use

  • •Container and binary delivery to production
  • •Regulated or high-value software
  • •Organizations consuming many third-party packages

✗ When Not to Use

  • •Throwaway prototypes
  • •Environments with no enforcement point to verify
  • •As a substitute for dependency review and vulnerability scanning

Pros

  • +Detects tampering between build and run
  • +Provenance supports incident response
  • +Policy gates enforce build standards

Cons

  • −Pipeline and admission policy complexity
  • −Signing proves origin, not safety
  • −Break-glass paths can undermine enforcement

Cost Profile

Infrastructure

Low to medium — signing, registry and policy engine

Operational

Medium — policy and key or identity management

Cognitive

Medium to high

Failure Modes

  • Compromised CI identity signs malicious artifacts

  • Mutable tags deployed instead of digests bypass verification

  • Admission controller outage blocks deploys or is set to fail-open

Real-World Examples

Alternatives

    Related Patterns

      Competency Domains

      security compliancereliability ops