Container security needs to operate across five phases: build (selecting a minimal, hardened base image and governing the packages included), store (signing and scanning images before they reach a registry), deploy (enforcing policy gates that prevent images not meeting security thresholds from reaching production), run (monitoring container behavior at runtime for anomalies that indicate compromise), and govern (continuous monitoring, SBOM maintenance, and remediation as new CVEs are disclosed against container components).

The most important decision in the build phase is the base image selection. The base image determines the attack surface of every container built on top of it. A base image pulled from DockerHub with hundreds of packages that the application does not need carries every vulnerability in those packages into every container derived from it. A minimal, distroless base image built from verified source with only essential components has a fraction of that attack surface from the start.

A hardened image has fewer vulnerabilities at deploy time, but it cannot prevent all classes of runtime attack. A compromised application inside a hardened container can still be exploited through application-layer vulnerabilities, network paths, or injected runtime payloads. Runtime security monitors for behavior that deviates from the established baseline: unexpected network connections, file system writes outside expected paths, process spawning anomalies. It is a complementary layer to image hardening, not a substitute.