🛡
docker-vulnerability-scanner

Free Online Security Tool

Docker Image Vulnerability Scanner —
Check & Scan Dockerfiles Instantly

Paste any Dockerfile to check for security vulnerabilities in seconds. Detects outdated base images with known CVEs, root user execution, hardcoded secrets, exposed ports, and dangerous instructions. No CLI, no Docker daemon, no login required.

Free No CLI required No login CVE-prone base images Root user detection Hardcoded secrets Security score 14 vulnerability checks

// Paste Dockerfile contents

// How to scan

How to Scan Docker Images for Vulnerabilities — No Install Required

Most vulnerability scanners require installing a CLI tool, running a Docker daemon, or building the image first. This tool performs static Dockerfile analysis — catching security issues before the image is even built, directly in your browser.

  1. 01
    Open your Dockerfile Any Dockerfile works — local development, CI/CD pipeline, or a client project. Copy the full file contents.
  2. 02
    Paste and scan Paste the Dockerfile into the field above and click Scan for Vulnerabilities. The tool checks against 14 security rules instantly — no server calls, no data stored.
  3. 03
    Review findings by severity Each finding includes a severity level (Critical, High, Medium), an explanation of the risk, and a specific fix recommendation with example code.
  4. 04
    Apply fixes and rescan Update your Dockerfile based on the recommendations, paste it again, and confirm the score improves. Aim for zero Critical and High findings before deploying to production.

Click Load Sample Dockerfile above to see the scanner in action with a pre-built example containing multiple vulnerabilities across all severity levels.

// Core concept

What Is a Docker Image Vulnerability?

A Docker image vulnerability is a security weakness embedded inside a container image that can be exploited to compromise the container, its host, or the broader infrastructure. Unlike application vulnerabilities in source code, image vulnerabilities often come from the environment the application runs in — the base OS, the installed packages, the runtime configuration, or the instructions used to build the image.

Container image vulnerabilities fall into several categories. Base image CVEs are the most common — an outdated Ubuntu or Node.js base image may contain dozens of unpatched known vulnerabilities from its package repositories. Configuration vulnerabilities include running as root, exposing sensitive ports, or using hardcoded credentials. Supply chain vulnerabilities arise from pulling remote scripts or using untrusted registries without verification.

The distinction between a Docker image vulnerability and a running container vulnerability matters for remediation. Image vulnerabilities are fixed by modifying the Dockerfile and rebuilding. Runtime vulnerabilities — where an attacker has already exploited a weakness — require incident response. This tool focuses on catching image vulnerabilities before deployment, at the Dockerfile level.

// Image layer assessment

Image Layer Vulnerability Assessment — How Docker Layers Create Risk

Every instruction in a Dockerfile creates a new read-only layer in the final image. A Docker image is a stack of these layers, and vulnerabilities can be introduced at any of them. An image layer vulnerability assessment examines each layer for security risks — not just the final state of the container.

FROM
Pulls the base image. If the base is EOL (ubuntu:18.04, node:14), it introduces all known CVEs from that distribution's unpatched packages.
⚠ Highest risk layer — EOL base images contain dozens of unpatched CVEs
RUN
Installs packages or runs commands. Packages installed here inherit CVEs from their versions. Curl-pipe-to-bash patterns execute unverified remote code.
⚠ Supply chain risk — always pin package versions and verify checksums
ENV
Sets environment variables. Hardcoded secrets (passwords, API keys, tokens) baked into ENV are visible to anyone with image access and appear in docker history.
⚠ Secret exposure — use runtime injection or Docker secrets instead
COPY / ADD
COPY is safe for local files. ADD has implicit behaviors — it can fetch remote URLs and auto-extract archives, introducing unverified content.
⚠ Use COPY for local files — only use ADD when tar extraction is explicitly needed
EXPOSE
Documents which ports the container listens on. Exposing sensitive ports like SSH (22) or database ports (3306, 5432) increases attack surface.
⚠ Remove EXPOSE for sensitive ports — use internal Docker networks for DB access
USER
Sets the user for subsequent instructions and the container runtime. Missing USER means the container runs as root by default.
✓ Always add USER after creating a non-root user — this is the single most impactful security improvement
HEALTHCHECK
Defines how orchestrators verify the container is healthy. Without it, a broken container keeps receiving traffic.
✓ Add HEALTHCHECK to enable automatic detection and restart of unhealthy containers
// Detection capabilities

What Docker Vulnerabilities This Scanner Detects

This tool checks Dockerfiles against 14 security rules covering the most common vulnerability categories found in production container images.

critical //

Outdated Base Images with Known CVEs

Detects EOL images: ubuntu:18.04, node:14, node:12, python:3.7, python:3.8, debian:stretch, centos:7. These no longer receive security patches.

critical //

Root User Execution

Flags containers with no USER directive. The default Docker user is root — container escape means host root access.

critical //

Hardcoded Secrets in ENV

Scans ENV for patterns matching PASSWORD, SECRET, API_KEY, TOKEN, PRIVATE_KEY. These are baked into every image layer.

critical //

curl / wget Pipe to bash

Detects curl URL | bash and wget URL | bash patterns — the most common supply chain attack vector in Dockerfiles.

high //

Unpinned "latest" Tag

Detects :latest usage. Non-deterministic builds can silently introduce new CVEs without warning on the next pull.

high //

Sensitive Port Exposure

Flags EXPOSE 22 (SSH), 3306 (MySQL), 5432 (PostgreSQL), 6379 (Redis), 27017 (MongoDB), 9200 (Elasticsearch).

medium //

ADD with Remote URL

Flags ADD https:// — downloads remote content at build time without integrity verification. A supply chain risk.

medium //

Missing HEALTHCHECK

