Docker published the port. Your firewall never saw it.

You probably got here from my own free checker. It was right.

So this page opens where that report ends, rather than reading your Compose file back to you.

The Docker Compose production checker on this site is free and needs no account and no email address. It finds all seven of the faults on this page, names the line, gives you the line number, and lists what passed as well as what failed. None of that is discovered here. It is already yours.

What the free checker already gives you

The verdict, the offending line, its line number, the evidence behind it and the checks that passed. Nothing on this page unlocks any of it, and nothing here is held back to make you pay for it.

And the obvious next thing is free too

Paste that file into a language model and ask for a hardened version. You will get one, in seconds, and most of it will be correct. I am not going to sell you a document you can generate while you read this sentence.

So the honest part first. If your file came back clean, or the only findings were the easy ones and you can already answer the question below, you do not need this page. Fix the lines the checker named and get on with your week.

The question is the one no file answers: that published port — does it actually answer, right now, to somebody who is not you?

Every free tool here reads a file. The fault is not in the file.

A Compose file records what you asked Docker to publish. Whether that port answers depends on the bind address, the host firewall, the packet filtering order and anything in front of the machine — and none of those live in the file.

This is where most people are confident, and it is where Docker itself says not to be. If you run ufw, the firewall you configured is not doing what you think for published container ports. That is not my claim. It is on Docker’s own packet filtering and firewalls page:

• docs.docker.com — Docker and ufw Docker and ufw use firewall rules in ways that make them incompatible with each other.
• docs.docker.com — Docker and ufw When you publish a container’s ports using Docker, traffic to and from that container gets diverted before it goes through the ufw firewall settings.
• docs.docker.com — Docker and ufw Packets are routed before the firewall rules can be applied, effectively ignoring your firewall configuration.

Read that narrowly, because it is narrow. It is about ufw, and it is about the order packets are filtered in. Docker is not insecure by default, and I am not going to tell you it is. On a firewalld host the same page describes something else entirely — Docker creates a zone called docker with target ACCEPT and a forwarding policy to go with it — and it claims no bypass there. So firewalld gets checked rather than assumed, and if you sit behind a cloud security group the whole question may already be answered. Finding that out is a short engagement and a good outcome.

If you have had a server hardened — by me on the VPS hardening page or by anyone else — this is exactly the gap that survives it. That work configures the firewall. This work finds where Docker went around it.

The second half: a credential that has already left

The other thing a file cannot tell you is where a leaked credential went. If a password was passed to a build as an ARG, editing the Compose file changes nothing, because the value is no longer only in the file. Docker says so in the Dockerfile reference:

• docs.docker.com — Dockerfile reference, ARG It isn’t recommended to use build arguments for passing secrets such as user credentials, API tokens, etc. Build arguments are visible in the docker history command and in max mode provenance attestations

Be precise about the mechanism, because the same page is precise about it. An ARG is not embedded in the image the way an ENV is — Docker says that too. It is in the image’s history, and the history travels with the image. Every registry copy, every pull, every build cache. So the question is never “is it still in the file”. It is: who has pulled that image since, and what does the credential still open?

What the free competition does, and does not, cover

Use all of these. They are good, they cost nothing, and none of them connects to your ports from outside.

The Compose production checker — mine, free

All seven faults, from a paste, with the line and the line number. Reads the file.

KICS — free, open source

Explicitly supports Compose — KICS supports scanning DockerCompose files with .yaml extension — as one of 22 platforms. Reads the file.

Trivy — free, open source

Excellent, and worth running. Its supported configuration list is Kubernetes, Docker, Terraform, Terraform Plan, CloudFormation, Azure ARM Template, Helm, YAML and JSON — no Docker Compose entry. It will still read the file as generic YAML; what it does not have is Compose-aware checks. Reads the file.

Docker Bench for Security — Docker’s own, Apache-2.0

Audits the host, the daemon, the running containers and the images against CIS Docker Benchmark v1.6.0. It reads no Compose file at all, and it runs on the host rather than from outside it.

Docker Scout — free tier, then paid

Image vulnerabilities and SBOMs, which this page does not do and does not try to. Docker Personal includes it for one Scout-enabled repository; the paid plans are billed per user per month. Reads the image.

Every one of them reads a file, or reads an image. None of them opens a connection to your published port from an address that is not yours — and until somebody does, whether that port answers is a belief rather than a fact.

Two tables. Both of them are records of something that happened.

This is what the review produces. Every row below is an example of the shape rather than anybody’s real stack — but the columns are the real columns, and the fifth one cannot be filled in by reading anything.

Published ports, tested from outside

Three rows there say the same thing: the firewall says denied, and the port answered anyway. That is the product. It is also the row that does not exist until somebody connects from an address that is not yours, which is why no file-reading tool returns it and why the report is worth what it costs.

Note the other four, because they matter as much. One port answered and is meant to. Two were genuinely closed — one bound to 127.0.0.1, one covered by a cloud security group that was doing its job. And one was not tested at all, because that host was not named in the written permission. The report says so in the table rather than leaving you to assume it was covered.

Credentials, and how far each one has already travelled

