Dockerfile Hardener

The Problem

Your Dockerfile runs as root. It uses ubuntu:latest as a base image (which means "whatever Ubuntu version happens to be current"). It pipes curl output directly to bash. It has ARG SECRET_KEY=production-key-here visible in docker history. It copies everything (including .env, .git, and node_modules) into the image because there's no .dockerignore. It has no HEALTHCHECK, no non-root user, and no layer optimization — so a 200MB runtime image balloons to 800MB.

Each of these is a different class of problem (security, reliability, efficiency), and most Dockerfile linters catch only a subset. Running hadolint catches best practices but not always security patterns. Running Trivy catches OS vulnerabilities but not Dockerfile anti-patterns. Nobody's checking whether you're mounting the Docker socket or running apt-get install without version pins.

What You Get

• 18-rule audit checklist across four severity tiers — CRITICAL (hardcoded secrets, running as root, unpinned base image, exposed Docker socket), HIGH (unpinned packages, ADD vs COPY, curl-to-shell, missing healthcheck, SUID binaries, secrets in build args), MEDIUM (no multi-stage build, excessive layers, no .dockerignore, cache-busting COPY, unnecessary packages, missing metadata labels), LOW (image size, missing BuildKit syntax, redundant ENV, missing WORKDIR)
• Security score (0-100) with letter grade — starts at 100, deducts points per finding severity (CRITICAL: -25, HIGH: -15, MEDIUM: -8, LOW: -3); grade A-F with production-readiness thresholds
• Hardened Dockerfile template — when any CRITICAL or HIGH finding exists, generates a complete replacement with multi-stage build, non-root user, pinned versions, cache-optimized layer ordering, HEALTHCHECK, and OCI metadata labels
• Base image security ratings — ranked table from scratch (A+) to *:latest (F) with size and use-case recommendations
• CI/CD integration — GitHub Actions (hadolint-action), pre-commit hooks, and GitLab CI templates for automated Dockerfile linting
• Docker Compose cross-check — flags compose-level issues (privileged mode, docker.sock mounts, cap_add) when the Dockerfile is part of a compose stack

Why This Beats Prompting It Yourself

A single Dockerfile can have issues across four different security domains: secret exposure (visible in layer history), runtime privilege (running as root), supply chain (unpinned packages that change between builds), and attack surface (unnecessary packages and ports). No single tool catches all four. The hardener performs a unified audit across all domains, assigns a composite security score, and generates a hardened replacement that addresses every finding simultaneously — not one-off fixes that introduce new issues.

Example Session

You: "Audit this Dockerfile for security. Here's the content."

Agent:

═════════════════════════════════════
Score: 32/100 (Grade: F)

CRITICAL (4 FINDINGS)
─────────────────────
- [C01] Line 8: Hardcoded secret: ARG API_KEY=sk-prod-abc123...
  Fix: Use --mount=type=secret in RUN instead of ARG
- [C02] Line 1: No USER directive — container runs as root
  Fix: Create non-root user with RUN addgroup/adduser, add USER after deps
- [C03] Line 1: FROM node (no tag — defaults to :latest)
  Fix: Pin to node:22.14.0-alpine or node@sha256:...
- [C04] Line 15: Docker socket mount detected
  Fix: Remove; use Docker API over TLS if Docker access is needed

HIGH (5 FINDINGS)
─────────────────
- [H01] Line 6: npm install without version pin
  Fix: Pin each package or use package-lock.json with npm ci
- [H02] Line 4: ADD used instead of COPY for local files
  Fix: Replace ADD with COPY (ADD has hidden tar-extraction behavior)
- [H03] Line 10: curl | sh pattern — no integrity check
  Fix: Download

Use Cases

• Pre-deployment security review — audit every Dockerfile before deploying to production
• Container security compliance — generate audit reports for SOC 2, PCI DSS, or internal security reviews
• Dockerfile refactoring — transform a single-stage bloated Dockerfile into a minimal multi-stage build
• CI/CD pipeline hardening — add hadolint pre-commit hooks or GitHub Actions to catch issues before merge
• New project setup — start with a hardened Dockerfile template instead of fixing issues later

Known Limitations

The audit checks Dockerfile syntax and patterns but cannot verify base image CVEs (use Trivy or Grype for OS-level vulnerability scanning). Windows container Dockerfiles have different best practices (package managers, user creation) — the tool flags but doesn't fail on Windows-specific patterns.