The docker security concerns that actually cause real-world incidents are a shorter, more specific list than most generic checklists suggest: containers running as root by default, Docker daemon sockets exposed to the network or mounted into containers, unpatched base image vulnerabilities inherited silently, and secrets baked into image layers. Everything else — network segmentation, resource limits, logging — matters too, but these four account for the overwhelming majority of documented container breakout and compromise incidents.
Why does running containers as root matter so much?
It matters because root inside a container is far closer to root on the host than most teams assume, and container escape vulnerabilities have repeatedly turned that closeness into full host compromise. Docker containers run as root (UID 0) by default unless a Dockerfile or runtime explicitly sets a different user, and while namespaces isolate a lot of what root can see and do, they don't eliminate every path to escape. CVE-2019-5736, a vulnerability in runc (the low-level container runtime under Docker and most other container engines), allowed a malicious container to overwrite the host's runc binary and gain root execution on the host itself — and it was directly exploitable specifically because the container was running as root. Setting USER in a Dockerfile, or runAsNonRoot at the orchestrator level, doesn't eliminate every container security concern, but it removes the precondition that made that specific class of escape possible.
How does an exposed Docker socket actually get exploited?
An exposed Docker socket (/var/run/docker.sock) is effectively a root-equivalent API to the whole host, and mounting it into a container — a common pattern for CI runners and monitoring tools that need to manage other containers — hands that same power to anything running inside. If an attacker gets code execution in a container that has the socket mounted, they can trivially spin up a new container with the host filesystem bind-mounted in, and read or write anything on the host, no exotic exploit required — it's a documented, well-known pattern, not a theoretical edge case. This is one of the most consistently repeated docker security checklist items precisely because the mistake is so easy to make (it's a common StackOverflow answer for "how do I let a container manage other containers") and so severe when it's exploited.
How much of container security risk actually comes from the base image?
A large share of it. Base image vulnerabilities are inherited silently — pulling node:18 or any full-distro base image brings along every OS package vulnerability present in that image at build time, and those accumulate the longer an image goes unrebuilt, since a stale image doesn't get security patches just by sitting in a registry. This is the mechanism behind the recurring "we scanned once at build time and never again" gap: a base image that was clean six months ago has almost certainly accumulated new CVEs in its OS packages since, and if the derived application image hasn't been rebuilt against a refreshed base, those patches never land. Preferring minimal base images (Alpine, distroless, or scratch where feasible) shrinks this surface directly, and rebuilding on a schedule — not just when application code changes — is the other half of actually keeping it managed.
What about secrets ending up inside image layers?
Secrets baked into image layers are a recurring, avoidable mistake: an ENV instruction, a COPY of a .env file, or a build argument containing an API key or credential gets committed into a layer, and even if a later layer deletes the file, the secret remains recoverable from the earlier layer in the image history — Docker layers are additive, not destructive, so rm in a later RUN step doesn't remove data from the layer that added it. Multi-stage builds with build-time secrets passed via --secret (rather than ARG or ENV) avoid this entirely, since Docker's secret mount mechanism never persists the value into a layer. Any registry a compromised or overly permissive account can pull from turns a leaked layer secret into an immediate credential exposure, which is why this concern sits alongside daemon exposure as one of the highest-severity items on any real docker security checklist.
How Safeguard Helps
Safeguard scans container images layer by layer for known CVEs in base image packages and flags images that haven't been rebuilt recently enough to pick up upstream patches, closing the "scanned once, never again" gap that causes most base-image drift. It also detects common misconfigurations — root user, missing USER directives, and secret-like patterns embedded in layers — as part of the same scan that covers application dependencies. See the SCA product page for how image and dependency scanning work together to secure containers end to end.
FAQ
Is Docker itself insecure by default?
Not insecure, but permissive by default — root containers, no read-only filesystem enforcement, and no automatic image rebuilding are all defaults that favor ease of use over security, and each needs to be explicitly hardened rather than assumed.
What's the single highest-priority item on a docker security checklist?
Removing root as the default container user closes off the largest class of container-escape-to-host-compromise incidents, followed closely by never mounting the Docker socket into an untrusted or internet-facing container.
Do rootless Docker and Podman actually solve the root problem?
They meaningfully reduce it — rootless mode maps container root to an unprivileged host user via user namespaces — but they don't eliminate every kernel-sharing risk, since containers still share the host kernel regardless of the user namespace mapping in place.
How often should container images actually be rebuilt for security reasons?
On a fixed schedule (weekly is common) independent of application code changes, specifically to pick up upstream OS package security patches in the base image, plus immediately whenever a scanner flags a new critical CVE in a currently deployed image.