Docker audit fixes

Network & Supply Chain: fixing all 5 checks

The network and supply chain audit reads published ports, network membership, container environment and pending engine updates: who can reach a container, and how far you can trust what it runs.

Four of the five need a reachable daemon and three of those also need at least one running container, so they skip together on an idle host. Docker Engine Updates is the exception, because it queries apt, dnf, yum, zypper or apk and skips only when Docker is absent or no supported package manager is found.

5
checks in this audit
3
rated high severity
4
need root or sudo
~12s
automated run time

Transcribed from the docker-security-network-supply-chain audit script.

Every check

Find your finding

Listed in the order the audit runs them. Take the check name from the third field of the result line and open its page.

  • Published Container Ports

    Soon

    Check for containers publishing ports on all interfaces, which bypasses UFW host firewall rules

    HighNeeds root3 results

  • Inter-Container Connectivity

    Soon

    Check whether containers share the default bridge network with inter-container communication enabled

    MediumNeeds root3 results

  • Secrets In Env

    Soon

    Check for secret-like values (passwords, keys, tokens) passed as container environment variables

    HighNeeds root3 results

  • Docker Engine Updates

    Soon

    Check for pending Docker engine, containerd or runc package updates across supported package managers

    HighNo root4 results

  • Unpinned Running Images

    Soon

    Check whether running containers use pinned image tags and whether a vulnerability scanner is installed

    MediumNeeds root3 results
Shared script behaviour

How the Network & Supply Chain audit reads your server

Every check in this audit runs after the same preamble, and several of its results only make sense once you know what that preamble could and could not see.

Docker detection: DOCK=direct if docker ps works as the audit user (docker group), DOCK=root if it works through sudo; the dk helper wraps docker accordingly. IDS is the list of running container IDs and NRUN their count; dk inspect --format is used with Go templates. Podman is recognised but not audited.

Why checks skip

A SKIP is never a pass

A skipped check verified nothing at all. The most common cause is privilege: 4 of the 5 checks in this audit need root for a complete result. Before every run, each script works out which of four privilege modes it is in.

The four privilege modes an audit script can run in, and what each one means for checks that need root
ModeHow it is reachedWhat it means for your results
rootThe audit runs as UID 0.Every privileged branch runs directly. No check skips for lack of permission.
nopasssudo -n true succeeds, so the account has passwordless sudo.Privileged commands run through sudo -n.
passA sudo password was supplied in the CtrlOps audit settings and accepted.Privileged commands run through sudo -S.
noneNone of the above worked.CAN_ROOT=0. Every privileged branch returns SKIP with a "Need root" message rather than guessing.

If many checks skip with a “need root” message, run the audit as root, grant the audit account sudo (with or without NOPASSWD), or supply the sudo password in the CtrlOps audit settings. For Docker checks, membership of the docker group is an alternative to sudo: run usermod -aG docker <user> and log in again.

Keep going

Related audits

FAQ

Network & Supply Chain questions

Not for UFW. It reads each container's HostIp binding and flags 0.0.0.0 or ::, and Docker inserts its own iptables rules ahead of the UFW chain, so a published port stays reachable from the internet despite a host DENY. That is the finding, not a false positive. Two things it cannot see: a cloud security group that blocks the port anyway, and rootless Docker, where publishing goes through RootlessKit and the host firewall usually does apply. A reverse proxy publishing 80 and 443 on all interfaces is correct design and still warns.
Only as far as the package lists on the host go. The check greps pending updates for docker, containerd and runc, so stale apt lists produce a false pass and you should run apt update first. It also never sees a snap-installed Docker or a static binary, and packages from download.docker.com land in the WARN branch rather than the FAIL branch even when they fix a CVE, because that repository has no security pocket for the check to match on.
Usually the opposite. A user-defined network gives DNS resolution by container name, which the default bridge does not, so docker network create backend and starting the containers with --network backend is normally a drop-in. What does break is anything that reached a container by its bridge IP or through the legacy --link flag, so update those references first. Setting icc to false in daemon.json also clears the finding, but it breaks legitimate default-bridge traffic and is the fallback rather than the fix.
Audit your fleet

Run all 5 Network & Supply Chain checks, in one click

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

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