It begins before an image is built and continues through deployment, operation, incident response, and retirement. It is not limited to scanning an image for known software vulnerabilities.
Containers normally provide operating-system-level isolation and share the host kernel, unlike virtual machines with separate guest kernels. Their security therefore depends on both the container configuration and the surrounding platform. A privileged container, dangerous host mount, exposed orchestrator API, compromised registry, or vulnerable node can undermine otherwise well-built application code.
Key points
Secure the supply chainUse minimal maintained base images, pin and verify dependencies, protect build systems and registries, produce provenance, scan artifacts, and rebuild when fixes become available.
Harden deploymentRun as a non-root user, drop unnecessary Linux capabilities, restrict privilege escalation and host access, use read-only filesystems where practical, and enforce resource and admission policies.
Protect the platformLimit orchestrator and node administration, apply RBAC and workload identities, segment network paths, protect secrets and control-plane data, and keep hosts and runtime components patched.
Monitor and respondRecord deployment and audit events, detect unexpected processes, files, connections, or privilege changes, preserve useful evidence, and replace compromised workloads from trusted artifacts.
Important limitationA container is not automatically a strong security boundary. Shared-kernel flaws, privileged modes, weak policy, exposed management interfaces, or unsafe host integration can enable escape or broader platform compromise.