b2KIT

Dockerfile Security Scanner

Scan Dockerfiles for security issues: running as root, hardcoded secrets, missing health checks, and insecure base images.

Tested tool guide Tested browser tools Checked August 16, 2026

What Dockerfile Security Scanner does and how it behaves

This tool reviews Dockerfile text for four specific warning classes: a container that appears to run as root, credential-like values embedded in the file, no declared health check, and a base image classified as insecure. It is a static review of the recipe, not a vulnerability scan of the image produced from it. The usual source of confusion is inheritance: a base image can supply USER or HEALTHCHECK metadata that is not visible as an instruction in the pasted file, and later stages or deployment settings can alter the effective runtime behavior.

How the result is produced

1

Dockerfile-level inspection

The scanner reads the pasted Dockerfile as build instructions and reports concerns associated with directives and literal values, including FROM, USER, HEALTHCHECK, and places where credentials may be embedded. It performs this review in the browser, so the Dockerfile is not uploaded. It does not need a built image to identify these source-level signals.

2

Stage-aware interpretation

Interpret findings against Docker's stage and instruction semantics. Each FROM begins a stage; USER affects subsequent instructions and the image's default runtime user; HEALTHCHECK NONE can cancel a health check inherited from a base image. In a multi-stage file, a builder-stage warning may not describe the final runtime stage, so trace each finding to the stage it concerns.

Good uses

  • Checking a new application Dockerfile before review or release, especially when it starts from a convenience image and never declares USER or HEALTHCHECK.
  • Triaging legacy container recipes for obvious root execution, embedded access tokens, password-like environment values, and missing health probes before conducting a deeper image audit.
  • Reviewing a Dockerfile copied from a tutorial or vendor project to identify which FROM lines and runtime defaults deserve manual investigation before building it.

Limits and checks

  • A clean report covers only the four Dockerfile-level concern types described by this scanner. It says nothing conclusive about installed packages, known vulnerabilities, malicious files, image signatures, exposed services, Linux capabilities, seccomp settings, or the configuration used when the container is launched.
  • Secret detection is ambiguous. A placeholder such as SECRET=example may look suspicious even though it is inert, while a credential fetched during RUN, copied from the build context, inherited from a base image, or injected only at runtime may not appear as a hardcoded value in the Dockerfile.
  • Root and health-check results need stage context. An explicit USER can be replaced by a later USER, HEALTHCHECK NONE disables an inherited check, and a warning in a discarded builder stage may not affect the shipped stage. Runtime configuration can also override image defaults, so a Dockerfile finding is not the complete deployment state.

Common questions

Does a clean scan mean the container image is secure?

No. A clean result means this Dockerfile did not trigger the scanner's checks for root execution, hardcoded secrets, missing health checks, or insecure base images. Security also depends on what the base and build steps install, the resulting image contents, registry provenance, and runtime privileges. Use an image vulnerability scan and deployment-configuration review as separate checks.

Will the scanner catch every secret used during a build?

No. It can only flag secret-like material visible in the Dockerfile text. Values introduced through copied files, build commands, a base image, external build inputs, or runtime environment variables may require other inspection. It can also flag examples or placeholders that merely resemble credentials. If a real credential was exposed, locate and rotate it rather than relying only on removing the line.

References and verification

The behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools

Password Generator

Generate strong, random passwords with customizable length, character sets, and complexity requirements.

Password Strength Checker

Analyze password strength with entropy scoring, crack-time estimates, and improvement suggestions.

Random String Generator

Create cryptographically random strings for API keys, tokens, salts, and unique identifiers.

QR Code Generator

Create QR codes for URLs, text, Wi-Fi credentials, vCards, and more with customizable size and colors.

QR Code Reader

Scan and decode QR codes from uploaded images or your device camera to extract embedded data.

File Checksum Calculator

Compute MD5, SHA-1, SHA-256, and SHA-512 checksums to verify file integrity and detect tampering.