Dockerfile Security Review Prompt
AI security review of a Dockerfile — privilege, attack surface, secrets in layers, vulnerable bases, supply-chain risk.
- Target user
- Container engineers and security engineers reviewing Dockerfiles
- Difficulty
- Beginner
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior container security engineer who has audited Dockerfiles in production for years. You know what hadolint, trivy, and grype flag — and what they miss. Review the Dockerfile I share. Apply this checklist: 1. **Base image** - Pinned to a specific digest (`@sha256:...`) or specific tag (`alpine:3.20`)? - Avoid `:latest` (silent upgrades = silent supply-chain risk)? - Using a minimal base (distroless, alpine, slim) where possible? - Base image known-good? (Official images, verified publishers) 2. **User & privilege** - Final `USER` directive sets a non-root user? - User exists in the image (`adduser --system` or similar)? - Avoid `--privileged` flag references in docs? 3. **Layers & secrets** - No secrets in `ARG` or `ENV` for build-time values (visible in image history)? - Multi-stage build separates build dependencies from runtime? - `COPY` of specific files, not entire `.` (avoid copying `.git`, `.env`, `.aws`, etc.)? - `.dockerignore` excludes secrets and dev artifacts? 4. **Package install hygiene** - APT: `apt-get update && apt-get install -y --no-install-recommends ... && rm -rf /var/lib/apt/lists/*` in ONE layer? - APK: `apk add --no-cache ...`? - PIP: `pip install --no-cache-dir`? - NPM: `npm ci` (not `npm install`) and clean cache? - All packages pinned to versions (where possible)? 5. **Filesystem & runtime** - WORKDIR set explicitly (don't rely on /)? - No `chmod -R 777` or world-writable paths? - HEALTHCHECK defined? - EXPOSE matches actual listening ports? - ENTRYPOINT in exec form (`["bin", "arg"]`), not shell form? - Signals handled correctly (proper init or PID 1 forwarding)? 6. **Attack surface** - SSH server not installed in app images? - Shell tools (curl, wget, nc) only in build stage, not runtime? - No `RUN curl ... | sh` pulling unverified scripts? 7. **Supply chain** - Third-party packages pinned to specific versions? - SBOM generation / scanning in the pipeline? - Image signed with cosign or similar? For each finding: **severity**, **line number**, **issue**, **fix as a Dockerfile diff**. After: **summary** (severity counts) + **rewrite the Dockerfile** applying all critical/high findings. Dockerfile: ```Dockerfile [PASTE] ``` Build context: [app type — Python web app / Node service / Go binary / etc.] Target environment: [k8s cluster / ECS / standalone Docker]
Why this prompt works
Dockerfiles have a small set of repeating security failures: root users, latest tags, secrets baked into layers, kitchen-sink installs. This prompt enforces the same checklist a security engineer runs in PR review, and produces a rewritten Dockerfile rather than vague suggestions.
How to use it
- Paste the complete Dockerfile (not screenshots, not fragments).
- Specify the app type — security context for a Python web app differs from a Go binary.
- After the review, ask: “Rewrite the Dockerfile applying every critical and high finding, in multi-stage form.”
- Build and scan the result:
docker build→hadolint Dockerfile→trivy image <tag>→grype <tag>.
Pair this with
hadolint— Dockerfile lintertrivy— vulnerability scanner (image + filesystem)grype— vulnerability scannercosign— image signing & verificationsyft— SBOM generation- A registry that scans on push (ECR, GAR, GHCR all do this)
Common findings this catches
FROM ubuntu:latest— silent upgrades, no patch tracking. Pin to24.04or a digest.USER root(or implicit root) — most containers run as root. Add a non-root user.RUN apt-get install -y ...without cleanup — bloated image, attack surface.COPY . /app— includes.git,.env,node_modulesfrom host.ENV API_KEY=...— secrets in image history.- No
HEALTHCHECK— orchestrators can’t tell if the container is healthy. ENTRYPOINT bash -c "..."— shell form, signals don’t propagate, PID 1 issues.
Example good Dockerfile structure
# Build stage
FROM golang:1.23-alpine@sha256:... AS builder
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 go build -ldflags="-s -w" -o /out/app ./cmd/app
# Runtime stage
FROM gcr.io/distroless/static-debian12@sha256:...
WORKDIR /app
COPY --from=builder /out/app /app/app
USER 65532:65532
EXPOSE 8080
HEALTHCHECK --interval=10s --timeout=3s CMD ["/app/app", "-healthcheck"]
ENTRYPOINT ["/app/app"] Related prompts
-
CI/CD Secret Exposure Review Prompt
Audit GitHub Actions, GitLab CI, CircleCI, or Jenkins pipelines for secret leaks — logged secrets, exfiltration via unscoped tokens, third-party action risks.
-
Infrastructure as Code Security Review Prompt
AI security review of Terraform, CloudFormation, or Helm charts — surface dangerous defaults, missing encryption, overly-permissive IAM, and exposed services.
-
Kubernetes YAML Security Review Checklist Prompt
AI-driven security review of Kubernetes manifests — privilege, capabilities, network exposure, secret handling, and admission-policy compliance.
-
Linux Server Hardening Prompt
Walk an AI through a CIS-style hardening review of a Linux server — services, users, SSH, kernel parameters, file permissions — with safe, ordered remediation.