Skip to main content

Container Security Scanner

Paste your Dockerfile to get an instant security audit. Each rule is checked with a pass/fail/warning result and an explanation. Also generates a hardened Dockerfile template based on your base image.

✓ 10 security rules ✓ Scored security report ✓ Hardened Dockerfile template ✓ CIS Docker Benchmark aligned

Dockerfile Input

Generate Hardened Template

 

Security Score

--
Paste a Dockerfile to scan

Security Checklist

Scan a Dockerfile to see results.

Frequently Asked Questions

Why should containers run as non-root users?▼

Running as root inside a container is dangerous because if an attacker escapes the container (via a kernel vulnerability or misconfiguration), they gain root on the host. The principle of least privilege requires containers run as an unprivileged user. Use USER directive in Dockerfile: 'RUN addgroup -S appgroup && adduser -S appuser -G appgroup' then 'USER appuser'. Kubernetes SecurityContext can also enforce non-root at the pod level with runAsNonRoot: true.

What are the most secure base images to use?▼

Minimal base images reduce attack surface by containing fewer packages that could have vulnerabilities. Best options: scratch (empty, for statically compiled Go/Rust binaries), distroless (Google's minimal images without shell or package manager), Alpine (musl libc + BusyBox, ~5MB), Chainguard images (hardened, continuously patched). Avoid full debian/ubuntu/centos for production — they include compilers, package managers, and hundreds of packages you don't need.

Why are multi-stage builds important for security?▼

Multi-stage builds separate the build environment (with compilers, dev dependencies, secrets needed for fetching packages) from the final runtime image. Build secrets, SSH keys, and dev tools never appear in the final image layers. The final image only contains compiled artifacts. This dramatically reduces image size and attack surface — a typical Go app goes from 800MB to 10MB, and a Node.js app from 400MB to 50MB with multi-stage builds.

What secrets should never appear in ENV or ARG instructions?▼

API keys, database passwords, private keys, tokens, and any credentials should never be in ENV (they're visible in docker inspect and image metadata) or ARG (visible in build history). Use Docker secrets (--secret flag) for build-time secrets, or runtime secrets injection via environment from your orchestration layer (Kubernetes Secrets, AWS Secrets Manager, Vault). Scan images with tools like Trivy, docker scan, or Hadolint to detect hardcoded secrets.

What is a HEALTHCHECK and why does it matter?▼

The HEALTHCHECK instruction tells Docker how to test if a container is still working correctly. Without it, Docker only tracks if the process is running — not if it's actually healthy (e.g., the app might be deadlocked or returning errors). A health check enables orchestrators (Kubernetes, Swarm) to restart unhealthy containers and route traffic away from them. Example: 'HEALTHCHECK --interval=30s --timeout=3s --retries=3 CMD wget -qO- http://localhost:8080/health || exit 1'

Share this tool: X / Twitter LinkedIn
✓ 60,000+ developers use DevPlaybook ★★★★★ 4.8 / 5 on Gumroad ✓ MIT licensed · Instant download ✓ No login required

Related Products

on Gumroad

You Might Also Need

More Free Tools

Enjoying this tool? Get more like it.

Weekly developer tool guides, productivity playbooks & AI tricks. Free. No spam.

DevPlaybook Pro 7 days free

Unlock AI-Powered Dev Tools

  • ⚡ AI Code Review, Doc Generator & SQL Builder
  • ⚡ All premium templates & early access
  • ⚡ Member discounts on Gumroad products
Start Free Trial →

$9/mo after trial · Cancel anytime

Want the full toolkit?

Get DevPlaybook Pro

Every template, guide, boilerplate, and automation script in one bundle. 13 premium products — grab them all at once and save big.

$79
$241 separately Save $162 (67% off)
Get DevPlaybook Pro — $79 →

MIT licensed · Instant download · No subscription

See what's included → Browse all deals →