Container security

Docker Security Audit Fixes

These are the fixes for a Docker security audit: who can reach the daemon, how much of the host each container can touch, what is inside the images you run, and what stops one container taking down the rest.

39
checks documented
6
audits in this category
31
need root or sudo
13
rated high severity

What these fixes cover

  • Daemon TCP exposure, docker group membership, rootless mode and user namespace remapping
  • Privileged containers, capabilities, no-new-privileges, container user and read-only roots
  • Image vulnerabilities, floating tags, baked-in secrets, EOL base images and SBOMs
  • Host path mounts, volume permissions and memory, CPU and PID limits

What they do not

  • Kubernetes. These checks read a Docker daemon on the host; a cluster needs a different tool.
  • Podman. It is recognised so the audit can tell you Docker is absent, but it is not itself audited.
  • Stopped containers, for most checks. Only the volume checks look beyond docker ps.

How much of this is serious?

Severity of all 39 Docker checks, as the scripts rate them.

  • 13High severity33%
  • 15Medium severity38%
  • 11Low severity28%
By audit

6 audits, 39 checks

Grouped by the 6 audits they belong to. Daemon and socket comes first, because access to the Docker socket is root on the host by another name.

Fix these first

The highest-severity findings in Docker

Ordered by the impact class the audit script assigns, then by the order the audit runs them.

Keep going

The other three platforms

Most hosts run more than one of these. The split shows how much of each platform the audit rates as high severity.

FAQ

Docker fix questions

Either Docker is not installed, or the daemon could not be reached by the account running the audit. Unlike the other categories, sudo is not the only route here: membership of the docker group also works. Run usermod -aG docker <user> and log in again, or run the audit as root.
Not always, and the pages say which. Most container checks read running containers only (docker ps), so a stopped container is not evaluated. Several image checks examine only the first 5 or 10 local images, which means a host with many images is sampled rather than fully scanned.
Yes. Any process that can write to /var/run/docker.sock can start a container that mounts the host root filesystem and gain root on the host, in about three commands. It is the single highest-impact finding in this category, and the same reasoning applies to membership of the docker group and to an unauthenticated daemon on port 2375.
Yes. Where a fix is a docker run flag, the page gives the Compose equivalent alongside it, because almost nobody applies these one container at a time in production.
Audit your fleet

Run all 39 Docker checks, in one click

CtrlOps runs these audits over your existing SSH connection - no agents, no scripts to manage. $7/user/month after a 1 month free trial - no credit card required.

Windows

✓ Start instantly·✓ No credit card·✓ No sneaky autorenewals