PS Product SecurityKnowledge Base

🐳 Dockerfile Review Checklist

Intro: Dockerfiles are small, but they encode supply-chain trust, privilege defaults, package sprawl, and secret-handling mistakes that live far beyond one build.

Best time to use this checklist

Use it during service onboarding, build-pipeline hardening, base-image migration, or release-gate design.

Stop-the-line conditions

  • secrets or tokens used in build steps without safe handling;
  • unnecessary shells, package managers, or debugging tools in production images;
  • running as root without a strong reason;
  • untrusted or mutable base-image references without provenance checks.

Text-first review prompts

  • What is the base image, and why is it trusted?
  • Is the image pinned by digest or otherwise provenance-validated?
  • Does the image run as a non-root user?
  • Are build-time secrets handled safely and kept out of final layers?
  • Is unnecessary software excluded from the runtime image?
  • How are vulnerability scanning and rebuild cadence handled?

Evidence table

Control area What to verify Typical evidence
Base image trust Base image source and update pattern are understood Dockerfile, image policy
Privilege Runtime user is unprivileged by default USER instruction, runtime config
Build secrets Secrets are not persisted in image layers Dockerfile review, build config
Image contents Image is minimal and avoids debugging junk in production layer analysis, package list
Scanning/provenance Image is scanned and provenance is checked before deploy scanner report, signing policy

Common misses

  • using latest tags as if they were stable identity;
  • copying package manager caches or credentials into final image layers;
  • treating a minimal image as safe without checking the build context and base trust;
  • assuming runtime controls can fully compensate for a bad image hygiene pattern.

---Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.