How do you scan Docker images for vulnerabilities in CI/CD and block deployments with critical CVEs?

Think of container image scanning like the quality inspection process at a pharmaceutical manufacturing plant. Every batch of medicine must pass through a testing station that checks for contamination, verifies ingredient concentrations, and confirms the batch meets safety standards before it can proceed to packaging and distribution. If a batch fails any critical safety test, it is quarantined and cannot reach patients. The testing station also continuously monitors stored batches because a recall notice could arrive at any time for an ingredient that was previously considered safe. Container image scanning in CI/CD follows the same pattern: scan at build time, gate on policy, store the evidence, and rescan continuously.

The scanning process works by analyzing every layer of a container image. A container image is a stack of filesystem layers, each adding packages, libraries, configuration files, or application code. Vulnerability scanners like Trivy decompose the image into these layers, identify every installed OS package and application dependency, and compare each one against the National Vulnerability Database, vendor security advisories, and specialized databases like the GitHub Advisory Database. The scanner produces a report listing every known CVE affecting the image, with severity ratings from negligible to critical, fix availability information, and CVSS scores. For banking applications, the report also generates a Software Bill of Materials that documents every component in the image, satisfying regulatory requirements for software transparency.

The CI/CD pipeline integrates scanning as a mandatory gate between the build and push stages. After the Docker image is built, the scanner runs against the local image before it is pushed to the container registry. The pipeline configuration specifies a policy: which severity levels should block the pipeline, which CVEs are explicitly accepted through a risk exception process, and what the maximum allowable vulnerability count is per severity. In banking environments, the typical policy blocks any image with critical CVEs and requires a security review for high CVEs. The scan results are published to a centralized dashboard and stored as pipeline artifacts for SOX audit evidence. Failed scans create tickets in the vulnerability management system with the affected image, namespace, owning team, and remediation deadline.

Continuous scanning addresses the gap between build-time security and runtime exposure. An image that passes all checks today may have a new critical CVE published tomorrow affecting one of its base image packages. Registry-level scanning tools like ECR enhanced scanning, Harbor with Trivy, or Prisma Cloud continuously rescan all images in the registry against updated vulnerability databases. When a new critical CVE affects an image that is currently deployed in production, the scanning system triggers an alert to the owning team with the specific CVE details, affected pods, and remediation guidance. Teams then rebuild with a patched base image and deploy through the standard pipeline, creating a complete audit trail of the vulnerability lifecycle from discovery to remediation.

The production gotcha is managing false positives and vulnerability exceptions without creating security debt. Not every CVE is exploitable in every context: a vulnerability in a network utility is irrelevant if the container does not have network tools installed or if the affected code path is never reached. Banking teams maintain an exception registry where accepted vulnerabilities are documented with a justification, an expiration date, and an approving security engineer. Exceptions are reviewed quarterly as part of the vulnerability management program. Another common mistake is scanning only the application image while ignoring sidecar containers, init containers, and operator images that run in the same pod. A vulnerable logging sidecar or Vault Agent container provides the same attack surface as the main application container and must be scanned with the same rigor.