Docker Image Security Checklist: Scan, Reduce, Sign, and Maintain Container Images

Overview

Container image security works best as a sequence of controls rather than a single tool. Start with a smaller, predictable image. Build it from a trusted and maintained base. Scan the result, record what it contains, sign the exact artifact that passed review, and make the deployment platform verify the image before it runs.

This approach addresses different risks at different points in the delivery path:

• Build risk: unnecessary packages, embedded secrets, unsafe build instructions, or unpinned inputs.
• Dependency risk: known vulnerabilities in operating-system packages and application libraries.
• Supply-chain risk: an image being replaced, copied incorrectly, or deployed without a traceable source.
• Runtime risk: excessive privileges, writable filesystems, broad network access, or weak identity boundaries.
• Maintenance risk: an image that was safe at release but becomes outdated as new vulnerabilities or base-image updates appear.

Security decisions should be recorded against an immutable image digest, not only a mutable tag such as latest. A tag is useful for human workflows, but a digest provides a more precise reference for release records, deployment policies, and incident investigation.

For build-size and layer guidance, use this related Docker image optimization checklist. Image optimization and image security overlap, but reducing size does not replace scanning, signing, or access control.

Checklist by scenario

Before building the image

• Choose a minimal base image that contains only what the application needs at runtime.
• Prefer a maintained base-image family and document who owns its updates.
• Separate build-time dependencies from runtime dependencies with a multi-stage build where practical.
• Pin important inputs, including base-image references and package versions, according to your update process.
• Keep secrets out of Dockerfiles, build arguments, source archives, and image layers. Use a secret-management mechanism provided by the build or deployment environment.
• Review the Dockerfile for unnecessary shells, compilers, package managers, debugging utilities, and downloaded archives.
• Define a clear image owner, application purpose, source repository, and support contact in release metadata.

During the build

• Use a clean, repeatable build environment rather than relying on files left by a previous build.
• Run a scanner against the built image, not only against the source dependency manifest.
• Scan for both operating-system packages and language-specific dependencies where the chosen scanner supports them.
• Fail the pipeline for findings that meet your documented severity, exploitability, or exposure criteria. Avoid an unexplained “fail on everything” rule that teams will routinely bypass.
• Generate an SBOM for the exact image digest being released.
• Store scan results and the SBOM with the build record or registry metadata so they can be retrieved later.
• Check for accidental credentials and sensitive configuration before pushing the image.

Before publishing to a registry

• Push to a private registry or repository with authentication and role-based permissions.
• Restrict who can push, delete, overwrite, or administer repositories.
• Use separate permissions for publishing images and deploying images.
• Enable registry audit logs when available and send them to the same monitoring process used for other security events.
• Sign the image after the final scan and build steps. Record which identity performed the signing.
• Attach the SBOM, scan results, and other attestations to the immutable image reference where your registry and tooling support this workflow.
• Apply retention and cleanup rules carefully. Do not remove artifacts that are needed for rollback, investigation, or compliance records.

Before deploying to production

• Deploy by digest or verify that the tag resolves to the expected digest.
• Require a valid signature from an approved identity or build workflow.
• Reject images that are unsigned, from an unapproved registry, or missing required metadata.
• Run the container as a non-root user unless a documented exception is necessary.
• Drop Linux capabilities that the application does not need and avoid privileged execution.
• Use a read-only root filesystem where the application supports it, with narrowly scoped writable locations for required temporary data.
• Provide only the secrets and service-account permissions required by the workload.
• Recheck Kubernetes admission, workload identity, and registry permissions. The Kubernetes RBAC best practices guide can help with the access-control portion of this review.

Scanning approach comparison

Signing approach comparison

What to double-check

A green scan is not a complete security approval. Before release, verify the following details:

• Finding context: Is the vulnerable component present in the final runtime image, or only in a discarded build stage? Is it reachable or required by the application?
• Severity policy: Does the release rule consider severity, exploitability, exposure, available fixes, and the workload’s environment?
• Fix availability: If a fix is not available, is there a documented compensating control, owner, due date, and exception expiry?
• SBOM scope: Does the SBOM describe the final image digest, including operating-system packages and application dependencies where possible?
• Signature identity: Can the deployment system distinguish an approved CI workflow from an individual developer or unknown signer?
• Digest consistency: Do the scan, SBOM, signature, release ticket, and deployment record all point to the same digest?
• Runtime user: Is the configured user actually present in the image, and can the application read and write only what it requires?
• Registry path: Are pull credentials limited to the repositories and environments that need them?

Keep a small release-maintenance worksheet for every important image:

Common mistakes

• Using a large general-purpose base image: Extra packages increase maintenance and review effort. Start with the smallest practical runtime image.
• Scanning only once: Vulnerability data changes after an image is published. Rescan retained images and define what happens when a new finding appears.
• Treating tags as proof of identity: Tags can move. Use digests and verify signatures at deployment.
• Generating an SBOM without using it: An SBOM is most useful when it supports triage, ownership, notification, and remediation decisions.
• Signing too early: Sign the final artifact after the relevant build, scan, and packaging steps. A signature on an earlier image does not validate a later rebuild.
• Running as root for convenience: Fix file ownership and permissions during the build instead of granting unnecessary runtime privilege.
• Allowing permanent exceptions: Every exception should have a reason, owner, compensating control, and review date.
• Putting policy only in documentation: Encode important checks in CI/CD and admission controls where possible. See the CI/CD pipeline best practices guide for broader workflow considerations.

When to revisit

Use this checklist for every new production image, major Dockerfile change, base-image change, and release-workflow change. Revisit it during seasonal planning cycles and whenever your registry, scanner, signing workflow, Kubernetes policy, or identity provider changes.

Set a recurring review for images that remain deployed or available for rollback. The interval should match your risk tolerance and maintenance capacity. At each review, rescan retained artifacts, check the base image and application dependencies, inspect open exceptions, verify signing and registry policies, and remove images that are no longer needed.

When a vulnerability is reported, begin with the affected digest rather than searching by tag alone. Identify the deployed workloads, review the SBOM, determine whether a fixed dependency or base image is available, rebuild and rescan, sign the replacement, and record the rollout. If immediate replacement is not possible, document temporary controls and an explicit follow-up date.

Final release gate: Do not promote the image until you can answer five questions: What exactly is in it? Which findings remain? Who approved the exceptions? Who signed this digest? What prevents an unapproved image from running?