Container Security: Scanning Docker and Kubernetes
A development team pushes a new container image to production at 2:14 PM. At 2:16 PM, the image is running across 47 pods in three availability zones. At 2:18 PM, a security researcher publishes a Critical CVE affecting the base image -- the same Alpine 3.18 layer that 200+ images in your registry inherit from. By the time your weekly scan runs on Sunday night, the vulnerable image has served millions of requests across infrastructure you believed was current.
This is the container security problem: velocity and immutability working against traditional vulnerability management timelines.
Why This Matters Now
Container adoption crossed a threshold in 2024-2025 where most organizations deploying to public cloud run containers as their default compute primitive. Kubernetes is no longer the bleeding edge -- it is the standard. But security practices have not caught up to the deployment model.
The xz backdoor (CVE-2024-3094) demonstrated how supply chain compromise propagates through container ecosystems. A single compromised library, baked into base images, distributes automatically to every downstream consumer. The attack surface is not the container itself -- it is the dependency graph underneath it.
Meanwhile, CISA BOD 26-04 and the NVD April 2026 policy change mean organizations must detect and remediate vulnerabilities faster than ever. In container environments where a single base image vulnerability affects hundreds of running instances, the blast radius of slow detection is geometrically larger than in traditional server environments.
The Container Security Lifecycle
Container security is not a tool or a scan. It is a set of controls mapped to the four phases of a container workload lifecycle: build, store, deploy, and run. Gaps at any phase create exposure that later phases cannot fully compensate for.
Build: Shift-Left Image Scanning
The cheapest place to catch a vulnerability is before the image leaves the CI/CD pipeline. Build-time scanning inspects the image layers for:
- OS package vulnerabilities -- outdated or vulnerable packages in the base image (Alpine apk, Debian apt, RHEL yum)
- Application dependency vulnerabilities -- known CVEs in npm, pip, Maven, Go module, or Rust crate dependencies
- Hard-coded secrets -- API keys, private keys, database credentials, tokens baked into image layers (every layer is extractable; "deleted" files in earlier layers are still accessible)
- Misconfigurations -- running as root (UID 0), unnecessary packages installed, world-writable directories
- License compliance -- dependencies with incompatible licenses for your distribution model
The operational model: scanning runs as a pipeline gate. Images with Critical or High findings do not proceed to the registry. Developers receive immediate feedback with the specific package, CVE, and fixed version. The fix happens in the Dockerfile, not in production.
Here is the contrarian position: teams that gate only on Critical findings and let High findings through are buying speed with risk debt. A CVSS 8.5 with an EPSS score above 0.7 is more dangerous than a CVSS 9.2 that has no known exploit. Gate on exploitability, not just severity.
Store: Registry Security
Your container registry is a software distribution system. Treat it like one:
Access control -- who can push images determines what runs in production. Separate push permissions from pull permissions. Restrict push to CI/CD service accounts; humans should not push directly.
Image signing and verification -- sign images at build time with a verifiable identity (Cosign, Notary). Verify signatures at pull time. Without signing, a compromised registry or MITM attack can substitute images. The xz backdoor (CVE-2024-3094) would have been caught by artifact signing if the compromised library were a container image rather than a source-level dependency.
Continuous re-scanning -- images in the registry that passed scanning last week may have new CVEs disclosed against them today. Re-scan stored images continuously against updated vulnerability databases. Alert when an image in active deployment acquires a new Critical finding.
Retention policies -- images that have not been pulled in 90 days should be candidates for deletion. Stale images with known vulnerabilities sitting in registries are a liability even if they are not deployed -- they represent a lateral movement target if registry access is compromised.
Deploy: Admission Control
Kubernetes admission controllers are the enforcement point between "image exists" and "image runs." They evaluate deployment requests against policies and reject non-conforming workloads before a single pod starts.
Effective admission policies:
- Block unscanned images -- if the image has not passed scanning, it does not deploy. No exceptions for "just testing."
- Block Critical/High findings -- the same gate that exists in CI/CD should exist at admission. Drift (hotfixes pushed outside the pipeline) gets caught here.
- Require non-root execution -- containers running as UID 0 can escape to the host kernel via unpatched privilege escalation vulnerabilities. Default-deny root.
- Enforce resource limits -- unbounded CPU/memory is a denial-of-service vector (noisy neighbor at best, resource exhaustion attack at worst).
- Restrict image sources -- allow pulls only from your private registry. Block public Docker Hub, GitHub Container Registry, or other uncontrolled sources in production namespaces.
- Verify image signatures -- reject images that fail cryptographic signature verification.
Run: Runtime Detection and Response
Post-deployment, containers need behavioral monitoring. Traditional endpoint agents are poorly suited to ephemeral workloads, so container-native runtime security operates differently:
Process monitoring -- alert on unexpected process execution. A web server container spawning /bin/sh or curl is anomalous. Build behavioral profiles during normal operation; alert on deviation.
File system monitoring -- containers with read-only root filesystems should never have write events. Any file creation in a read-only container is a strong indicator of compromise.
Network monitoring -- containers should communicate only with approved destinations (other services in the mesh, external APIs in an allowlist). Outbound connections to unexpected IP ranges suggest data exfiltration or C2 communication.
Privilege escalation detection -- monitor for capabilities being added at runtime, namespace escapes, or attempts to access the host kernel through /proc or device files.
Drift detection -- the running container should match the deployed image. Runtime modifications to a container (installing packages, downloading binaries) indicate either a configuration management failure or active compromise.
Kubernetes-Specific Attack Surface
Kubernetes is not just a container runtime -- it is a distributed system with its own control plane, network fabric, and secret management. Each component introduces attack surface.
Control Plane Hardening
API Server -- the central management point. Every kubectl command, every admission webhook, every controller-manager action goes through the API server.
- Enable RBAC with least-privilege roles (not cluster-admin for developers)
- Restrict network access to the API server (not internet-facing)
- Enable audit logging for all mutating operations
- Use TLS for all API traffic (enforce mutual TLS where possible)
etcd -- stores all cluster state including Secrets (which are base64-encoded, not encrypted, by default).
- Encrypt etcd data at rest using a KMS provider
- Restrict network access to etcd to only the API server
- Enable client certificate authentication
- Regular encrypted backups with integrity verification
Kubelet -- the agent running on each node that manages pods.
- Disable anonymous authentication
- Enable certificate rotation
- Restrict read-only port access
- Implement node authorization (not ABAC)
Network Policies
By default, Kubernetes allows unrestricted pod-to-pod communication across all namespaces. This is the equivalent of running a flat network with no segmentation -- any compromised pod can reach any other pod.
Implement network policies to enforce microsegmentation:
- Default-deny all ingress and egress at the namespace level
- Explicitly allow only required communication paths
- Isolate sensitive namespaces (databases, secret managers, monitoring) from application namespaces
- Log denied traffic for detection purposes
Pod Security Standards
Kubernetes Pod Security Standards define three enforcement levels:
| Level | Purpose | Restrictions |
|---|---|---|
| Privileged | System components (CNI, storage drivers) | None |
| Baseline | Prevents known privilege escalations | No hostNetwork, no privileged containers, no hostPath |
| Restricted | Maximum workload security | Non-root, read-only root FS, no capabilities beyond minimum |
Apply Restricted to all application workloads. Apply Baseline to infrastructure components that need host access. Apply Privileged only to system-level DaemonSets that genuinely require it. Most applications can run under Restricted with zero code changes -- the Dockerfile just needs USER nonroot and the deployment spec needs securityContext.readOnlyRootFilesystem: true.
Supply Chain Security for Container Images
The xz backdoor (CVE-2024-3094) crystallized what container security practitioners already knew: your security posture is bounded by the integrity of your supply chain.
Base image provenance -- know where your base images come from. Pin to digest (sha256), not tag. Tags are mutable; someone with push access can change what alpine:3.18 points to. Digests are immutable content addresses.
Multi-stage builds -- separate build dependencies from runtime dependencies. Your production image should not contain compilers, debug tools, or test frameworks. Smaller images have smaller attack surfaces and faster scan times.
SBOM generation -- produce a Software Bill of Materials for every image at build time. When CVE-2024-3094 drops, you need to know in minutes which images contain the affected library, not hours.
Dependency pinning -- pin all dependencies to exact versions. Ranges (^1.2.3, ~2.0) allow automatic upgrades that may introduce compromised versions. Accept the maintenance cost of explicit version bumps in exchange for supply chain control.
Compliance Mapping
Container security controls map to the same compliance requirements as traditional infrastructure -- the implementation differs, not the intent:
| Requirement | Container Implementation |
|---|---|
| NIST 800-53 CM-7 (Least Functionality) | Minimal base images, multi-stage builds, no unnecessary packages |
| NIST 800-53 SI-2 (Flaw Remediation) | Image scanning, base image updates, registry re-scanning |
| NIST 800-53 AC-6 (Least Privilege) | Non-root containers, dropped capabilities, RBAC |
| DISA Kubernetes STIG | Checks covering control plane, network, workload |
| DISA Docker STIG | Daemon configuration, image management, runtime |
| FedRAMP | All applicable 800-53 controls contextualized to containers |
For organizations pursuing FedRAMP authorization with containerized workloads, the authorization boundary includes the orchestration platform, the container runtime, and the images themselves. Scan results, admission control logs, and runtime security alerts all become continuous monitoring evidence.
Key Takeaways
- Container security spans four lifecycle phases: build (pipeline scanning), store (registry security), deploy (admission control), and run (runtime detection)
- A single vulnerable base image propagates to every container instance -- blast radius scales with deployment velocity
- Kubernetes adds its own attack surface: API server, etcd, kubelet, and default-allow network policies all require hardening
- Pin base images to digest (not tag), generate SBOMs, and treat your registry as a software distribution system
- Pod Security Standards (Restricted level) should be default for all application workloads
- Supply chain integrity (image signing, provenance verification) is the boundary condition for everything else
How Advisedly Helps
Advisedly integrates with container scanning tools and Kubernetes security platforms to provide unified vulnerability visibility across containerized and traditional infrastructure. The platform maps container findings to 500+ compliance frameworks, tracks remediation alongside infrastructure vulnerabilities, and generates the evidence that auditors require for authorization boundaries that include container workloads. For organizations deploying Advisedly itself in containerized environments, the platform ships as Docker images with Helm charts for both connected and air-gapped Kubernetes deployments. Contact begin@advisedly.ai to secure your container infrastructure.
Frequently Asked Questions
How is container scanning different from traditional vulnerability scanning?
Traditional vulnerability scanning probes running systems over the network or via authenticated access. Container scanning inspects image layers statically -- analyzing the filesystem contents of an image without running it. This enables shift-left detection (finding vulnerabilities before deployment) but misses runtime-specific issues (configuration drift, behavioral anomalies). You need both: image scanning in the pipeline and runtime security in production.
Should we scan base images or only our application images?
Both, but base images are the higher-leverage target. A single base image vulnerability affects every application image derived from it. Maintain an approved base image catalog, scan those continuously, and rebuild all downstream images when a base image updates. Application-layer scanning catches dependency-specific CVEs that base image scanning misses.
What is the minimum container security stack for compliance?
For FedRAMP or CMMC: image scanning in CI/CD (build gate), continuous registry scanning (stored image freshness), admission control (deploy enforcement), and runtime monitoring (detect post-deployment). You also need audit logging of all Kubernetes API operations and network policies enforcing segmentation. This maps to SI-2, CM-7, AC-6, AU-2, and SC-7 respectively.
How do we handle vulnerabilities in images we do not control?
Third-party vendor images that ship without source code (commercial software, proprietary databases) require a different approach: scan them, document known vulnerabilities, implement compensating controls (network isolation, monitoring), and maintain vendor communication about their patching cadence. Document this in your POA&M with the vendor remediation timeline as the milestone.
Does container immutability make patching easier or harder?
Both. Easier: you never patch a running container. You rebuild the image with updated packages and redeploy. The deployment mechanism is the patching mechanism. Harder: you must rebuild and redeploy for every patch, which means your CI/CD pipeline must be fast enough to support the patching cadence your compliance framework demands. Organizations with slow build pipelines or manual deployment gates find container patching bottlenecked at the release process, not the scanning process.
<!-- LI hook: Your base image ships vulnerable before your scanner wakes up. -->First developed from container security architecture documentation for the Advisedly platform deployment model.