Docker security is the practice of protecting containerized applications across four layers: the base image, the container runtime, the orchestration layer (like Kubernetes or Docker Swarm), and the host operating system. It matters because a single misconfigured Dockerfile or an outdated base image can turn a routine deployment into a full breach — Docker Hub alone hosts more than 15 million public images, and a 2023 Sysdig study found that 87% of container images contain at least one critical or high-severity vulnerability. The 2019 Docker Hub breach, which exposed roughly 190,000 accounts, and the 2021 Codecov supply chain attack that traced back to a leaked GCP credential inside a Docker image, are both reminders that container security isn't optional. Teams that ship containers need controls at build time (image scanning, SBOM generation), at deploy time (admission control, signed images), and at runtime (behavioral monitoring, least-privilege enforcement) — not just one of the three. Most docker security issues in production trace back to a gap in one of those three stages, which is why docker security scanning has to run continuously — at build, in the registry, and at runtime — rather than as a single point-in-time check.
What does Docker security actually protect against?
Docker security protects against four main attack classes: vulnerable dependencies baked into images, container escapes that let an attacker reach the host, misconfigured runtime privileges, and supply chain compromise of the images themselves. CVE-2019-5736, a runc container escape affecting Docker versions before 18.09.2, let a malicious container overwrite the host's runc binary and gain root access on the host — it affected an estimated hundreds of thousands of production clusters before patches shipped in February 2019. CVE-2024-21626, disclosed in January 2024, was another runc flaw that allowed container breakout via a leaked file descriptor, scoring 8.6 on CVSS and prompting Docker, Kubernetes, and containerd maintainers to issue coordinated patches within days. Separately, in 2023 security researchers found over 1,600 exposed Docker Engine API instances on Shodan with no authentication, letting anyone pull, run, or exfiltrate data from any container on those hosts. Each of these is a different layer failing — kernel isolation, image hygiene, and network exposure — which is why Docker security has to be treated as a stack, not a single tool. That stack is also why choosing a docker security company or docker security tool matters: security for docker containers depends on covering all four attack classes, and outlets covering docker security news today consistently trace fresh incidents back to a gap in one of them.
How do you scan a Docker image for vulnerabilities?
You scan a Docker image by generating a Software Bill of Materials (SBOM) from its layers and matching every package version against vulnerability databases like the NVD, OSV, and GitHub Advisory Database. Open-source scanners such as Trivy, Grype, and Docker Scout do this by unpacking image layers, identifying OS packages (apt, apk, yum) and language dependencies (npm, pip, Maven, Go modules), then cross-referencing versions against CVE feeds — a scan of a typical node:18 image can surface 40-80 findings depending on how recently the base was rebuilt. The catch is volume without context: a 2023 analysis of container scan results found that fewer than 10% of flagged vulnerabilities in a typical image are actually reachable by the application's code paths at runtime, meaning most teams are triaging noise. Effective scanning has to happen at three points — in CI on every build, in the registry on a recurring schedule (because new CVEs get disclosed against already-pushed images), and pre-deploy via admission controllers that block images failing policy thresholds. Whatever you call it — a docker image security scan, a docker security scan, or just "scanning your containers" — that's what's actually happening under the hood, and skipping any one of the three trigger points leaves a real gap.
What is the difference between image security and runtime security?
Image security addresses vulnerabilities baked into a container before it ever runs, while runtime security monitors and constrains what a container actually does once it's live. Image security work includes pinning base images to digests instead of mutable tags (node:18 can change under you; node:18@sha256:abc... cannot), stripping build tools and shells from production images with multi-stage builds, and running as a non-root USER — Docker's own hardening guide has recommended non-root containers since at least 2017, yet a 2022 Unit 42 report found 96% of scanned container images still ran as root by default. Runtime security covers seccomp profiles, AppArmor/SELinux policies, read-only root filesystems, and dropping Linux capabilities like CAP_SYS_ADMIN that most containers never need. The two layers catch different failure modes: image scanning would never have caught the 2022 exploitation of an overly permissive --privileged flag in a misconfigured CI runner, because the image itself was clean — the exposure was entirely a runtime configuration choice.
Which Docker misconfigurations cause the most breaches?
The most common breach-causing misconfigurations are running containers as root, exposing the Docker daemon socket, using the --privileged flag unnecessarily, and mounting the host filesystem into containers. Mounting /var/run/docker.sock into a container — a pattern still found in a large share of public CI/CD templates — effectively hands that container root access to the entire host, since anyone with socket access can launch new privileged containers at will; this exact technique has been documented in multiple cryptomining campaigns, including the 2021 "Doki" backdoor campaign that specifically scanned for exposed Docker APIs on AWS, Azure, and GCP hosts. The Center for Internet Security's Docker Benchmark (CIS Docker Benchmark v1.6, published 2023) lists over 100 discrete configuration checks, and independent audits routinely find default Docker installs failing 20-30 of them out of the box — things like unrestricted inter-container communication, missing resource limits (no --memory or --cpus caps, which enables noisy-neighbor DoS), and unencrypted registry traffic. None of these require a zero-day; they're all documented, checkable settings that scanners like Docker Bench for Security can flag in minutes. Left unpatched, these docker security issues are exactly the kind of gap that continuous docker security scanning — not a one-off audit — is designed to catch across every item on that list. These same gaps show up behind most of the docker security news today — headlines about an exposed daemon or a crypto-mining container breach almost always trace back to one of the items on this list, not a novel zero-day.
How does Docker security fit into a broader supply chain security strategy?
Docker security is one link in a chain that starts with source code and ends with a running workload, and it only holds if every link — SCA, SBOM, image signing, and runtime enforcement — is connected end to end. The 2021 Codecov incident is the clearest example: attackers modified a Docker image creation script to exfiltrate CI environment variables, and because no SBOM diffing or image provenance check was in place, the tampering went undetected for roughly two months and touched thousands of downstream customers. Sigstore's Cosign, which reached general availability in 2021 and is now used to sign a large share of images on Docker Hub's official image program, exists specifically to close this gap by cryptographically attesting that the image running in production is the one that came out of a trusted build. Standards bodies have caught up too: the U.S. Executive Order 14028 (May 2021) and NIST SP 800-218 both now expect SBOMs for any software — including containers — sold into the federal supply chain. Treating Docker security as a standalone checklist item misses the point; it needs to be wired into the same pipeline that tracks source dependencies and cloud runtime posture.
How Safeguard Helps
Safeguard generates and ingests SBOMs directly from your Docker images at build time, then runs reachability analysis to determine which of the dozens of CVEs a typical scan surfaces are actually exercised by your application's code paths — cutting through the noise the CIS Benchmark and generic scanners leave behind. Griffin AI, Safeguard's agent, correlates those reachable findings against your running container inventory and prioritizes fixes by real exploitability rather than raw CVSS score. When a fix is available, Safeguard opens an auto-fix pull request that bumps the vulnerable base image or dependency and re-validates the build, so remediation doesn't sit in a backlog. The result is fewer false positives, faster patch cycles, and an audit trail that maps every container in production back to the SBOM and commit that produced it. Running a single docker image security scan at build time isn't enough on its own — pairing it with a scheduled docker security scan against the registry catches CVEs disclosed after an image was already pushed. Whether you're evaluating Safeguard as a docker security company or already run a separate docker security tool for image scanning, the same principle applies: security for docker containers only holds if scanning stays connected to what's actually running in production, not just what shipped in the image.