Interactive Explainer

Relevant for:Mid-levelSeniorStaff

Why this matters at your level

Mid-level

Know the difference between image tags (mutable) and digests (immutable). Understand image vulnerability scanning basics (CVE databases, CVSS scoring).

Senior

Implement image digest pinning in Deployments. Set up vulnerability scanning in CI/CD (Trivy, Grype). Configure registry policies (Kyverno/Gatekeeper) to reject images from untrusted registries.

Staff

Design end-to-end supply chain security: SBOM generation, Sigstore/cosign image signing, Connaisseur or Kyverno signature verification at admission, private registry with image promotion gates.

Image Security & Supply Chain: From Build to Runtime

Container images are the package format for Kubernetes workloads. Vulnerable base images, supply chain attacks (SolarWinds-style for containers), and unsigned images have all caused real breaches. Securing the image supply chain closes the gap between "deployed" and "trusted."

~3 min read

Be the first to complete!

LIVESupply Chain Attack -- codecov Bash Uploader -- Docker Hub -- 2021

Breaking News

T+0

Codecov GCS bucket compromised; malicious bash uploader deployed

T+2mo

Malicious script runs in thousands of CI pipelines; Docker credentials exfiltrated

T+2mo 1w

Backdoored Docker Hub images pushed with same tags as legitimate images

T+2mo 2w

Codecov discloses breach; teams audit CI pipelines and registry credentials

T+3mo

Industry adopts image signing (Sigstore/cosign) and digest-pinned image references

—CI pipelines running malicious script

—Backdoored images replaced legitimate ones with identical names

—The only trustworthy image identifier

The question this raises

If you cannot trust a container image's tag to be stable and untampered, what cryptographic mechanism ensures you deploy exactly what you built?

Test your assumption first

Your Deployment references image: myapp:v2.1. A teammate pushes a security patch and re-tags the same image myapp:v2.1. Your running pods use the old image; new pods use the patched one. How do you prevent this ambiguity?

Lesson outline

What Image Supply Chain Security Solves

Tags Are Not Trustworthy

A container image tag is a mutable pointer. nginx:1.25 today is not necessarily nginx:1.25 tomorrow. Attackers who compromise a registry account can push backdoored images under existing tags. Only cryptographic digests (sha256) and signed images with verified provenance provide tamper-evident identity for container images.

Digest pinning

Use for: Reference images by sha256 digest in production Deployments: image: nginx@sha256:abc.... The digest is computed from image content -- any change produces a different digest. Ensures exact reproducibility.

Image signing (cosign)

Use for: Sign image after build with cosign. Store signature in registry. Kyverno or Connaisseur webhook verifies signature at admission time. Unsigned or wrongly-signed images rejected before pod creation.

Private registry with promotion gates

Use for: Images must pass vulnerability scan, signing, and SBOM before being promoted from build registry to production registry. Admission controller enforces: only images from production registry allowed. Public images (Docker Hub) cannot be deployed directly.

The System View: Supply Chain Security Pipeline

Source Code (Git)
    |  [Build]
    v
CI/CD Pipeline:
  1. docker build myapp:git-abc1234
  2. Trivy scan -> CRITICAL CVEs? -> fail build
  3. cosign sign myapp:git-abc1234  (keyless via OIDC)
  4. SBOM generated (syft)
  5. Push to internal registry: registry.company.com/myapp:v2.1
    |
    v  [Deploy]
