Container Image Security Checklist

A container image security checklist is your practical, enforceable way to keep risky images (vulnerabilities, embedded secrets, tampered artifacts, and untrusted sources) out of production. Image security is supply-chain security: control inputs, verify provenance, and block what doesn’t meet policy—before it reaches your cluster.

How it works

At a practical level, image security is a pipeline of guardrails—some in the build system, some in the registry, and some at deployment. The goal is repeatability and enforcement, not just visibility.

1) Build hardening (reduce what can go wrong)

What to do next

• Use minimal, well-maintained base images (distroless/minimal OS) and standardize on a small set of approved bases.
• Pin base images and dependencies to immutable versions (prefer digest pinning over mutable tags like latest).
• Use multi-stage builds to keep compilers, package managers, and build tools out of the final runtime image.
• Run builds in clean, ephemeral CI workers; avoid “pet builders” that accumulate creds and artifacts.
• Prevent secrets from entering layers: never COPY .env, SSH keys, or cloud credentials into build context; use build-time secrets mechanisms.
• Add an explicit control for secrets hygiene (what to scan, what blocks release). If you need shared terminology, see: what is trojan malware (malicious payload risk is part of why base-image governance matters).

Why it matters

Most real incidents start upstream: a compromised base image, a malicious dependency, or a credential accidentally baked into a layer. If you minimize and standardize inputs, the security team can actually enforce and monitor meaningful policy.

2) Scan and gate (visibility without enforcement is theater)

What to do next

• Run vulnerability scanning on every build and on a schedule for images already in your registry (new CVEs appear after the image is built).
• Gate promotions with policy: fail builds on critical issues you consider non-negotiable (for example: known exploited vulnerabilities, embedded secrets, or running as root without justification).
• Separate “dev feedback” from “prod gate”: developers need fast results; production needs strict policy.
• Use weekly or daily vulnerability intelligence to tune gates to what’s actively exploited; a useful reference format is like 2026 04 25 digest critical vulnerability roundup.

Why it matters

Scanning alone doesn’t stop risky deployments. You need automated gates that prevent images from moving into environments where impact is high.

3) Generate and store SBOMs (make content auditable)

What to do next

• Generate an SBOM at build time and attach it to the image (or store it alongside the digest in your artifact system).
• Use SBOMs for rapid impact analysis when a library issue drops (e.g., “which deployed images contain package X?”).
• Track both OS packages and application dependencies (language ecosystems often matter more than OS).

Why it matters

Without an SBOM, you’re guessing what’s in production. With one, you can answer executive questions quickly: exposure scope, affected services, and remediation priority.

4) Sign images and verify at deploy (stop tampering and untrusted sources)

What to do next

• Sign images after they pass policy gates in CI.
• Enforce signature verification at deploy time (Kubernetes admission policy) so the cluster only runs what your CI attested to.
• Prefer signing by digest and enforcing “only allow from approved registries + verified signatures.”

Why it matters

Signatures shift you from “we think this came from our pipeline” to “the cluster cryptographically verifies it.” This directly reduces the risk of registry poisoning, tag swapping, and shadow IT images.

5) Registry controls (treat the registry like production infrastructure)

What to do next

• Require authn/authz: least-privilege for push/pull; separate writers from readers.
• Enable immutability or “tag protection” for release tags; ideally, deploy by digest, not tag.
• Enable audit logging and alerting on pushes, deletes, retags, and permission changes.
• Implement retention policies so old/vulnerable images don’t linger forever without reason.

Why it matters

If an attacker can push or retag in your registry, they can ship code into your environment without touching your CI system.

6) Deployment-time policy (Kubernetes admission is your last line)

What to do next

• Block images that are unsigned, unscanned, from unapproved registries, or using disallowed configurations (e.g., privileged, hostPath, or root where not justified).
• Require explicit image digests in manifests for production.
• Enforce runtime hardening defaults (non-root, read-only filesystem, dropped Linux capabilities) as policy.

Why it matters

Even with good CI, clusters often run “exceptions.” Admission policy is how you keep exceptions visible, reviewed, and bounded.

Technical notes (commands you can adapt)

# Pin by digest (avoid mutable tags)
docker pull alpine@sha256:REDACTED_DIGEST

# Example: scan an image (tooling varies; integrate into CI)
trivy image --exit-code 1 --severity CRITICAL,HIGH myrepo/myapp:build-123

# Example: generate an SBOM (SPDX)
syft packages myrepo/myapp:build-123 -o spdx-json > sbom.spdx.json

# Example: sign an image (Sigstore Cosign)
cosign sign --key cosign.key myrepo/myapp@sha256:REDACTED_DIGEST

# Example: verify signature before allowing promotion/deploy
cosign verify --key cosign.pub myrepo/myapp@sha256:REDACTED_DIGEST

When you’ll encounter it

You’ll run into container image security checklist requirements anytime containers move from “developer convenience” to “production delivery mechanism.” The common triggers are predictable—and usually happen right before or after a security incident.

Typical scenarios

• Kubernetes adoption / platform engineering rollout: Standardizing base images, CI templates, and admission policies becomes mandatory to avoid every team doing security differently.
• Customer security reviews (SOC 2/ISO 27001) or regulated data: Auditors will ask how you prevent vulnerable or tampered images from being deployed.
• Incident response after a supply-chain event: If a compromised dependency or leaked secret shipped in an image, leadership will demand proof that it can’t happen again.
• M&A or multi-tenant environments: Shared clusters amplify blast radius; “one team’s weak image” becomes “everyone’s outage.”
• Shift-left mandates: Security is asked to integrate with CI/CD; the checklist becomes the contract between dev and security.

What to do next

• Put the checklist into CI as policy (not a document). If it’s not automated, it will be bypassed under delivery pressure.
• Define an exception process with expiry dates. Permanent exceptions become tomorrow’s incident root cause.
• Measure compliance: % images signed, % deployments pinned by digest, time-to-remediate for critical findings.

Technical notes (quick triage)

# Find images running with mutable tags in a cluster (quick triage)
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{range .spec.containers[*]}{.image}{" "}{end}{"\n"}{end}' \
  | grep -v '@sha256:' | head

# Example grep to catch obvious secrets accidentally copied into repos/build contexts
grep -RIn --exclude-dir=.git -E '(AWS_SECRET_ACCESS_KEY|BEGIN (RSA|OPENSSH) PRIVATE KEY|password\s*=\s*|api[_-]?key)' .