Container Image Vulnerabilities and Why Runtime Drift Still Matters

Image Scanning Is Necessary but Not Sufficient

Container security programs frequently start and stop with image scanning. That is a valuable starting point, but production reality is significantly more complex. What runs in the cluster is not only the image that was built and scanned. It is also the runtime behavior, mounted secrets, spawned processes, established network paths, and any state drift that accumulates after deployment.

Why Runtime Drift Matters

Runtime drift describes the gap between what the platform expected to run and what is actually executing now. That gap can include:

packages installed into a running container that were not in the original image.

processes spawned that do not match the expected application baseline.

network connections established to destinations outside of normal application behavior.

secrets mounted at runtime that were not visible during the image build scan.

privilege escalations that the container runtime policy did not anticipate.

Each of these represents a real security state that image scanning alone cannot detect. A scanned-clean image can become a compromised container within minutes of deployment if the runtime environment is not monitored.

The Supply Chain Dimension

Image scanning does reveal an important class of risk: vulnerabilities in base images and third-party dependencies pulled at build time. This is the supply chain dimension of container security. A base image that contains a critical CVE will carry that vulnerability into every container built from it, regardless of what the application layer looks like.

Effective supply chain hygiene for containers includes:

pinning base image digests rather than floating tags to prevent silent base image updates.

tracking which CVEs are present in each image layer and which are in packages your application actually loads.

rebuilding images promptly when upstream vulnerabilities are patched.

understanding the difference between a vulnerability that exists in an image and one that is actually reachable by an attacker given your container's runtime configuration.

That last point matters significantly. A critical CVE in a library that your application does not load is different from a critical CVE in a library called on every request. Reachability context transforms the scan result from a raw count into a prioritized action list.

What Runtime Security Controls Look Like

Runtime security for containers focuses on detecting and blocking anomalous behavior after deployment. The practical controls include:

Process allow-listing: defining which processes should run inside a container and alerting when unexpected processes appear.

Network policy enforcement: restricting egress and ingress to expected destinations and generating alerts when containers attempt connections outside policy.

Filesystem immutability: treating the container filesystem as read-only where possible and detecting writes to unexpected locations.

Syscall filtering: using seccomp profiles to block system calls that the application has no legitimate need for.

Privilege constraint: enforcing non-root execution and preventing privilege escalation at the kernel level.

None of these controls can be derived from image scanning alone. They require runtime visibility.

The Kubernetes Layer

In Kubernetes environments, container security extends to the pod and cluster level. Security-relevant configurations include:

Pod Security Standards or admission controllers that enforce baseline security posture.

Network policies that restrict lateral movement between namespaces and pods.

RBAC configurations that limit which service accounts can be used for privilege escalation.

Audit logging at the API server level to detect abnormal cluster operations.

A container with a clean image and robust runtime controls can still be compromised if the Kubernetes RBAC configuration allows the service account to escalate privileges or exfiltrate secrets.

Dockerfile Security Best Practices

Hardening starts at the build stage. The table below maps common Dockerfile mistakes to the security control that fixes them:

| Practice | What to Do | Why It Matters |

| --- | --- | --- |

| Use minimal base images | FROM alpine or distroless instead of ubuntu:latest | Fewer packages = smaller CVE surface |

| Pin base image digests | FROM alpine@sha256:abc123... | Prevents silent upstream updates that introduce new CVEs |

| Run as non-root | USER nonroot before CMD | Limits blast radius of container escape |

| Drop capabilities | --cap-drop=ALL at runtime | Removes Linux capabilities the app doesn't need |

| Use multi-stage builds | Build in one stage, copy binary to clean stage | Strips build tools and compilers from production image |

| Set read-only filesystem | --read-only at runtime + tmpfs for writable paths | Detects and blocks unexpected writes |

| Apply seccomp profiles | Use Docker's default or a custom profile | Restricts syscalls the container can make |

These are build-time and runtime controls that image scanning cannot enforce. They require intentional configuration in CI/CD pipelines and container runtime policy.

MyVuln Perspective

MyVuln supports container vulnerability tracking by correlating image scan findings with CVE severity, exploitation status, and affected version ranges. When combined with runtime exposure context — whether a vulnerable container is internet-facing and what processes it exposes — the resulting prioritization reflects actual operational risk rather than an unweighted list of scan findings. MyVuln's vulnerability database tracks CVEs by affected package and version range, so teams can determine whether a CVE in a base image layer is actually reachable given the container's runtime configuration.

Image scanning gives you a build-time truth. It answers which packages were present when the image was assembled, which known CVEs were associated with the base layer and installed software at that moment, and whether the build satisfied the policies in place at the time of registry push. Runtime drift tells a different and often more operationally significant story: what actually survived into production, and what has changed since the image was approved.

The gap between scan-time and runtime state is not theoretical. A concrete drift example:

Registry scan result (approved):
  base: ubuntu:22.04
  packages: nginx 1.24.0, openssl 3.0.2
  CVEs: 0 critical, 2 low (accepted)
  Status: APPROVED ✓

Runtime state (72 hours later):
  Added post-deploy: python3, pip, requests library (debug session)
  Mounted credentials: broader scope than original approval (ops patched config)
  Active processes: /bin/bash (interactive shell — operator left open)
  Network connections: unexpected egress to 203.0.113.42:4444
  Status: CRITICAL DRIFT — investigation required

This is a critical gap: an image that passes registry scanning cleanly can degrade into a significantly different security posture through accumulated runtime modifications. The questions that matter are not only "did the image pass the scan?" but also: Is the running workload executing the expected binary? Is it making the expected system calls? Have mounted credentials changed in scope? Has interactive access into the container normalized into a persistent operational pattern?

The mature approach reads the build and runtime layers together as complementary evidence. Image scanning provides early warning at the registry gate; runtime visibility shows whether that certified state persists in production. When an organization can correlate these layers, it closes the gap between "known vulnerability at build time" and "active runtime risk." Container security thereby matures from a CI pipeline step into a continuous, living workload monitoring model that tracks what is actually running in production — not just what was approved at the registry.