Docker Network & Supply Chain Checklist: 5 Checks (2026)

Docker's default networking behaviour punches holes in your host firewall without telling you. A container publishing a port on 0.0.0.0 bypasses UFW entirely, because Docker writes its own iptables rules and they are evaluated before your DENY rules. This page documents the 5 checks in the CtrlOps Network and Supply Chain audit, in the order the audit runs them.

The audit covers two surfaces that share a theme: what your containers expose to the network, and what you actually know about the code inside them. Every threshold below is transcribed from the audit script itself, not from general advice.

Key takeaways

Five checks, three HIGH, and the first one is the finding that surprises experienced administrators most often.

• Three are rated HIGH: published ports, secrets in environment variables and pending engine updates. Two are MEDIUM.
• Four need root, or docker group membership. The engine update check reads package metadata, which any account can do.
• Docker bypasses UFW by design. Check 1 is not looking for a bug, it is looking for the documented behaviour that surprises people: your firewall rules and Docker's iptables rules are not the same rule set.
• Only check 4 can fail on Debian and Ubuntu. Separating security updates from ordinary ones is an apt capability, so on RHEL family, SUSE and Alpine every pending container-stack update reports as a warning regardless of what it fixes.
• The whole audit takes about 12 seconds when CtrlOps runs it over your existing SSH connection.

Check 1: Are containers publishing ports on all interfaces?

When you run docker run -p 8080:80, Docker binds port 8080 on 0.0.0.0, which includes your public interface. It enforces that with iptables rules inserted ahead of the chains UFW manages, so the host firewall can show DENY for that port while the container behind it answers the internet.

The audit reads NetworkSettings.Ports for every running container and flags any host binding on 0.0.0.0 or ::, naming the container and the binding it found.

How to check manually

docker ps --format '{{.Names}} {{.Ports}}' | grep '0.0.0.0:'

This is a HIGH severity check that warns, and the reason is that publishing on all interfaces is correct for some containers: a reverse proxy is supposed to answer the world. The audit cannot know which container is your front door, so it names every one and leaves the judgement with you.

How to fix it

# Binds to every interface, including the public one
docker run -p 8080:80 nginx

# Binds to localhost only
docker run -p 127.0.0.1:8080:80 nginx

services:
  app:
    ports:
      - "127.0.0.1:8080:80"

Put anything that genuinely needs to be public behind a reverse proxy that terminates TLS, and bind the application containers to localhost. For a host-wide fix that makes Docker respect UFW:

sudo wget -O /usr/local/bin/ufw-docker https://github.com/chaifeng/ufw-docker/raw/master/ufw-docker
sudo chmod +x /usr/local/bin/ufw-docker
sudo ufw-docker install
sudo systemctl restart docker

Check 2: Are containers sharing the default bridge with inter-container communication?

The default bridge network connects every container attached to it with inter-container communication enabled. Any container on it can reach any other by IP, with no access control, no segmentation and no logging. One compromised container is then one hop from all the others.

The audit lists which running containers are attached to the bridge network, then reads com.docker.network.bridge.enable_icc on that network. Containers on the default bridge only warn when ICC is actually on.

How to check manually

docker network inspect bridge --format '{{range .Containers}}{{.Name}} {{end}}'
docker network inspect bridge --format '{{index .Options "com.docker.network.bridge.enable_icc"}}'

Anything started by Docker Compose gets a user-defined network automatically, so this check tends to fire on hosts where containers were started by hand with docker run and never moved.

How to fix it

Give each group of containers a network scoped to what it actually needs to talk to:

services:
  web:
    networks: [frontend]
  api:
    networks: [frontend, backend]
  db:
    networks: [backend]

networks:
  frontend:
  backend:

web reaches api, api reaches db, and web cannot reach db at all. To disable ICC on the default bridge globally, add this to /etc/docker/daemon.json and restart the daemon:

{
  "icc": false
}

Check 3: Are secrets passed as container environment variables?

Environment variables are the most common way to pass secrets to containers and the least protected. docker inspect prints every one in plain text to anyone with Docker access, which includes every member of the docker group. Child processes inherit them, some runtimes log them on crash, and they stay in the container metadata long after the process has exited.

The audit reads Config.Env for every running container and matches names against PASSWORD, PASSWD, SECRET, API_KEY, ACCESS_KEY, TOKEN and PRIVATE_KEY, including prefixed forms. It ignores variables whose value is empty or an obvious placeholder such as changeme or example, and it reports variable names only, never values.

How to check manually

docker ps -q | while read c; do
  name=$(docker inspect --format '{{.Name}}' "$c" | tr -d '/')
  keys=$(docker inspect --format '{{range .Config.Env}}{{println .}}{{end}}' "$c" \
    | grep -iE '^(.*_)?(PASSWORD|PASSWD|SECRET|API_?KEY|ACCESS_?KEY|TOKEN|PRIVATE_?KEY)=' \
    | sed 's/=.*//' | head -3 | tr '\n' ',')
  [ -n "$keys" ] && echo "$name: $keys"
done

Both directions of error are worth knowing. A variable called DB_CONN holding a full connection string will not match, and a variable called TOKEN_PATH holding a harmless path will. Read the named variables rather than the count.

How to fix it

# Compose with file-based secrets
services:
  app:
    secrets:
      - db_password
    environment:
      DB_PASSWORD_FILE: /run/secrets/db_password

secrets:
  db_password:
    file: ./db_password.txt

Then read the file rather than the variable in the application:

import os
path = os.environ.get('DB_PASSWORD_FILE', '')
if path and os.path.exists(path):
    with open(path) as f:
        db_password = f.read().strip()

The file path in the environment is the part that is safe to expose. The credential itself stays on a mounted file that only the container can read.

