> ## Documentation Index > Fetch the complete documentation index at: https://zeropath.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Container Scanning > Scan built container images for OS-package and bundled-dependency vulnerabilities, with per-layer findings and base-image upgrade guidance. ## How It Works ZeroPath Container Scanning analyzes the container images you actually ship. Instead of inspecting only the source a repository builds from, it examines a built image — pulled by its registry reference or uploaded as a local archive — looking at the operating system and everything bundled on top of it for known vulnerabilities. Public images, private registries (with credentials), and air-gapped images shared as a `docker save` archive are all supported. Findings are surfaced under the existing **Supply Chain** section, alongside dependency analysis, so image-level and source-level risk live in one place. Scans a built image — pulled by registry reference, including private registries with credentials, or uploaded as a local archive — and analyzes OS packages and bundled dependencies baked into it, not just the source it was built from. Ties every vulnerability to the image layer that introduced it, so you can tell inherited base-image issues from ones your build added. Re-scans monitored images on a schedule so newly disclosed CVEs surface without a manual re-run. ## End-to-end Flow You point ZeroPath at a built image. ZeroPath either resolves a registry reference and pulls the image — authenticating with the registry credentials you provide for private registries — or reads a local image archive you upload for air-gapped images that cannot be pulled. The image is unpacked layer by layer. ZeroPath records which layer contributes each file so findings can later be attributed to the layer that introduced them. ZeroPath inventories the operating-system packages and the application dependencies bundled into the image, building a complete picture of everything that ships inside it — including packages that never appear in your source manifests. Inventoried packages are matched against vulnerability intelligence to identify known issues in OS packages and bundled dependencies. Each finding is attributed to the layer that introduced it and is severity-rated (Critical / High / Medium / Low), so you can immediately see whether an issue came from your base image or your own build steps. ZeroPath detects the image's base and, when a newer stable base of the same distribution exists, scans that candidate and recommends it — reporting how many of the current findings the upgrade would remove, so you can fix the most vulnerabilities with the fewest changes. Findings are surfaced under the Supply Chain section in your dashboard, API, and integrations. Container scan findings also appear in the main Issues list alongside SAST and SCA results, giving you a unified view of all security findings across your organization. Monitored images are re-evaluated on their schedule as new vulnerabilities are disclosed. ## Container Images Dashboard The Containers section is organized into two pages: a **Dashboard** overview and an **Images** list. ### Dashboard The Dashboard provides an at-a-glance overview of all tracked container images across your organization, including: * **Image counts** — total tracked images, how many are monitored on a schedule, how many are currently scanning, and how many have a failed latest scan. * **Findings by severity** — a breakdown of total findings across every image's latest scan, bucketed by Critical, High, Medium, Low, and Informational. * **Base-image upgrade opportunities** — images where a newer base of the same distribution would remove findings, ranked by the number of findings the upgrade resolves. * **Most-vulnerable images** — a ranked list of the images with the highest finding counts. ### Images List The Images page lists all tracked container images with search, filtering, and pagination. Images are grouped by repository so you can see at a glance which images belong to which project; standalone images (not linked to a repository) collect under their own group. You can submit new images for scanning directly from this page using the **Scan image** button, which opens a dialog with two modes: * **Registry image** — enter an image reference (e.g. `ghcr.io/acme/api:1.4`), optionally provide private registry credentials, and optionally set a monitoring schedule (cron expression, UTC). * **Upload archive** — upload a `docker save` tarball (`.tar`) for images that cannot be pulled from a registry. A progress bar tracks the upload. In both modes you can optionally attach the image to one of your repositories. On success, the dialog navigates to the new image's detail page. ### Image Detail Clicking an image opens a detail page with three tabs: * **Overview** — severity histogram (Critical / High / Medium / Low), fixable and resolved counts, base-image upgrade recommendation (when available), image metadata (digest, size, build date, findings count, detected base image), and a layer breakdown showing which layers are base-image layers and which are application layers. * **Vulnerabilities** — a searchable, filterable list of every CVE found in the image's latest scan. You can search by CVE ID or package name, and filter by severity (Critical, High), fixable status, or open status. Clicking a CVE opens the full issue detail with the same triage workflow used across the rest of ZeroPath (status changes, patching, Jira export, etc.). Deep links to individual findings are shareable via the URL. * **Settings** — configure a monitoring schedule (cron expression, UTC) for registry images, and link or relink the image to a repository in your organization. From the detail page you can also: * **Re-scan now** — pull and re-scan a registry image immediately. (Uploaded archives cannot be re-scanned because the original tarball is not retained.) * **Delete** — permanently remove the tracked image and all of its scan history. When a scan fails, a failure banner is displayed with guidance to retry. When an image is queued but not yet scanned, the page shows a placeholder until results are available. ## Managing Container Images From the dashboard or the API, you can: * **List images** with search and cursor-based pagination, optionally filtered by repository. * **View image details** including the latest scan summary, queue status, and monitoring schedule. * **Enable monitoring** with a cron schedule so the image is re-scanned on a recurring basis. * **Disable monitoring** to return to scan-on-submit only. * **Link to a repository** to reassign an image from one repository to another (both must be in your organization and accessible to you). * **Delete an image** to stop tracking it entirely and remove all of its scan history. ## Running Scans Run a single scan of a built image to get an immediate snapshot of its vulnerabilities. This is the right choice for ad-hoc checks, CI/CD gates on a freshly built image, or evaluating an image before you promote it. ```bash theme={null} zeropath container test ``` The scan pulls the referenced image, inventories its OS packages and bundled dependencies, and returns per-layer findings with base-image upgrade guidance. To scan an image hosted in a private registry, pass registry credentials and ZeroPath authenticates when pulling the image. Credentials are transmitted over TLS and stored encrypted. ```bash theme={null} zeropath container test \ --registry-username \ --registry-token ``` Use a registry access token or robot/service-account token rather than a personal password where your registry supports it. For images that cannot be pulled — air-gapped environments, or images that never leave a build host — export the image to a tarball with `docker save` and upload that archive directly. No registry access is required. ```bash theme={null} # Export the built image to a tarball docker save -o image.tar # Scan the uploaded archive, giving it a label to identify it in results zeropath container test --file image.tar --name Register an image for recurring re-scans so it is continuously checked against the latest vulnerability intelligence. An image that is clean today can become vulnerable the moment a new CVE is disclosed — monitoring surfaces those issues without a manual re-run. ```bash theme={null} # Monitor an image on the default schedule zeropath container monitor # Monitor an image on a custom schedule (crontab expression) zeropath container monitor --schedule "0 6 * * *" ``` Monitored images keep their base-image upgrade guidance current, so you always know the single change that resolves the most findings in your running images. ## Key Capabilities Detects known vulnerabilities in the system packages installed in your base image and build steps. Finds vulnerable application dependencies copied or installed into the image during the build — including packages that never appear in your source manifests. Every vulnerability is tied to the layer that introduced it, distinguishing inherited base-image issues from ones your build added. Detects the image's base and, when a newer stable base of the same distribution exists, scans that candidate and reports how many findings the upgrade would remove — so a single change can clear many issues at once. Scans images in private registries using the registry credentials you provide. Credentials are sent over TLS and stored encrypted. Scans air-gapped images that cannot be pulled by uploading a `docker save` archive directly, with no registry access required. Re-scans monitored images on a recurring schedule so newly disclosed CVEs surface automatically. Image-level findings appear under the same Supply Chain section as dependency analysis, giving you the complete picture of what ships in production. Upload a container image tarball through the API in chunks for air-gapped environments where registry access is not available. The chunked upload flow handles large archives reliably. ## Adoption Checklist List the built images that run in production — these are the artifacts Container Scanning analyzes by registry reference. Use `zeropath container test ` to get an immediate snapshot of an image's vulnerabilities. Inspect findings under the Supply Chain section, using layer attribution to separate inherited base-image issues from ones your build introduced. When ZeroPath recommends a newer base, review how many findings the upgrade would remove and adopt it to clear the largest share of findings with a single change. Register production images with `zeropath container monitor ` so newly disclosed CVEs surface automatically on a schedule.