Kubernetes Admission:
  Kyverno policy: only registry.company.com/* images
  cosign verifier: signature must be from ci-sa@company.com
  -> passes: pod created with image pinned to digest
  -> fails: pod rejected -- no signature from trusted CI identity

Trust chain:
  Git commit -> signed build -> signed image -> verified admission
  Any break in chain -> blocked before deployment

Every step from source to runtime has a cryptographic link; broken chain = blocked at admission

Image Security Evolution

Situation

Before

After

Public Docker Hub images with mutable tags in production

“Backdoored image pushed under same tag; next deployment or restart pulls compromised version; no detection”

“Digest-pinned images from private registry; cosign signature verified at admission; Docker Hub images blocked by Kyverno policy”

Zero-tolerance CVE policy blocks all deployments

“Scanner finds ANY critical CVE in base image; CI pipeline fails; team cannot deploy; frustration with security tooling”

“Gate on: CRITICAL CVEs with known exploits AND fix available; accept CRITICAL with no fix + alert; review weekly”

How Image Signing Works

Sigstore/cosign keyless signing in CI

→

1. CI build produces image; pushed to registry: image has sha256 digest

→

2. cosign sign --oidc-issuer=https://accounts.google.com IMAGE_DIGEST

→

3. cosign gets OIDC token from CI provider (GitHub Actions, GCP SA)

→

4. Sigstore Fulcio issues short-lived certificate binding OIDC identity to key

→

5. Signature stored in OCI registry (same repo, .sig tag) + logged to Rekor transparency log

6. Admission webhook calls cosign verify: checks signature against Rekor + verifies expected OIDC identity

1. CI build produces image; pushed to registry: image has sha256 digest

2. cosign sign --oidc-issuer=https://accounts.google.com IMAGE_DIGEST

3. cosign gets OIDC token from CI provider (GitHub Actions, GCP SA)

4. Sigstore Fulcio issues short-lived certificate binding OIDC identity to key

5. Signature stored in OCI registry (same repo, .sig tag) + logged to Rekor transparency log

6. Admission webhook calls cosign verify: checks signature against Rekor + verifies expected OIDC identity

kyverno-image-policy.yaml

1apiVersion: kyverno.io/v1
2kind: ClusterPolicy
3metadata:
4  name: require-signed-images
5spec:
6  validationFailureAction: Enforce
7  rules:
8  - name: check-image-signature
9    match:
10      resources:
11        kinds: [Pod]
12    verifyImages:
13    - imageReferences:
14      - "registry.company.com/*"
15      attestors:
keyless: signature must be from this GitHub Actions workflow OIDC identity
16      - entries:
17        - keyless:
18            subject: "https://github.com/myorg/myrepo/.github/workflows/*"
19            issuer: "https://token.actions.githubusercontent.com"
20    # Reject any image NOT from registry.company.com
This policy blocks Docker Hub, public ECR, and any non-internal registry images
21  - name: require-internal-registry
22    validate:
23      message: "Only images from registry.company.com are allowed"
24      pattern:
25        spec:
26          containers:
27          - image: "registry.company.com/*"

What Breaks in Production: Blast Radius

Image supply chain failure modes

Tag pulled with backdoored image — Registry account compromised; attacker pushes malicious image with same tag. Next pod restart or deployment pulls it. Pin to digest or use admission signature verification to prevent.
Zero-tolerance CVE policy paralysis — Every base image has some CVE. Zero-tolerance blocks all deployments. Gate on: CRITICAL with available fix. Accept CRITICAL without fix with a tracked exception. Review weekly rather than blocking every deploy.
Signature verification webhook unavailable — Like all admission webhooks: if the verifier is down with failurePolicy: Fail, all pod creates are blocked. Run verifier as 3-replica HA deployment with PDB.
imagePullPolicy: Always causes slow startups — Always pulls the image on every pod start -- even if it is already cached. Slows pod startup, increases registry load. Use IfNotPresent with digest-pinned images (digest guarantees freshness; no pull needed if digest is cached).

Using mutable tag in production deployment

Bug

spec:
  containers:
  - name: app
    image: myapp:v2.1          # tag is mutable pointer
    imagePullPolicy: IfNotPresent
    # If myapp:v2.1 is reassigned to backdoored image:
    # running pods: still use old cached image
    # NEW pods: pull backdoored image
    # No alert, no indication of change

Fix

spec:
  containers:
  - name: app
    image: registry.company.com/myapp@sha256:abc123def456
    imagePullPolicy: IfNotPresent
    # sha256 digest is immutable: same digest = same image content
    # If attacker pushes new image under v2.1: different digest
    # Your deployment still references old (safe) image

Pin images to their sha256 digest in production Deployments. The digest is computed from image content -- it cannot be reassigned. Use tags in CI to reference images by semantic version; record the digest post-push and use that in production manifests.

Decision Guide: Image Security Controls

Is image integrity (tamper detection) a requirement?

YesImplement cosign signing + admission verification; pin all prod images to digests

NoDigest pinning alone prevents tag reassignment attacks; simpler than signing

Do you pull images from public registries (Docker Hub)?

YesImplement private registry with promotion gates; Kyverno policy blocking non-internal registries

NoInternal registry with proper access controls is sufficient baseline

Do CVE scanners block your CI pipeline frequently?

YesGate on CRITICAL with fix available only; triage monthly; avoid zero-tolerance

NoCurrent scanning is effective; maintain the gate; add new scanners for supply chain (SBOM, provenance)

Cost and Complexity: Image Security Controls

Control	Threat addressed	Implementation effort	Operational cost	When to implement
Digest pinning	Tag reassignment attacks	Low	Low	All production clusters now
Vulnerability scanning	Known CVE exploitation	Medium	Medium (triage)	CI/CD pipeline gate
Private registry + promotion	Untrusted public images	Medium	Medium	Production environments
Image signing (cosign)	Backdoored image substitution	High	Low (automated)	Compliance/high-security envs
SBOM generation	Supply chain transparency	High	Low	Regulated industries

Exam Answer vs. Production Reality

1 / 3

Image tag vs digest

📖 What the exam expects

Tag (e.g., nginx:1.25) is a mutable pointer -- it can be reassigned. Digest (sha256:abc...) is immutable -- it uniquely identifies a specific image content.

Toggle between what certifications teach and what production actually requires

How this might come up in interviews

Security architecture questions about container supply chain and DevSecOps questions about CI/CD pipeline security.

Common questions:

What is the difference between an image tag and a digest?
How would you prevent pulling a backdoored image that has the same tag as a legitimate one?
What is Sigstore and how does image signing work?
How do you balance blocking CVEs in CI without blocking all deployments?

Strong answer: Mentions cosign + Sigstore for keyless signing, Trivy in CI/CD gate on CRITICAL severity, and Kyverno admission policy requiring images from trusted registries with valid signatures.

Red flags: Using :latest in production, or thinking a tag is a stable identifier for an image.

Related concepts

Explore topics that connect to this one.

Suggested next

Often learned after this topic.

Runtime Security: Falco and Anomaly Detection

Ready to see how this works in the cloud?

Switch to Career Paths for structured paths (e.g. Developer, DevOps) and provider-specific lessons.

View role-based paths

Continue learning

Runtime Security: Falco and Anomaly Detection

Discussion

Questions? Discuss in the community or start a thread below.

Join Discord

Image Security & Supply Chain: From Build to Runtime

What Image Supply Chain Security Solves

The System View: Supply Chain Security Pipeline

How Image Signing Works

What Breaks in Production: Blast Radius

Decision Guide: Image Security Controls

Cost and Complexity: Image Security Controls

Exam Answer vs. Production Reality

Discussion

In-app Q&A

Image Security & Supply Chain: From Build to Runtime

What Image Supply Chain Security Solves

The System View: Supply Chain Security Pipeline

How Image Signing Works

What Breaks in Production: Blast Radius

Decision Guide: Image Security Controls

Cost and Complexity: Image Security Controls

Exam Answer vs. Production Reality

Discussion

In-app Q&A