Check 4: Are Docker engine updates pending?

Docker, containerd and runc share the host kernel with every container. A vulnerability in runc, such as the Leaky Vessels family in CVE-2024-21626, gives an attacker inside a container full root on the host. These are not theoretical: they ship with public exploits and get used.

The audit queries whichever package manager the host has, apt, dnf, yum, zypper or apk, for pending updates to docker, containerd and runc.

How to check manually

# Debian and Ubuntu
apt-get -s upgrade 2>/dev/null | grep '^Inst ' | grep -iE 'docker|containerd|runc'

# RHEL family
dnf check-update 2>/dev/null | grep -iE 'docker|containerd|runc'

# Alpine
apk version -l '<' 2>/dev/null | grep -iE 'docker|containerd|runc'

Two caveats carry real weight. A warning on a Rocky or Alma host is not evidence that nothing security-related is waiting: run dnf updateinfo list security to find out. And the check never refreshes package metadata, because every check in this catalog is strictly read-only and apt update writes to disk. Refresh it yourself before trusting a pass.

How to fix it

# Debian and Ubuntu
sudo apt-get update && sudo apt-get upgrade docker-ce containerd.io runc -y

# RHEL family
sudo dnf update docker-ce containerd.io runc -y

sudo systemctl restart docker

Running containers keep using the old runtime until they are recreated, so finish the job:

docker compose down && docker compose up -d

Check 5: Are running containers using unpinned images?

A running container on latest or on an untagged image means you do not know exactly what is in production, and the next pull or restart can change it silently. Combine that with no scanner anywhere on the host and you have unknown code running with no way to find out whether it is vulnerable.

The audit counts running containers whose image ends in :latest or carries no tag or digest at all, then looks for trivy, grype, docker scout, clair or snyk on the host. The two signals are graded together, which is why this check has three distinct warnings.

How to check manually

docker ps --format '{{.Image}}' | grep -cE '(:latest$|^[^:@]+$)'

for tool in trivy grype snyk; do command -v "$tool" >/dev/null && echo "$tool available"; done
docker scout version >/dev/null 2>&1 && echo "docker scout available"

This check reads what is running, which is what distinguishes it from the floating tag check in the Image Vulnerabilities audit. That one reads images on disk, including ones nothing has started for months. This one reads production.

How to fix it

# Resolve the digest for what you are running now, then pin to it
docker pull nginx:1.27-alpine
docker inspect --format '{{index .RepoDigests 0}}' nginx:1.27-alpine

# Install a scanner
curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin

services:
  web:
    image: nginx:1.27.1-alpine

What this audit does not cover

This audit reads container networking, secret handling and image hygiene on running containers. It does not check:

• Container-level hardening. Privileged mode, capabilities, the runtime user and read-only filesystems are the Container Hardening audit.
• Daemon-level controls. Socket exposure, rootless mode and log rotation are the Daemon and Socket audit.
• Image contents. CVE scanning, embedded secrets and EOL base images are the Image Vulnerabilities audit.
• Runtime resource limits. Seccomp, AppArmor and memory, CPU and PID caps are the Runtime and Resources audit.
• Host firewall configuration. UFW rules, iptables chains and cloud security groups are the Firewall and Network audit.

The manual audit problem at scale

These five checks move between container inspection, network inspection, package manager queries and a PATH search. On one host that is about four minutes. On ten servers with different firewall setups and package managers it is forty minutes of context switching, and the most important finding, a port bound to 0.0.0.0 that your firewall is not protecting, is the one easiest to scroll past.

How CtrlOps runs all 5 checks in one click

Instead of running these commands on every server by hand, CtrlOps runs the whole Network and Supply Chain audit over the SSH connection you already have open. Nothing is installed on the server: no agent, no daemon, no package, no new credentials. The checks are read-only POSIX shell that executes, streams its results back, and leaves nothing behind.

Watch it run

The recording below walks through the SSH and Access audit rather than this one, but the flow is identical for every audit in the catalog: pick it, watch the checks stream in, read the score, send the failures to the AI Terminal.

Step 1: Open the Audit tab

Connect to your server in CtrlOps and open the Audit tab in the left sidebar.

Step 2: Select Network & Supply Chain

Choose it from the Docker category. All 5 checks are listed with their descriptions, severity levels and the estimated run time, about 12 seconds in total.

Step 3: Run it

The audit runs over your existing SSH session. Results stream in as they complete, so you watch each check pass, warn or fail rather than waiting on a final report.

Step 4: Read the report

You get a summary containing:

• A hardening score out of 100
• A severity breakdown: how many HIGH, MEDIUM and LOW findings
• Pass, warning, failed and skipped counts
• A findings table naming the container and port combination for every exposed binding

Step 5: Fix what failed

Select the failed findings and send them to the AI Terminal. Each proposed fix command appears with an explanation of what it changes. Nothing runs until you review and approve it, which matters here: changing a port binding means recreating the container, and updating runc means restarting the daemon.

Step 6: Re-run and compare

Run the same audit again after applying the fixes and watch the score move. Check 4 is the one that reappears on its own, because new container-stack updates land regardless of what you change on the host.

Conclusion

The theme of this audit is the gap between what you believe is exposed and what actually is. The firewall says the port is closed and the container answers anyway. The secret is "in the environment", which is another way of saying it is in docker inspect output for everyone in the docker group. The image is "the current one", which is only true until the next pull.

Three of these five are HIGH severity and each has a fix that takes minutes. The CtrlOps Security Audit runs the set in about 12 seconds per server and names the specific container, port and variable in every finding.

The neighbouring checklists cover the other container layers: container hardening, daemon and socket, image vulnerabilities, volume permissions and runtime and resources.

Frequently asked questions