Dockerfile Production Security Checklist

Make the base image decision reviewable

Record why the chosen base image fits the application and who will maintain its updates. A mutable tag can point to different image content later. Digest pinning identifies specific content, but it also makes an update process essential: a pinned vulnerable image does not become safer on its own.

Keep the build context focused with a .dockerignore file. Review what a broad COPY . . can include, especially local configuration, test data, and generated artifacts. Prefer explicit application inputs when that makes the build easier to inspect. Docker’s build best practices cover base-image selection, context size, caching, and updates.

Separate build tools from the runtime artifact

A multi-stage build lets you compile or package an application in one stage and copy the required outputs into another. That can keep compilers and development dependencies out of the final image. The final stage still needs every runtime dependency the application actually uses.

During review, identify the final stage and list what crosses into it. Check executable permissions, shared libraries, certificates, and files loaded dynamically. A small image that fails when it encounters its first TLS connection is not ready for release. The Docker multi-stage build guide explains how stages and targeted copies work.

.git
node_modules
.env
.env.*
*.pem
coverage

Check this list against your build inputs. For example, a test or packaging stage may intentionally need files excluded by a generic template. Review the resulting context instead of treating the example as a universal policy.

Keep build credentials out of image instructions

Do not use build arguments or ordinary environment variables as a secret store. When a build needs private package access, use the builder’s secret mechanism and scope the credential to the command that needs it. A later layer that removes a copied credential is not a substitute for keeping it out of the image build inputs.

Check scripts as well as the Dockerfile: a script can echo a token into a log or write it into an artifact. Review your CI system’s handling of the supplied secret separately. Docker documents the mount mechanism in build secrets.

Test the final image as it will run

Confirm the intended non-root process can read application files and write only where expected. Run a representative request, check shutdown handling, and verify that configuration comes from the deployment rather than a developer’s machine. Use a health signal that reflects the application’s behavior and the orchestrator that will run it.

• Review the final image, not just an intermediate build stage.
• Inspect the image for unexpected configuration or credentials.
• Exercise startup and shutdown under the intended user.
• Keep an update and rollback path for the chosen image version.

Sentinel’s Dockerfile checks can help identify risky patterns for review. They complement dependency and image scanning; they do not replace either. When a supported patch is available, inspect it and rebuild the image before accepting it. For deployment-side controls, continue with the Kubernetes workload review.