Container image security: from build through runtime

Container image security begins before docker build and ends only when a deployment is retired. CVE scanning matters, but it cannot detect every leaked secret, malicious CI stage, registry substitution or excessive runtime privilege.

NIST SP 800-190 treats images, registries, orchestrators, hosts and containers as connected risk layers.

Minimal, repeatable builds

Use small, maintained base images and pin them to an immutable digest. The latest tag does not guarantee that testing and production run the same bytes. Multi-stage builds keep compilers and build tools out of the final image.

Remove package managers, shells and diagnostic tools when the application does not need them. Avoid copying the entire repository. .dockerignore should exclude .git, local configuration, keys and test artefacts.

Keep secrets out of layers

Deleting a file in a later instruction does not remove it from an earlier layer. Supply build credentials through a build-secret mechanism. At runtime, use a secrets manager and ephemeral files or workload identity.

Scan the final image for tokens, private keys and credentials. Rotate any discovered secret; rebuilding the image alone does not invalidate the exposure.

SBOM, CVEs and context

Generate an SBOM for every release and retain it with attestations. Scan both operating-system and application dependencies. Prioritise vulnerabilities by fix availability, package use, exposure and exploitation evidence, not CVSS alone.

An image accepted today may become vulnerable tomorrow when a new CVE is published. Rescan the registry and running workloads, then deliver fixes as new immutable images.

Signatures and admission policy

Sign images and attestations from trusted CI. Admission policy should accept only artefacts from approved registries, expected workflows and within the organisation’s risk threshold.

A valid signature without pipeline protection merely proves that a compromised process signed a malicious artefact. Connect verification with software supply-chain security.

Runtime still matters

Run as non-root, with a read-only filesystem, no privileged mode, unnecessary capabilities or Docker socket mounts. Restrict network access and apply seccomp, AppArmor or SELinux profiles.

The running digest should match the approved artefact. Monitor unexpected processes, writes to system paths and outbound connections. Use the broader Kubernetes security guide for cluster controls.

Pipeline checklist

1. Pin a trusted base image by digest.
2. Build a minimal final stage without secrets.
3. Generate an SBOM and scan dependencies.
4. Sign the image and provenance in CI.
5. Enforce admission policy before deployment.
6. Run without root or unnecessary privileges.
7. Rescan registries as new CVEs emerge.
8. Retire unused and unsupported images.

A secure image is the result of a controlled lifecycle. One green scan cannot replace provenance, admission controls and runtime protection.

---

The gate between registry and cluster

A pull-request scan ages quickly because new CVEs appear after the image is built. Rescan the registry, assign image owners and set exposure-based SLAs. Admission policy should allow only approved registries, verified signatures or attestations and immutable digests.

A minimal image reduces surface but does not remove application defects. At runtime combine a non-root user, read-only filesystem, restricted capabilities, resource limits and seccomp profiles. Exceptions need a workload, reason and expiry. Retesting covers shell execution, writes to sensitive paths and cloud metadata access.

Sources: NIST SP 800-190, SLSA Specification, Kubernetes — Images.