What is container scanning?

Your code analysis checks the code you write. Your dependency analysis checks the packages you import. Neither one sees the operating system packages, language runtimes, and shared libraries that get built into the container image you actually ship. That layer runs in production, and it carries its own vulnerabilities.

This page explains what container scanning is, how it works step by step, what it finds, how it differs from the adjacent scans you already run, and where it fits in a CI/CD pipeline. It is written for developers who build and ship images, and for the security and engineering leaders accountable for what reaches production.

What is container scanning?

Container scanning is the automated inspection of a container image to identify known vulnerabilities and malicious packages in its operating system packages, language runtimes, and application libraries. It analyzes the full contents of an image, layer by layer, and matches each component against vulnerability databases and vendor security advisories.

A container image is a packaged, layered filesystem that bundles your application together with everything it needs to run: a base operating system, system packages, a language runtime, and third-party libraries. Most of those components come from a base image you did not write and do not track in your source repository. Container scanning reads that assembled filesystem, produces an inventory of what is inside it, and reports the components with known security issues.

The scanner reads an image and tells you which of its parts carry a published vulnerability or match a known malicious package, so you can fix or replace them before the image runs.

Why does container scanning matter?

The image layer is a blind spot that your other scans structurally cannot cover. A vulnerability in the PHP runtime or in a system certificate library or your declared dependencies, so code analysis and dependency analysis will not flag it. Without image scanning, that exposure ships to production undetected.

The stakes are rising because supply chain risk is now a primary attack surface. Software Supply Chain Failures ranks number three in the OWASP Top 10 2025, a reflection of how often attackers target the components teams assemble rather than the code they author. The timing gap makes it worse: the median time to patch a known exploited vulnerability is 43 days (451 Research), which is a long window when the vulnerable component is already running in your production images.

Scanning closes that gap in two directions. It catches a known-vulnerable or malicious component before the image ships, and it re-checks images you have already shipped as new vulnerabilities are published, so a component that was clean at build time does not quietly become an exposure you never revisit.

How does container scanning work?

Container scanning follows a consistent sequence, whether you run it on your laptop or inside a CI/CD pipeline.

1. Select the image. You point the scanner at a built image, identified by its name and tag. Scanning runs against the assembled image, so it reflects exactly what will ship, not what a manifest claims should be inside.
2. Build an inventory. The scanner reads the image layer by layer and generates a software bill of materials, an SBOM: a structured list of every operating system package, runtime, and library it finds, with versions.
3. Match against known risks. Each component in the inventory is checked against vulnerability databases, vendor security advisories from the base operating system distribution, and malicious package data. A match produces a finding tied to a specific component and version.
4. Report and prioritize. Findings are returned with a severity, so the most serious exposures surface first. This output is what a developer acts on and what a pipeline reads to decide whether to proceed.
5. Gate the result. The scan returns a pass or fail based on a severity threshold you set (in SonarQube, high by default). A failing result can stop a pipeline before the image is pushed or deployed.
6. Re-check over time. Because the inventory persists, the same image can be re-evaluated as new vulnerabilities are published, without rebuilding or re-scanning it.

The SBOM is the pivot. Once the scanner knows exactly what is in an image, matching that inventory against current vulnerability data is what turns a static image into a living risk inventory.

What does container scanning find?

Container scanning covers the components that get assembled into an image, most of which never appear in your source repository.

• Operating system packages. The system libraries and utilities that come from the base image distribution, such as OpenSSL or a certificate trust store. These are tracked through vendor security advisories published by the distribution.
• Language runtimes. The interpreter or runtime your application executes on, such as the PHP or Python runtime installed in the image. A flaw here affects every application running on that runtime, independent of your code.
• Application libraries. Third-party libraries present in the image filesystem, including ones pulled in as part of the base image rather than declared in your project manifest.
• Malicious packages. Components that match known malicious or compromised package data, rather than merely carrying a published vulnerability.

What image scanning does not cover is as important as what it does. Container scanning focuses on known, published exposure in the components inside an image. It does not observe how a container behaves at runtime. Dockerfile misconfiguration and secrets in images are separate checks, and not every tool combines them with vulnerability scanning.

How does container scanning differ from adjacent scans?

Container scanning sits next to several scans that sound similar and solve different problems. Each one inspects a different artifact at a different point in the lifecycle. Confusing them leaves gaps.

Container scanning vs. software composition analysis on source dependencies

Software composition analysis, or SCA, reads the dependencies your project declares: the packages listed in your manifests and lockfiles, including their transitive dependencies. Container scanning reads the components actually present in the built image filesystem, including the operating system packages and runtime that no manifest declares. SCA tells you about the libraries your code imports. Container scanning tells you about everything your image carries, declared or not.

Container scanning vs. infrastructure-as-code and Dockerfile checks

Infrastructure-as-code and Dockerfile analysis inspect configuration instructions: the Dockerfile that builds the image, or the deployment definitions that run it. These checks catch misconfiguration, such as running as root or exposing a port, before anything is built. Container scanning inspects the result, the assembled image itself, for vulnerable and malicious components. One checks the recipe; the other checks the finished dish.

Pipeline scanning vs. registry scanning

