Dockerfile Analyzer
Analyze Dockerfiles for security issues, best-practice violations, and image optimization opportunities
Enter your Dockerfile content to analyze for security issues and best practices
What is the Dockerfile Analyzer?
The Dockerfile Analyzer is a client-side security tool that inspects your Dockerfile for common security misconfigurations, best-practice violations, and image optimization issues. It detects running as root, secrets in build arguments, unpinned or obsolete base images, and layer inefficiencies — then calculates a quality score with actionable recommendations.
How to Use
- Paste your Dockerfile content into the input field
- Click "Analyze" or wait for automatic processing
- Review findings with severity ratings (Critical, High, Medium, Low)
- Follow the recommendations to harden your container
- Export a full report in JSON or Markdown format
Example: Insecure Dockerfile
This Dockerfile has multiple security issues that the analyzer will detect:
FROM ubuntu:latest
ENV DB_PASSWORD=s3cr3t123
ARG GITHUB_TOKEN=ghp_abc123
RUN apt-get update && apt-get install -y curl
ADD . /app
CMD ["python", "app.py"]What Security Issues Are Detected?
- Root execution — No USER directive means the container runs as root, increasing attack surface
- Secrets in ENV — Passwords, tokens, and keys baked into image layers are recoverable by anyone with image access
- Secrets in ARG — Build arguments are visible in image history and build logs
- :latest tag — Unpinned base images create non-reproducible builds and unauditable deployments
- Obsolete base images — End-of-life images no longer receive security patches
- ADD for local files — COPY is more transparent; ADD has implicit extraction and remote download behavior
- apt-get without cleanup — Package cache left in layers increases image size unnecessarily
Quality Scoring
Each Dockerfile receives a score from 0 to 100 based on detected findings. Severity weights are: Critical (25 points), 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).
Docker Security Best Practices
- Always pin base images to specific version tags or SHA digests
- Use a non-root USER directive before CMD/ENTRYPOINT
- Never store secrets in ENV or ARG — use Docker BuildKit secrets or runtime injection
- Prefer minimal base images (alpine, distroless) to reduce attack surface
- Use multi-stage builds to avoid shipping build tools in production images
- Clean up package manager caches in the same RUN layer as the install
- Use COPY instead of ADD for local files
Privacy and Security
All analysis happens entirely in your browser using JavaScript. Your Dockerfile content — which may contain internal registry URLs, build arguments, and infrastructure details — is never transmitted to any server. No data is stored, logged, or shared.
Frequently Asked Questions
What security issues does the Dockerfile Analyzer detect?
The analyzer detects root execution (USER root or missing USER directive), secrets in ENV and ARG directives (passwords, API keys, tokens), usage of :latest tag or untagged base images, obsolete or end-of-life base images, use of ADD instead of COPY for local files, and apt-get install without cleanup. Each finding includes severity and a specific remediation recommendation.
How is the quality score calculated?
The score starts at 100 and deducts points based on finding severity: Critical issues (like secrets in ENV) deduct 25 points, High issues (like running as root or obsolete base images) deduct 15, Medium issues (like missing USER directive or :latest tag) deduct 8, and Low issues (like ADD instead of COPY) deduct 3. The final score maps to a letter grade: A (90+), B (75+), C (60+), D (40+), F (below 40).
Is my Dockerfile sent to any server?
No. All analysis happens entirely in your browser using JavaScript. Your Dockerfile content — which may contain internal registry URLs, build arguments, and infrastructure details — never leaves your device. No data is stored, logged, or transmitted.
Why is running as root dangerous in Docker containers?
Running containers as root means that if an attacker exploits a vulnerability in your application, they gain root privileges inside the container. Combined with misconfigured volumes, host networking, or kernel exploits, this can escalate to host system compromise. Always use a non-root USER directive before CMD or ENTRYPOINT.
Why are secrets in ENV or ARG flagged as critical?
ENV values are baked into image layers and can be extracted by anyone with access to the image using 'docker history' or 'docker inspect'. ARG values, while not persisted in the final image, are visible in build logs and intermediate layers. Use Docker BuildKit secrets (--mount=type=secret), runtime environment injection, or an orchestrator's secret management instead.
Why is the :latest tag a security concern?
Using :latest or no tag means your builds depend on whatever version happens to be current at build time. This creates non-reproducible builds, can introduce breaking changes or vulnerabilities without notice, and makes it impossible to audit which exact image version is running in production. Pin to specific version tags or digests for reproducible, auditable builds.
What format should the input be?
Paste your Dockerfile content exactly as it appears in your project. The analyzer expects standard Dockerfile syntax with instructions like FROM, RUN, COPY, ENV, ARG, USER, CMD, and ENTRYPOINT. Multi-stage builds (multiple FROM statements) are fully supported.
What is the difference between Dockerfile Analyzer and Docker Compose Inspector?
The Dockerfile Analyzer focuses on single-container build configuration — base image selection, build-time secrets, user permissions, and layer optimization. The Docker Compose Inspector analyzes multi-container orchestration — exposed ports, privileged mode, volume mounts, network configurations, and service-level security. Use both for comprehensive Docker security auditing.