Flags Dockerfiles without a HEALTHCHECK directive. Orchestrators cannot detect broken containers without one.

// Docker security

Docker Image Vulnerability Scanning Best Practices

Scanning is one step in a broader security posture. Here are the most impactful practices for reducing Docker image vulnerability exposure across the build pipeline.

// vs. Trivy & Snyk

Free Alternative to Trivy and Snyk for Dockerfile Analysis

Trivy and Snyk are the industry standards for Docker image vulnerability scanning — they query live CVE databases and scan actual image layers. This tool is a free, zero-setup alternative for Dockerfile-level static analysis, ideal for pre-build checks and quick audits.

Feature This Tool Trivy Snyk Container
Requires CLI install ✓ No install ✗ CLI required ✗ CLI / account
Requires Docker daemon ✓ No daemon ✗ Needs Docker ✗ Needs Docker
Works on unbuilt Dockerfile ✓ Yes ✗ Needs built image ✗ Needs built image
Live CVE database ✗ Pattern-based ✓ Full CVE DB ✓ Full CVE DB
Package-level CVE scan ✗ Not available ✓ Full scan ✓ Full scan
Login required ✓ No account ✓ No account ✗ Account needed
Free ✓ Always free ✓ Open source — Free tier limited

Need package-level CVE scanning against a live vulnerability database? Use Trivy — it's open source and the industry standard. Need a quick Dockerfile audit before committing or sharing? This tool is faster with zero setup.

// Community questions

What Security Engineers Ask About Docker Image Vulnerability Scanning

Common questions from developers and security engineers dealing with container security — the kind of discussions found on Reddit, DevSecOps forums, and Docker community channels.

What's the fastest way to check a Dockerfile for vulnerabilities before pushing to a registry?
For a quick pre-commit check: paste the Dockerfile into this browser scanner. It catches the most common issues — EOL base images, root user, hardcoded secrets, exposed ports — in seconds with no setup. For a full CVE scan before pushing to a registry, use trivy image --severity HIGH,CRITICAL myimage:latest as part of your CI/CD pipeline. The two approaches are complementary, not competing.

How do I know if my base image has known CVEs without pulling it?
Check the base image version against its official end-of-life date. Ubuntu 18.04, Node.js 14, Python 3.7, and Debian Stretch are all past EOL and receive no security patches. Any image built on these bases inherits all their unpatched vulnerabilities. The Docker Hub page for official images lists active CVE counts — or paste your FROM line into this scanner to get an instant flag.

Why does my Docker image fail security scans even after I update the base image?
Updating the base image fixes base-image CVEs but not package-level CVEs introduced by your own RUN instructions. If you install packages with apt-get install without pinning versions, you may be installing vulnerable package versions. Also check: are you running as root? Do you have hardcoded credentials? Are you exposing database ports? Each of these is flagged independently from the base image.

Is it safe to use Docker Hub images without scanning them?
Official Docker Hub images (marked with the blue "Official Image" badge) are regularly scanned and maintained. However, "popular" community images without the official badge should always be scanned before use. Even official images can have CVEs between update cycles. Docker Hub's vulnerability scanning tab shows the current CVE count for each image tag — always check before pulling, especially for older tags.

What's the difference between a Dockerfile vulnerability scanner and a runtime scanner like Falco?
A Dockerfile scanner (like this tool or Trivy) analyzes the image before it runs — it finds CVEs in packages, misconfigurations, and dangerous instructions at build time. A runtime scanner like Falco or Sysdig monitors container behavior while it's running — detecting unexpected syscalls, file access, or network connections that indicate an active attack. Both are necessary: build-time scanning prevents deploying vulnerable images, runtime scanning catches what slips through and detects post-exploitation activity.

Should I scan Docker images in CI/CD even if I scanned the Dockerfile already?
Yes. Dockerfile analysis catches configuration and base image issues at write time. But by the time your CI/CD pipeline runs, the base image may have changed (if not pinned), new CVEs may have been disclosed, and your dependency lock files may have resolved to vulnerable package versions. Run both: static Dockerfile analysis early (this tool), and a full image scan (Trivy) after the image is built, as a pipeline gate before pushing to your registry.

```
// FAQ

Frequently Asked Questions

Paste your Dockerfile into the scanner above and click Scan for Vulnerabilities. The tool checks for 14 vulnerability patterns including EOL base images, root user execution, hardcoded secrets, and dangerous instructions — all in your browser with no CLI or Docker installation required.
Avoid any end-of-life base image: ubuntu:18.04, ubuntu:16.04, node:14, node:12, python:3.7, python:3.8, debian:stretch, debian:jessie, centos:7. These no longer receive security patches and contain known unpatched CVEs. Prefer ubuntu:24.04, node:22-alpine, python:3.12-slim, or distroless images.
Secrets in ENV are baked into every image layer and remain visible in docker history even after deletion from later layers. Anyone with access to the image can extract them. Use runtime environment injection, Docker secrets, or secret management tools like Vault to pass credentials at runtime rather than build time.
Each Dockerfile instruction (FROM, RUN, COPY, ENV, EXPOSE) creates a separate image layer. An image layer vulnerability assessment examines each layer for security risks — base image CVEs in the FROM layer, supply chain risks in RUN, secret exposure in ENV, and attack surface in EXPOSE. This tool analyzes all layers from the Dockerfile before the image is built.
docker scan and Trivy query live vulnerability databases and scan the actual built image layers against real CVE records — they require a built image and a Docker daemon. This tool performs static Dockerfile analysis instantly in your browser before building, with no CLI, no daemon, and no account. Use this for quick pre-build checks and Trivy for comprehensive CVE scanning in CI/CD.
No. All analysis runs entirely in your browser using JavaScript. Nothing is sent to any server. Safe to use with proprietary, internal, or production Dockerfiles.