Container Image Security Scanning: A Practical CI/CD Checklist for Cloud Apps

Overview

A container image combines application code, libraries, runtime components, operating-system packages, configuration files, and sometimes build artifacts. Each layer can introduce a vulnerability or an unintended secret. A scanner can compare known components with vulnerability data, inspect image configuration, identify exposed credentials, and flag risky settings. It cannot, by itself, prove that an application is secure.

The most reliable approach is to connect scanning to the full CI/CD path: build, inspect, evaluate, fix or document, sign, and promote. Run checks before an image reaches a shared registry when practical, then scan again at registry or deployment stages if the environment supports it. The second check matters because vulnerability databases, base images, and policy rules change after an image was originally built.

Define the release decision before enabling a scanner. For example, a team might block an image when it contains a critical issue with a known fix, a confirmed secret, or a prohibited configuration. Other findings may create a ticket or warning rather than stop delivery. The exact thresholds should reflect application exposure, data sensitivity, exploitability, compensating controls, and the team's ability to respond.

Image scanning should sit alongside application observability, not replace it. After deployment, use logs, metrics, traces, and alerts to detect behavior that static checks cannot see. See Cloud App Observability: Logs, Metrics, Traces, and Alerts Explained for the operational layer.

Checklist by scenario

Before creating or changing a base image

• Choose a maintained base image appropriate for the runtime and deployment environment.
• Prefer a minimal image that contains only the runtime components the application needs. Smaller images can reduce unnecessary packages, although minimal size is not a substitute for patching.
• Record the base image reference, build date, architecture, and source in version control or build metadata.
• Pin important build inputs where reproducibility matters, while maintaining a process for reviewing and updating those pins.
• Remove package-manager caches, compilers, test fixtures, and temporary files from the final runtime stage when they are not required.
• Use a multi-stage build to separate compilation tools from the production image when the application allows it.

During the CI build

• Build from a clean, controlled environment and generate an image identifier that can be traced to a commit and pipeline run.
• Scan operating-system packages and language dependencies. A container may contain vulnerabilities in both layers, even when the application code itself has not changed.
• Run secret detection against the image filesystem and build context. Check source files, copied configuration, shell history, certificates, package-manager files, and generated artifacts.
• Inspect image configuration for root execution, excessive Linux capabilities, writable sensitive paths, unnecessary exposed ports, and unsafe entrypoint behavior.
• Export machine-readable results so findings can be reviewed, tracked, and compared between builds.
• Fail the build only on rules the team has agreed to maintain. An unreviewed block-everything policy often encourages bypasses or ignored alerts.

When a vulnerability is found

• Confirm the affected component and installed version. Scanners can report a package that is present but not reachable, or a result that needs contextual review.
• Check whether a fixed version is available and whether upgrading it changes application behavior.
• Determine whether the image is internet-facing, handling sensitive data, used only in development, or protected by additional controls.
• Prioritize findings using severity, exploitability, exposure, availability of a fix, and business impact rather than severity alone.
• Rebuild after remediation and scan the resulting image. Updating a package file without rebuilding the actual artifact does not resolve the deployed risk.

Before registry promotion and deployment

• Allow promotion only from the image digest that passed the required checks. Avoid relying solely on a mutable tag such as latest.
• Attach scan results, build provenance, ownership, and exception references to the image or release record.
• Sign the approved image or its provenance according to the trust model used by the organization.
• Configure the deployment platform or admission control to accept only approved repositories, signatures, environments, or policy states where those controls are available.
• Record the exact digest deployed to each environment so a later investigation can distinguish rebuilt images with the same tag.

For a broader release sequence, compare this process with the Cloud App Deployment Checklist: From Git Push to Production Monitoring.

What to double-check

Use the following reference table to turn scan results into consistent release actions. It is a starting policy, not a universal rule; teams should adjust it to their threat model and deployment controls.

Double-check scanner scope as well. Some tools inspect only the final image filesystem; others can inspect source dependencies, image history, configuration, or registries. Know which checks run in which stage, and avoid assuming that one scan covers the entire software supply chain.

Also verify that exceptions are visible to the people who make release decisions. An exception should state the finding, affected image digest, reason, mitigating controls, owner, approval, and expiration or review date. A permanent “accepted risk” with no accountable owner is usually an undocumented backlog item.

Common mistakes

• Scanning only after deployment: This detects risk late and allows an unreviewed artifact to enter production. Scan during build and before promotion.
• Using tags as identity: Tags can be moved. Track immutable digests and connect them to source commits and pipeline runs.
• Deleting a secret in a later layer: Container history or cached layers may retain it. Remove the secret from the build process, rotate it, and rebuild from a clean context.
• Blocking on every severity label: This creates noisy pipelines and makes urgent findings harder to distinguish. Define thresholds using context and exploitability.
• Ignoring development images: Development and test images can expose credentials or enter shared environments. Apply an appropriate baseline to every image that can be distributed or deployed.
• Updating without retesting: A package fix can alter APIs, startup behavior, or native dependencies. Rebuild, test, scan, and verify the runtime image.
• Failing to scan rebuilt images: A base-image refresh can introduce a new package or configuration change even when application code is unchanged.
• Confusing scanning with runtime security: A clean image does not prevent insecure authentication, excessive network access, or vulnerable application behavior. Pair supply-chain checks with least privilege, secure deployment settings, and monitoring.

Application credentials and token handling deserve separate review. If the image contains API authentication components, use the guidance in API Authentication for Cloud Applications: OAuth, OIDC, API Keys, and JWT Compared rather than embedding secrets in image configuration.

When to revisit

Revisit this checklist whenever a base image, runtime, framework, package lockfile, build action, scanner, registry, or deployment platform changes. A scheduled review before seasonal planning or major release cycles is also useful, especially when teams revise risk tolerance, ownership, or production environments.

At each review, confirm that the scanner still covers the image types you build, its vulnerability data is being updated, and its output reaches the right owners. Test the policy with a controlled sample finding so the team knows whether the pipeline warns, blocks, creates a ticket, records an exception, or permits promotion. Review open exceptions for expiration, changed exposure, and available fixes.

For the next release, take these actions: identify the exact image digest, scan the final artifact, review secrets and privilege settings, triage findings by context, remediate or document each blocking issue, sign the approved image, and record the digest deployed. Repeat the scan after any rebuild. This makes container image security scanning a practical part of cloud app delivery rather than a report that arrives after the release decision has already been made.