Docker Compose Security Scanner
Deep security analysis of docker-compose files detecting privileged containers, namespace sharing, secrets exposure, and capability misuse
Enter your docker-compose.yml content for deep security scanning — detects privileged containers, namespace sharing, secrets exposure, and more
What is the Docker Compose Security Scanner?
The Docker Compose Security Scanner performs deep security analysis of your docker-compose.yml files, going beyond general best practices to identify specific security vulnerabilities. It evaluates container isolation, namespace sharing, filesystem security, user permissions, secrets handling, supply chain risks, and resource constraints — then calculates a security score with detailed remediation guidance.
How to Use
- Paste your docker-compose.yml content into the input field
- Click "Scan Security" or wait for automatic processing
- Review security findings organized by severity (Critical, High, Medium, Low)
- Follow the remediation recommendations to harden your composition
- Export a full security report in JSON or Markdown format
Example: Insecure Docker Compose
This docker-compose.yml has multiple security vulnerabilities that the scanner will detect:
version: '3'
services:
app:
image: myapp:latest
privileged: true
network_mode: host
pid: host
cap_add:
- SYS_ADMIN
- NET_ADMIN
ports:
- "3000:3000"
volumes:
- /var/run/docker.sock:/var/run/docker.sock
- /proc:/host-proc
environment:
DB_PASSWORD: "super_secret_123"
API_KEY: "sk-1234567890abcdef"Security Categories Analyzed
- Container Isolation — Privileged mode, dangerous capabilities (SYS_ADMIN, NET_ADMIN), host PID/IPC namespace sharing
- Network Isolation — Host network mode, overly permissive port bindings (0.0.0.0)
- Filesystem Security — Writable root filesystem, sensitive host path mounts (/etc, /proc, /sys, /var/run/docker.sock)
- User Security — Running as root (no user specified), default UID 0
- Secrets Exposure — Hardcoded secrets in environment variables, API keys, passwords in plaintext
- Supply Chain — Using :latest tag (mutable), insecure registries (HTTP), no digest pinning
- Resource Limits — Missing memory limits (OOM risk), missing CPU limits (DoS risk)
- Reliability — Missing health checks (silent failures)
Security Scoring
Each docker-compose.yml receives a security score from 0 to 100 based on detected vulnerabilities. Severity weights are: Critical (25 points deducted), High (15 points), Medium (8 points), Low (3 points). The score maps to a letter grade: A (90+), B (75+), C (60+), D (40+), F (below 40).
Hardening Best Practices
- Never use
privileged: true— add only specific required capabilities - Always set
user: "1000:1000"to run as non-root - Enable
read_only: trueand use tmpfs for writable paths - Avoid
network_mode: host,pid: host, andipc: host - Pin images to specific version tags or SHA digests
- Use Docker secrets or env_file instead of inline environment secrets
- Bind ports to
127.0.0.1for local-only access - Set memory and CPU limits via deploy.resources.limits
- Add health checks for automatic container recovery
Privacy and Security
All security scanning happens entirely in your browser using JavaScript. Your Docker Compose configuration — which may contain service names, registry URLs, secrets, and infrastructure topology — is never transmitted to any server. No data is stored, logged, or shared.
Frequently Asked Questions
How is the Docker Compose Security Scanner different from the Docker Compose Inspector?
The Docker Compose Inspector focuses on general best practices and misconfigurations (exposed ports, latest tags, unused networks). The Security Scanner goes deeper with security-specific analysis: it detects host namespace sharing (PID, IPC, network), writable root filesystems, containers running as root, hardcoded secrets in environment variables, dangerous Linux capabilities, missing health checks, insecure registries, and missing CPU limits. Use the Inspector for quick checks, and the Security Scanner for thorough security audits.
What makes a container 'privileged' and why is it critical?
A container with privileged: true or cap_add: ALL has unrestricted access to the host kernel, all devices, and all Linux capabilities. An attacker exploiting a vulnerability in a privileged container can escape to the host, access other containers, modify kernel parameters, and potentially compromise the entire infrastructure. The scanner flags this as critical because it completely eliminates container isolation.
Why does the scanner flag containers without a user specification?
By default, Docker containers run as root (UID 0). If an attacker gains code execution inside the container, they have root privileges — which combined with any misconfiguration (like a writable host volume) can lead to host compromise. Setting user: '1000:1000' or a named non-root user limits the blast radius of a container breach.
What are dangerous Linux capabilities?
Linux capabilities are fine-grained privileges that replace the traditional root/non-root binary. Dangerous capabilities include SYS_ADMIN (near-root access, mount operations), NET_ADMIN (network configuration, firewall changes), SYS_PTRACE (debug other processes, read memory), SYS_RAWIO (raw I/O access to hardware), and NET_RAW (create raw sockets for network sniffing). The scanner flags these individually because each introduces specific attack vectors.
Why is sharing host PID/IPC/network namespace dangerous?
Host namespace sharing breaks container isolation at the kernel level. pid: host lets the container see and signal all host processes. ipc: host allows access to host shared memory. network_mode: host bypasses Docker network isolation entirely — the container shares the host's network stack, ports, and can sniff all traffic. Each is flagged as critical or high severity because they enable direct host-level attacks.
How does the scanner detect secrets in environment variables?
The scanner checks environment variable names and values against known secret patterns: passwords, API keys, tokens, private keys, database URLs, and session secrets. It specifically flags hardcoded values (not variable references like ${SECRET}) because these end up in version control, docker inspect output, and process listings. The recommendation is to use Docker secrets, env_file, or external secret managers.
What is a writable root filesystem and why does it matter?
By default, a container's root filesystem is writable. If an attacker gains code execution, they can modify application binaries, install tools, or alter configuration files. Setting read_only: true makes the filesystem immutable — the attacker cannot persist changes. Use tmpfs mounts for paths that need writes (like /tmp or /var/run).
Is my docker-compose.yml sent to any server?
No. All security scanning happens entirely in your browser using JavaScript. Your Docker Compose configuration — which may contain service names, internal hostnames, registry URLs, and infrastructure topology — never leaves your device. No data is stored, logged, or transmitted.