Skip to content
CloudOps
All prompts
AI for DevOps Security & Hardening Difficulty: Beginner ClaudeChatGPTCursor

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

  1. Paste the complete Dockerfile (not screenshots, not fragments).
  2. Specify the app type — security context for a Python web app differs from a Go binary.
  3. After the review, ask: “Rewrite the Dockerfile applying every critical and high finding, in multi-stage form.”
  4. Build and scan the result: docker buildhadolint Dockerfiletrivy image <tag>grype <tag>.

Pair this with

  • hadolint — Dockerfile linter
  • trivy — vulnerability scanner (image + filesystem)
  • grype — vulnerability scanner
  • cosign — image signing & verification
  • syft — 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 to 24.04 or 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_modules from 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

Newsletter

Get weekly AI workflows for DevOps engineers

Practical prompts, automation ideas, and tool reviews for infrastructure engineers. One email per week. No spam.