Category: Vulnerability Management
Image Scanning
Also known as: Container Image Scanning, Container Image Analysis
Simply put
Image scanning is the process of analyzing container images to identify known security vulnerabilities and risks before or after deployment. It examines the contents of a container image, including its base layers and installed packages, to flag issues that could be exploited. This practice is typically integrated into CI/CD pipelines, container registries, and runtime environments.
Formal definition
Container image scanning involves static analysis of container image layers and their constituent components, including operating system packages, application libraries, and configuration files, against known vulnerability databases to identify CVEs and security risks. Scanning may be performed at multiple points in the container lifecycle, including during CI builds, within image registries, and against deployed containers at runtime. Static image scanning can identify known vulnerabilities in packaged software components present in the image, but typically cannot detect vulnerabilities that manifest only through runtime behavior, misconfigurations that depend on deployment context, or zero-day vulnerabilities not yet present in reference databases. Known false negative categories include vulnerabilities in unpacked or non-standard package formats, and issues introduced at runtime rather than baked into the image. Scope boundaries generally cover declared dependencies and installed packages within the image filesystem rather than dynamic or network-level exposures.
Why it matters
Container images are the fundamental unit of deployment in modern cloud-native environments, and vulnerabilities present in an image at build time will be carried into every environment where that image runs. Because images bundle an operating system base layer, system libraries, and application dependencies together, a single unpatched package can expose all containers derived from that image to known exploits. Catching these issues before deployment is substantially less costly and disruptive than responding to them in production.
Who it's relevant to
DevOps and Platform Engineers
Platform and DevOps engineers are typically responsible for integrating image scanning into CI/CD pipelines and container registries. They configure scan policies, set threshold rules that may block promotion of vulnerable images, and ensure scanning tooling is kept current so that vulnerability database coverage remains as comprehensive as possible.
Application Security Teams
Security teams use image scanning results to track vulnerability exposure across the organization's container portfolio, prioritize remediation efforts, and establish baseline policies for acceptable risk levels in images before deployment. They also evaluate scanner coverage and understand the scope boundaries and known false negative categories of the tools in use.
Software Developers
Developers encounter image scanning findings when building or updating container images. Understanding scan results helps developers distinguish between vulnerabilities in base image layers versus application dependencies they directly control, and guides decisions about base image selection, dependency updates, and remediation sequencing.
Cloud and Infrastructure Architects
Architects designing container-based infrastructure need to account for where scanning fits in the container lifecycle, including registry-level scanning and runtime coverage, and understand what image scanning does and does not address so that complementary controls can be selected for gaps such as runtime behavior or deployment-context misconfigurations.
Inside Image Scanning
OS Package Analysis
Inspection of operating system packages installed in the container image, typically sourced from distributions such as Debian, Alpine, or Red Hat, to identify known CVEs associated with those package versions.
Application Dependency Scanning
Analysis of language-specific package manifests and installed libraries (such as those managed by npm, pip, Maven, or RubyGems) within the image filesystem to detect vulnerable third-party dependencies.
Vulnerability Database Matching
Correlation of identified packages and versions against one or more vulnerability databases, such as the NVD, vendor-specific advisories, or aggregated feeds, to surface known CVEs and severity ratings.
Layer-by-Layer Filesystem Inspection
Traversal of the union filesystem layers that compose a container image to enumerate installed components, configuration files, and artifacts introduced at each build stage.
Secret and Credential Detection
Pattern-based scanning of image contents for hardcoded secrets, API keys, tokens, or credentials that may have been inadvertently embedded during the image build process.
Base Image Identification
Identification of the parent or base image from which the scanned image was built, enabling inherited vulnerability tracking and policy enforcement against unapproved base images.
Policy and Threshold Evaluation
Application of configurable rules that determine whether an image passes or fails based on criteria such as maximum allowable severity, presence of specific CVEs, or license compliance requirements.
Common questions
Answers to the questions practitioners most commonly ask about Image Scanning.
Does scanning a container image mean my running containers are secure?
Not necessarily. Image scanning analyzes the static contents of an image at a point in time, typically checking for known vulnerabilities in installed packages and libraries. It cannot account for runtime conditions such as misconfigurations applied at deployment, secrets injected via environment variables, network exposure, or vulnerabilities that emerge from how the container interacts with its environment. A clean scan result reflects the image's state at scan time, not the security posture of a running container.
Will image scanning catch all the vulnerabilities in my container?
No. Image scanning has known false negative behavior in several categories. It typically cannot detect vulnerabilities in application-layer code that are not tied to a catalogued package, logic flaws, misconfigurations outside the image filesystem, or issues that only manifest at runtime. Scanner coverage also depends on the quality and currency of the vulnerability database being used, so vulnerabilities disclosed after the last database update will generally be missed. Scope boundaries mean that scanning is one layer of defense, not a comprehensive security guarantee.
At what point in the pipeline should image scanning be performed?
Image scanning is most effective when integrated at multiple points: during the build stage to catch issues early, at the registry level before images are promoted to production, and optionally as a recurring scheduled scan against images already in the registry to catch newly disclosed vulnerabilities. Scanning only at build time can miss vulnerabilities disclosed after the image was built but before or during deployment.
How should teams handle false positives from image scanners?
False positives are common in image scanning, often occurring when a package is present in an image but the vulnerable code path is not compiled in, not reachable, or already patched by the distribution vendor without a corresponding CVE update. Teams should establish a documented exception and triage process that includes recording the justification for suppressing a finding, setting a review expiration date, and distinguishing between accepted risk and confirmed false positives. Most enterprise scanners support allowlist or suppression mechanisms for this purpose.
What is the difference between scanning a base image and scanning a final application image?
Scanning a base image checks only the operating system packages and libraries present in the starting layer. Scanning the final application image includes those base layers plus any packages, dependencies, and files added during the build process, including application runtimes and third-party libraries. Final image scanning provides broader coverage and is generally preferred for production gates, though base image scanning is useful for upstream hygiene and reducing inherited vulnerability surface area.
How do vulnerability severity scores from image scanners translate into actionable remediation priorities?
Severity scores such as CVSS provide a standardized baseline but should not be used as the sole prioritization factor. Teams should also consider whether the vulnerable component is actually reachable in the deployed application, whether a fix is available, the exposure context of the container, and whether compensating controls are already in place. A high CVSS score for a library that is present but unused in the application may warrant lower priority than a medium score for a component that handles external input. Contextual risk assessment alongside scanner output typically produces more actionable remediation queues.
Common misconceptions
A clean image scan result means the running container is secure.
Image scanning operates at the static, pre-execution level and cannot detect runtime threats such as malicious process injection, exploitation of configuration weaknesses, insecure network behavior, or vulnerabilities introduced after the image is deployed. A passing scan result reflects the state of the image at scan time, not the security posture of a live container.
Image scanning catches all vulnerabilities present in the image.
Image scanners are bounded by the completeness and freshness of the vulnerability databases they query. They typically cannot detect vulnerabilities in custom or proprietary code compiled into binaries without accompanying metadata, logic flaws, or zero-day vulnerabilities not yet assigned a CVE. False negatives are a known limitation, particularly for statically compiled binaries and stripped executables.
High CVE counts from an image scan always indicate immediate, exploitable risk.
Many reported CVEs may have no available fix, may affect components not reachable in the deployed application context, or may carry high base scores that do not reflect actual exploitability in a specific environment. Scan output requires triage and contextual prioritization rather than treating every finding as equally critical.
Best practices
Integrate image scanning into the CI/CD pipeline at build time so that vulnerable images are identified before they are pushed to a registry or deployed to production.
Establish and enforce severity-based gate policies that block promotion of images containing vulnerabilities above a defined threshold, while documenting and time-bounding any accepted exceptions.
Rescan images stored in registries on a regular schedule to surface newly disclosed vulnerabilities in images that passed earlier scans, since vulnerability databases are updated continuously.
Maintain a curated, approved set of base images and enforce their use through policy, reducing the inherited vulnerability surface that all derived images carry.
Pair image scanning with secret detection checks to catch hardcoded credentials or tokens embedded during the build process, as these represent a distinct and high-severity risk class.
Treat scanner output as one input into a broader risk prioritization process: correlate CVE findings with reachability, exploitability ratings, and compensating controls rather than acting on raw scan counts alone.