Dockerfile Security Basics Checker

A Dockerfile determines far more than how application files enter an image. It chooses the software supply-chain starting point, decides which build material can persist in layers, sets the runtime identity, and defines the command and health behavior operators will inherit. A short file can therefore carry several release risks at once.

Static review is most useful before a build, when risky defaults are still cheap to change. A mutable base tag can drift between rebuilds, a broad context copy can pull local secrets into a layer, and an ARG or ENV declaration can preserve sensitive material in image metadata or history. Running as root and exposing management ports expand the impact of a later compromise.

• Base-image trust covers the registry, tag or digest, and the deliberate process used to refresh pinned images.
• Build containment keeps secrets, unrelated files, remote installers, and package-manager residue out of the finished image.
• Runtime least privilege uses an explicit non-root user, narrow permissions, an absolute working directory, and only the listener the application needs.
• Operational readiness includes an explicit command and, for a service profile, a bounded healthcheck that tests useful behavior.

Some practices involve tradeoffs rather than universal bans. Digest pins make a build reproducible but must be updated to receive patched base images. ADD has legitimate archive and remote-fetch behavior, while COPY is clearer for ordinary file transfer. A CI builder image may not need a runtime healthcheck, but a long-running service usually benefits from one.

A clean static result is only a baseline. It cannot reveal vulnerable packages in the resolved image, secrets hidden in copied files, a compromised base image, unsafe container privileges, or a command that fails after startup. Build the image, scan it, inspect its contents and provenance, and exercise the runtime path before release.

How to Use This Tool:

Review the exact Dockerfile intended for the release and select the profile that matches the final image's job.

1. Paste the Dockerfile source or load one Dockerfile or plain-text file up to 512 KiB. Remove real credentials before sharing or saving review evidence.
2. Choose Runtime service, CI builder image, or Strict release gate. The service profiles expect a final-stage healthcheck; strict release also requires digest pins.
3. Set the approved Trusted registries. Enable Force digest-pin checks when local policy requires digests outside the strict profile, and disable Include low signals only when the review intentionally excludes Low and Info findings.
4. Review the highest-severity rows before the numeric score. Each finding names a line when one is available, the matched signal, evidence, and a suggested correction.
5. Verify fixes by building with current Docker checks, scanning packages and secrets, confirming the final user and image contents, and running the health and startup paths.

Interpreting Results:

The Risk band follows severity before score. Any Critical finding is Blocked; any High finding is Needs hardening; and any Medium finding is at least Review. Weighted points can raise a collection of lower findings into those same bands, but they cannot lower a severe finding.

• Baseline clear means no enabled static rule matched. It is not a release approval.
• Low-signal cleanup contains only Low or Info findings and remains worth reviewing for maintainability and attack-surface reduction.
• Review means at least one Medium finding or a score of 10 to 27 without a High or Critical finding.
• Needs hardening means at least one High finding or a score of 28 or more without a Critical finding.
• Blocked means the Dockerfile has no usable FROM instruction or another Critical base-image defect.

Technical Details:

The review joins continued physical lines into Dockerfile instructions, ignores blank lines and comments, and assigns each instruction to its build stage. Final-user, work-directory, command, and healthcheck rules inspect only the last stage, while base-image, secret, context, package, permission, port, and build-check rules can apply across stages.

Rule Core

Formula Core

The risk score is the sum of the enabled finding weights. Duplicate findings with the same identifier and evidence are counted once.

Disabling Include low signals removes Low and Info rows before counting and scoring. Visible finding limit only limits the displayed ledger to 5 through 200 rows; it does not change the underlying result.

Profile rules

Force digest-pin checks requires a digest regardless of profile. A finding is evidence that a text pattern matched the bounded rules; context can justify an exception, but the exception should be reviewed and recorded outside the score.

Limitations and Privacy Notes:

Dockerfile text and loaded files are read in the current browser. The review does not build or pull an image, expand variables, inspect a .dockerignore, resolve package versions, scan filesystem layers, verify signatures or provenance, test container privileges, or run the declared command and healthcheck. Treat the results as pre-build triage and avoid pasting live secrets even though the review is local.

References:

• Building best practices, Docker Docs.
• Build secrets, Docker Docs.
• Dockerfile reference, Docker Docs.
• Docker Security Cheat Sheet, OWASP Cheat Sheet Series.
• How to create a Dockerfile, Simplified Guide.
• How to build a multi-stage Docker image, Simplified Guide.