highContainers and deployment files

Container Given Host-Level Access

A container is allowed to control the host it runs on.

Why it matters

These settings are meant for monitoring agents and build runners, not for web apps. With the Docker socket or privileged mode, a container can start other containers with the host's disks mounted. Web services do not need any of it, and dropping the setting rarely changes how the app runs.

What it looks like

This is the shape of code that triggers the rule. AI tools produce it because it works, and nothing tells them it is unsafe.

privileged web service
services:
  api:
    image: myapp:1.0
    privileged: true

The smallest fix

minimal patch
services:
  api:
    image: myapp:1.0
    # removed: privileged: true
    # removed: - /var/run/docker.sock:/var/run/docker.sock
    networks: [internal]

The better fix

If you have a few more minutes, this is the approach that holds up as the app grows.

safe alternative
# If a service genuinely needs a host capability, add only that
# capability (cap_add: [NET_BIND_SERVICE]) and keep cap_drop: [ALL]. For
# anything that must talk to Docker, use a socket proxy such as
# tecnativa/docker-socket-proxy with only the endpoints it needs.

Let your AI tool fix it

When the scanner finds this in your project, it fills in the file and line for you. This is the prompt it gives you to paste into Claude Code, Cursor or whatever you use.

In [the file] at line [the line number] a container is given host-level access: [the flagged code]. Remove the setting. If a specific capability is truly required, add just that one with cap_add and set cap_drop: [ALL]. If the service needs the Docker API, route it through a read-only socket proxy.

How to check the fix worked

1. Start the stack with the setting removed and confirm the service
   still works.
2. Run `docker inspect <container> --format '{{.HostConfig.Privileged}}'`
   and confirm false.

Further reading