Docker integration
DevOps & CI/CD
Containers make it trivially easy to publish a port, and that convenience is exactly how unintended external exposure happens — a stray `-p 6379:6379`, a debug endpoint left mapped, a service bound to 0.0.0.0 instead of localhost. The FortWatch Docker integration (currently in development) ties your container workflow to continuous external scanning, so the public-facing surface a deployed container actually exposes gets checked from the outside before it becomes someone else's entry point. It is the bridge between "the container built and shipped" and "we know what the internet can now reach."
Exposed Redis on 203.0.113.10:6379
Unauthenticated database reachable from the internet.
View finding & step-by-step fix →Docker + FortWatch
FortWatch is an external attack surface scanner, so the integration focuses on what a running container exposes to the internet rather than parsing image layers. It plugs in at two points. First, in your pipeline: a FortWatch CLI step (run as a small container image or a Docker CLI plugin) triggers an on-demand external scan of the staging or production host/endpoint a container is being deployed to, then returns the result to the build. You set a severity threshold, and the step can fail the build — exit non-zero — when FortWatch finds a critical or high exposure, so a misconfigured port mapping or an unauthenticated database never reaches production silently. Second, for already-running containers: FortWatch can be pointed at a registry webhook (Docker Hub, GHCR, ECR, GCR) or your deploy hook so a fresh push/deploy queues a scan of the affected public asset automatically. Findings flow back through the REST API and webhooks — severity, the affected host and port, the AI triage summary, and remediation guidance — which you can wire into your existing alerting or CI annotations.
FortWatch scans
Eleven scanners watch your external attack surface around the clock — ports, certs, DNS, cloud buckets, exposed files and more.
AI triages the finding
Each issue is scored by real-world impact and packaged with the affected asset and a one-line explanation of the risk.
Delivered to Docker
The finding lands in Docker, routed by severity — so the right people see the right alert, fast.
What you'll be able to do
Everything the Docker integration will bring to your security workflow.
Pipeline exposure gate
a FortWatch scan step in your `docker build`/deploy job fails the build when a deployed container exposes a critical finding, like an unauthenticated Redis or Mongo reachable from the internet.
Catch accidental port publishing
surface containers that mapped a port to 0.0.0.0 (an exposed `-p 6379:6379`, a debug or metrics endpoint, a management port) the moment the service goes live.
Post-deploy verification
a registry or deploy webhook auto-triggers an external scan after every push, confirming what the new container version actually exposes versus the last one.
TLS and header checks on containerized web services
verify the reverse proxy / web container in front of your app ships valid certificates and HTTP security headers once deployed.
Drift detection across deploys
compare the external surface of a service before and after a container update to catch newly opened ports or regressed configurations.
Block secret and config leaks
confirm a deployed container isn't serving an exposed `.env`, `.git`, or other sensitive path before the build is allowed to promote.
What an alert looks like
Every finding arrives formatted for Docker — severity up front, the affected asset, and a one-line explanation of why it matters, with a link straight to the step-by-step fix.
- Severity-tagged and color-coded
- The exact asset and port affected
- One click to the full finding & remediation
DockerFortWatch CI · Docker deploy scan — staging\n\n✗ BUILD FAILED — 1 critical finding (threshold: high)\n\n🔴 Critical · Exposed Redis on staging.example.com:6379\nA container in this deploy published port 6379 to 0.0.0.0 — unauthenticated Redis is now reachable from the internet. Anyone can read, flush, or use it to pivot onto the host.\nLikely cause: `-p 6379:6379` in compose/run (should bind 127.0.0.1 or stay internal-only).\n\nScan: 11 checks · 1 critical · 0 high · 2 medium\n→ Full finding & fix: https://app.fortwatch.ai/findings/...
Set it up in minutes, once it lands
No agents, no infrastructure changes — just connect Docker and choose where alerts go.
When it launches, generate a FortWatch API token in Settings → Integrations and add it as a secret in your CI environment.
Add the FortWatch scan step to your pipeline — run the `fortwatch/scan` container image (or Docker CLI plugin) after your build/deploy stage, pointing it at the target host or endpoint.
Set your fail threshold (for example, fail the build on any critical or high finding) and choose whether the step blocks or just reports.
Optionally connect a registry or deploy webhook so a push to Docker Hub, GHCR, ECR, or GCR auto-triggers a scan of the affected asset.
Run a test deploy to confirm scans trigger, findings return, and the build gate behaves as expected, then turn it on for your protected branches.
Why route FortWatch into Docker?
Containers compress the distance between a config typo and a live internet exposure to a single command — and the host that runs them often has nothing between a published port and the open internet. Wiring FortWatch into your Docker workflow means every deploy is checked from the attacker's vantage point, so an accidentally exposed database or debug port gets caught at the pipeline gate instead of being discovered in a breach report. It turns "we think it's internal" into "we verified it from the outside."
Frequently asked questions
Is the Docker integration available now?
Not yet — it is in active development. Add your email on this page and we will let you know the moment it ships.
Does FortWatch scan inside my Docker images for CVEs?
No. FortWatch is an external attack surface scanner — its job is to check what a deployed container actually exposes to the internet (open ports, unauthenticated services, TLS, headers, exposed files), not to parse image layers. Pair it with an image scanner like Trivy or Snyk for build-time CVEs; FortWatch covers the runtime exposure those tools can't see from the outside.
Will adding a scan step slow down my builds?
The scan runs against your deployed or staging endpoint and returns a result your pipeline can gate on; you control the severity threshold and whether the step blocks the build. For faster pipelines you can run it as a non-blocking post-deploy check via a webhook instead of an inline gate.
Want the Docker integration when it ships?
We'll email you the moment it goes live — no spam, just the launch.
Get notified
Secure your entire stack today
Start scanning in under 5 minutes. No credit card required. 14-day free trial included.