Container image security conversations focus heavily on the build phase: scan the image, harden it, gate on CVE thresholds before deployment. This is necessary work. But it addresses only one half of the security picture.
The other half is what happens after deployment. Images change, containers drift, admitted images can have vulnerabilities that were not yet known at deploy time, and Kubernetes admission policies that seemed comprehensive turn out to have gaps. Runtime visibility is the control that covers what image security alone cannot.
The Deploy-Time to Runtime Gap
When a container image passes your security gate and is deployed to Kubernetes, three things are true:
- The image passed your CVE threshold at the time of scanning
- New CVEs may have been disclosed since the scan
- The running container may not stay identical to the deployed image
Each of these creates a gap between what you approved and what is running in production.
New CVE disclosure: A container image that passed a zero-Critical CVE gate yesterday may have Critical CVEs today. Vulnerabilities are disclosed continuously. An image that was clean at deployment becomes vulnerable as the CVE database updates. Without continuous scanning of running images, this gap grows silently.
Runtime drift: Containers in production can be modified through exec sessions, volume mounts, or in-memory techniques. The running container may not match the approved image. Admission control that verified the image at pod creation time does not continuously verify that the running container matches that image.
Admission policy gaps: Kubernetes admission controllers validate pod creation, not pod modification. A pod admitted with a compliant image can be exec’d into and modified. Admission control is a point-in-time verification.
What Runtime Visibility Adds?
Runtime visibility means observing what is actually happening inside running containers — not just what was in the image at build time.
Behavioral monitoring: What processes are running? What system calls are being made? What network connections are being established? A web server container should be accepting HTTP connections and forwarding them to an application. If it starts making outbound connections to unusual IP addresses, that is a behavioral anomaly that indicates something has changed.
Drift detection: Compare the running state of a container against its approved baseline image state. New files written to the filesystem, new processes running, new network connections established — these are drift signals.
CVE correlation with runtime data: A scanner can tell you that a package has a CVE. Runtime visibility can tell you whether that package is executing in the running container. The combination changes the severity assessment: a Critical CVE in a package that is demonstrably not executing has lower effective risk than a Medium CVE in a package that is heavily used.
“Image scanning tells you what the threat potential is. Runtime visibility tells you what the actual exposure is. The difference between these two matters for prioritization.”
The Blast Radius Argument for Pre-Hardened Images
Runtime security and image security are more closely related than they might appear. Pre-hardened images — images from which unused packages have been removed — directly reduce the blast radius of runtime security events.
When a container is compromised at runtime, the severity of the incident depends heavily on what tools are available inside the container. A container with a full Ubuntu toolset gives an attacker shell access, networking utilities, and potentially package management capabilities. A hardened container with only the application’s runtime dependencies gives the attacker a much more constrained environment.
Container security at the image layer thus directly supports runtime security: the image hardening you did before deployment limits what an attacker can do with a runtime compromise.
Kubernetes-Specific Runtime Security Controls
Several Kubernetes-native controls extend image security into the runtime environment:
Immutable pod specs: Configure Kubernetes to prevent post-deployment modification of running pods. This does not prevent exec sessions (exec is a legitimate operational capability), but it prevents changes to pod specs that could introduce new images or configurations.
Kubernetes audit logging: Enable audit logging for exec operations. Every kubectl exec is a potential security event. Audit logs capture who exec’d into which pod, when, and what commands were run if command logging is enabled.
Admission controller continuous enforcement: OPA/Gatekeeper and Kyverno can enforce policies at admission time. Pairing this with image signing ensures that only signed, verified images are admitted — and that images are re-verified if pods are restarted.
Network policy as runtime control: Network policies do not change after pod deployment unless modified. They continue to restrict pod communication throughout the pod’s lifetime. Well-defined network policies that limit what compromised containers can connect to are a runtime control even though they are configured at deployment time.
The Runtime BOM Concept
A runtime BOM (Bill of Materials) extends the static SBOM concept into the running container. Where a static SBOM lists packages present in the image, a runtime BOM captures packages that are actually executing in the running container.
The runtime BOM enables a more precise security assessment:
- Packages in the image that are not in the runtime BOM are candidates for removal in the next image update
- New packages that appear in the runtime BOM but were not in the original image SBOM indicate drift
- CVE assessment against the runtime BOM prioritizes findings in code that is actually executing over findings in dormant packages
Docker security tool capabilities that produce and maintain runtime BOMs for running containers give security teams the data to make continuous security decisions rather than point-in-time assessments.
Frequently Asked Questions
What is container image security?
Container image security is the practice of identifying and reducing vulnerabilities in the packages, libraries, and dependencies that make up a container image before and after deployment. It encompasses scanning images for known CVEs, hardening images by removing unused components, signing images to verify integrity, and monitoring running containers for runtime threats.
What is the role of a Docker image in container deployment?
A Docker image is the immutable artifact that defines what runs inside a container. It packages the application code, language runtime, dependencies, and configuration into a distributable unit that Kubernetes pulls from a registry and instantiates as a running container. The security properties of the image — its CVE count, package footprint, and signing status — directly determine the security posture of the deployed container.
What happens to container image security after deployment in Kubernetes?
After deployment, security gaps can emerge even from images that passed their pre-deployment security gates. New CVEs may be disclosed against packages in the running image, containers may drift from their original state through exec sessions or volume mounts, and admission policies only validate images at pod creation time. Runtime visibility — behavioral monitoring, drift detection, and continuous CVE scanning — is required to maintain security coverage throughout the container’s operational life.
Can a container image become vulnerable after it is deployed?
Yes. A container image that passed a zero-Critical CVE threshold at deployment can accumulate Critical CVEs as new vulnerabilities are disclosed against its packages. Because CVE databases are updated continuously, an image that was clean yesterday may have known Critical vulnerabilities today. Continuous scanning of running images, rather than only point-in-time scanning at build or admission, is needed to detect this growing gap.
The Security Posture Across the Full Lifecycle
The complete container security model covers three phases:
Build: Image hardening reduces CVE count to the minimum necessary for application function. Signing creates a verifiable artifact.
Admission: Admission controllers verify signing, enforce CVE thresholds, and check policy compliance before pods are created.
Runtime: Behavioral monitoring, drift detection, and continuous CVE assessment maintain security visibility throughout the container’s operational life.
Each phase has controls that the other phases cannot replicate. Build-phase hardening cannot detect runtime drift. Admission-phase policy cannot catch new CVE disclosures after deployment. Runtime monitoring cannot prevent a vulnerable image from being built. The security posture is complete only when all three phases have active controls.