Registry-based scanning analyzes images after they have been pushed to a container registry, inspecting what is already stored centrally. Container scanning on Pipelines can run earlier, against an image available locally or in a pipeline, before it is pushed anywhere. The practical difference is timing: Scanning in the pipeline lets you stop a risky image before it enters the registry; scanning the registry covers images that are already stored. The two are complementary.

Container scanning vs. runtime security

Runtime security monitors a running container, watching live behavior for anomalous processes, network activity, or privilege escalation. Container scanning is static: it inspects an image before or without executing it, identifying known vulnerabilities in its components. One watches what a container does; the other examines what a container contains.

Key distinction

The single clarifying question is which artifact gets inspected and when. Container scanning examines the assembled image, before it runs, for known-vulnerable and malicious components across every layer. Dependency analysis examines declared source dependencies, configuration checks examine build instructions, and runtime security examines live behavior. They are complementary layers, not substitutes, and a thorough software supply chain practice uses them together.

Where does container scanning fit in a CI/CD pipeline?

Container scanning belongs at the point where the image is built and before it is promoted. The natural sequence is to build the image, scan it, and let the scan result gate what happens next.

Placed there, the scan acts as a checkpoint. When it finds risks at or above a severity threshold you set, it returns a failing result, and the pipeline stops before the image is pushed to a registry or deployed. A passing scan lets the image continue. This is the same gating logic teams already apply to tests and code analysis, extended to the image.

Software developers get the same checkpoint earlier, running the scanner locally against an image before they push a change. The result is one standard applied consistently, from a developer’s machine through the CI build, so a risky image is caught where it is cheapest to fix rather than after it ships.

The checkpoint does not expire when the build finishes. Because the scan produces a durable inventory of each image, that inventory is re-evaluated as new vulnerabilities are published, turning a one-time build gate into continuous coverage of what you already shipped.

Best practices for container scanning

• Scan before you push. Run the scan against the built image in your pipeline before it reaches a registry, so a vulnerable image is stopped at the gate rather than caught after it is stored and pulled.
• Gate on a severity threshold you can defend. Set the fail threshold to a severity your team will act on. A gate that blocks on everything gets disabled; a gate that blocks on nothing is theater.
• Start from minimal, well-maintained base images. Many image vulnerabilities come from the base, so a smaller base with fewer packages and an active security advisory stream gives the scanner less to flag and you less to patch.
• Re-check shipped images, do not just scan at build. New vulnerabilities are published daily against components already in production. Treat the image inventory as something that gets re-evaluated, not a one-time check.
• Put image findings in the same triage workflow that developers use. A separate console for image risk produces a second backlog nobody reconciles. Image risk that lands next to code and dependency risk gets triaged with everything else.
• Rebuild on a patched base rather than patching in place. When a base operating system package is vulnerable, the durable fix is a rebuild on an updated base image, then a re-scan to confirm the risk is gone.

How can SonarQube help you scan container images?

SonarQube container scanning inspects the container images you build and ship for known vulnerabilities and malicious packages, across the operating system packages, runtimes, and libraries inside them. It is a capability included with SonarQube Advanced Security, which brings image risk into the same workflow you already use for your code and your dependencies, so there is no second tool and no second set of findings to reconcile.

You download the Sonar container scanner for Linux, macOS, or Windows and run it from the command line against an image, locally or in CI. The image must already be available locally, for example after docker build or docker pull, and the scanner accepts an image reference, a local .tar archive, or an OCI layout directory. The scanner generates an SBOM for the image and sends it to SonarQube Cloud, which checks the components for known vulnerabilities and malicious packages.

Results appear in the scanner output and under Container images in SonarQube Cloud, where you manage them with the same workflow you use for dependency risks. By default the scanner exits with a failing code at high severity or above so your pipeline can stop a risky image, and you can change that threshold with the --fail-on option. SonarQube Cloud re-checks analyzed images for newly published vulnerabilities, based on your organization’s re-analysis settings, so you do not need to re-scan an image to learn about new risks. After an image changes, run the scanner again to refresh its results.

Vulnerability tracking covers images based on Red Hat Enterprise Linux, Debian 11 and higher, Rocky Linux, AlmaLinux, Ubuntu, and Alpine, including vendor security advisories from those distributions. Images built on these, such as official Node.js images on Debian or Alpine, are covered as well. During the beta, container scanning analyzes two types of risk, known vulnerabilities and malicious packages. License risks and license policy are not available for container images, and container scanning does not observe runtime behavior.

Container scanning is in open beta on SonarQube Cloud, for organizations with SonarQube Advanced Security on the Team or Enterprise plan, at no additional cost. SonarQube Server support is planned and not yet available. The SBOMs and reports in SonarQube Advanced Security support the evidence requirements that frameworks such as the CRA, NIST SSDF, and SOC 2 ask for. To get started, run your first scan on an image you already build.

Next steps

• SonarQube Advanced Security—see how dependency scanning, malicious package detection, and container scanning work together as one supply chain security layer.
• Container scanning documentation—the reference for installing the scanner, setting options, and viewing results.
• Container scanning open beta announcement—the release details and supported base images.
• SBOM and software supply chain security—a learn page on software bills of materials and how they support evidence requirements