The last column is the state after the repair, which is why one row says not yet. A key compiled into a released mobile app cannot be rotated on the server alone, and a table that pretended otherwise would be selling you a tidier morning than you are going to get.

This is not a penetration test, and I want that in writing.

One connection per port you named. Enough to record that something answered and what it said it was — and then it stops.

Seven things go wrong, and the first three are the same problem.

Host access first, because a container that reaches the host makes everything below it academic. The finding ids are the ones the free checker prints, so you can match a row on your report to a paragraph here.

compose.docker_socket A container can reach the host’s Docker daemon

The Docker socket mounted into a container is root on the host today, by design, with no escape required and no permission model in front of it. Anything that can talk to it can start a second container with the whole filesystem mounted. It is separated from everything below because it is not a weakened boundary — it is no boundary at all.

compose.privileged, compose.network_host, compose.pid_host, compose.ipc_host, compose.cap_dangerous, compose.security_unconfined, compose.userns_host A container shares the host’s isolation boundaries

Different settings, one outcome: the walls come down one at a time. privileged: true removes all of them at once. pid: host makes every process on the machine readable from inside, environment variables included. network_mode: host matters twice over here, because a container on the host network opens ports that never appear under ports: at all — so the file stops describing what is reachable, which is this page’s whole argument in one line. userns_mode: host gives back the remapping that makes container root harmless outside.

compose.host_path_mounted, compose.device_dangerous A container has a path or a device into the host

A bind mount of a sensitive host directory reaches the host without needing privileged or a capability to do it. Writable, it ends where the socket ends, by a slower route. Read-only is better and is not safe, because those directories carry service credentials and every account on the machine. A raw disk device is the host filesystem with the host’s permissions taken off.

compose.db_port_published, compose.no_internal_network A backend service is published where it should not be

A database or a cache with a ports: entry is reachable from outside the machine, not just from the application in front of it. This is the fault the drill exists for, because the file says the port is published and stops there. Whether it answers depends on the firewall, the bind address, the cloud security group and the packet filtering order — and that combination is not in any file.

compose.admin_ui_published An admin interface is published to every interface

Adminer, phpMyAdmin, a queue console, a metrics dashboard. They get published to 0.0.0.0 during setup and stay there, and unlike a database they are designed to be used by a human with a browser. Anyone who finds one needs no tooling at all.

compose.secret_in_env, compose.secret_in_command Credentials readable in the file, or in the process list

A literal password in environment: is readable by everyone with the repository, which is more people than the team. On the command: line it is worse: it is in the process list, so any container sharing the host process namespace can read it without touching the file at all.

compose.secret_in_build_arg A credential that has already travelled

This one is separated from the row above because the blast radius differs in kind. A credential passed as a build ARG is visible in docker history, so every copy of that image carries it — in the registry, on every machine that pulled it, in the build cache. Editing the Compose file does nothing about any of them. Only rotation does, and rotation is work rather than advice.

Faults four and five are the ones the drill settles. The rest are read off the file, ranked by what is actually reachable rather than by severity in the abstract — because a privileged container on a machine nothing can reach is a worse configuration and a smaller emergency than a database that answered on the first try.

Four ways in

Everyone starts with the drill, because until the ports have been tested nobody knows how much of the file actually matters — including me.

Deploy Re-test is not uptime monitoring, and it is not alerting. Uptime monitoring watches that something you want up is up, and it is free in places including the uptime trial on this site. If you want dashboards and somebody watching the whole stack, that is hosted monitoring and it is a different service. This watches the opposite thing: that a port which is supposed to be closed has not quietly become reachable again.

There are no figures on this page, and that is deliberate rather than coy. A fixed number would be too high for four services publishing one port and too low for a stack with a socket mount holding up three other things. Tell me the shape of it in the form — how many services, what is published, and whether anything mounts the Docker socket — and you get a figure back before anything is committed to.

What you have to supply

The first item is not negotiable and nothing starts without it.

What this cannot promise

Every one of these is on the page rather than in an email after you have paid.

Four things this is not

Named up front, so none of them turns into silent scope halfway through.

How payment works

Plainly, so nothing about it is a surprise later. There is no account to create, no portal to log into and no card stored anywhere.

1. You apply through the form

   No payment at this point, and no commitment. Tell me how many services, what is published, and what prompted this.

2. I review it and confirm the scope

   If it is not worth doing, I say so here and it costs you nothing. If it is, you get the scope, the host and port list and the window in writing before any invoice exists.

3. An invoice arrives, payable within 48 hours

   It carries an invoice number and a due date. Unpaid past 48 hours, the application lapses and the slot is released to somebody else.

4. Work begins once payment is received, and once the permission is signed

   Not before, and the written permission is the second half of that sentence rather than a formality. For one-off work there is nothing to suspend after delivery, so payment comes first — that is the standard arrangement and it runs both ways.

5. Deploy Re-test, if you take it, is monthly in advance

   Non-payment simply stops the work. Nothing is billed silently in the background and you can stop whenever you like.

If you are still building

Everything above assumes a stack that grew over years. Before launch the same work is a fraction of it, and here the gap is unusually large.

Mention that you are pre-launch in the form and I will quote it as its own piece of work. It is cheaper, and it is the version of this engagement I would rather sell.

Questions