Skip to main content

​
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.

Image-Level Scanning

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.

Per-Layer Attribution

Ties every vulnerability to the image layer that introduced it, so you can tell inherited base-image issues from ones your build added.

Continuous Monitoring

Re-scans monitored images on a schedule so newly disclosed CVEs surface without a manual re-run.

​
End-to-end Flow

1

Image Submitted

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.
2

Layer Extraction

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.
3

Package Inventory

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.
4

Vulnerability Matching

Inventoried packages are matched against vulnerability intelligence to identify known issues in OS packages and bundled dependencies.
5

Per-Layer Findings & Severity

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.
6

Base-Image Upgrade Guidance

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.
7

Results Delivered

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 three modes:
  • Image reference — enter an image reference (e.g. ghcr.io/acme/api:1.4), optionally provide private registry credentials (username + token), and optionally set a monitoring schedule (cron expression, UTC). If the registry host you type matches one of your org’s saved registry connections, the dialog will suggest switching to Connected registry mode so you can pull without re-entering credentials. You can also clear previously stored credentials for an image to revert it to an anonymous pull.
  • Connected registry — pick one of your organization’s registry connections, browse its repositories and tags (or enter an image path manually), and submit without re-entering credentials. This tab is only shown when your organization has at least one registry connection. You can also set a monitoring schedule in this mode.
  • Upload archive — upload a docker save tarball (.tar) for images that cannot be pulled from a registry. A progress bar tracks the upload.
In all modes you can optionally link the image to one of your code repositories. On success, the dialog navigates to the new image’s detail page.
The dialog cannot be closed while a submission is in flight. This prevents the form from being reset mid-upload. Once the scan is enqueued, the dialog closes automatically and navigates to the new image’s detail page.
Turning off the monitoring schedule checkbox in the dialog does not disable an existing monitoring schedule on an image you are re-submitting — it simply leaves the existing schedule unchanged. To disable monitoring for an image, use the Settings tab on that 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.

​
Repository Deletion

When a repository is deleted from ZeroPath, its associated container images are automatically detached from their registry connections and their monitoring schedules are stopped. The images themselves are not deleted — they remain in ZeroPath’s records but will no longer re-scan automatically or authenticate with the saved registry connection. You can re-link or delete them manually from the Images list.

​
Connect a Registry

For private registries, you can save an organization-level registry connection once instead of passing inline credentials with every submit. Connections are created under Settings → Integrations → Registries — in the Manage Registries dialog’s Container registries section: pick a provider, enter its credentials, and ZeroPath validates them against the registry before saving. (The same dialog also manages private package registries for dependency analysis.) Any scan of an image in that registry — one-shot, monitored re-scan, or API submission — can then authenticate with the stored connection. Credentials are stored encrypted and tokens are never returned by any API. Use read-only scopes wherever the provider supports them; each provider’s requirements are listed below.
Your username, a read-only access token (Docker Hub → Account Settings → Personal access tokens), and the namespace to browse (defaults to the username).Docker Hub rate-limits image pulls — the free tier allows authenticated users 200 pulls per 6 hours. Every scan pulls the image, so keep monitoring schedules across many Docker Hub images coarse enough to stay under the limit. A rate-limited pull surfaces as a failed scan carrying the registry’s rate-limit message.
The GitHub username that owns the token, the organization or user whose packages you want to browse, and a classic personal access token with the read:packages scope. The token must be a classic PAT — GitHub does not support fine-grained PATs for ghcr.io.
Your AWS account ID, the registry’s region, and an access key ID / secret access key pair. Use a least-privilege IAM user with the AmazonEC2ContainerRegistryReadOnly managed policy — ZeroPath only needs to list and pull images. The keys are exchanged for short-lived ECR authorization tokens at scan time.
The registry host ({location}-docker.pkg.dev, e.g. us-central1-docker.pkg.dev), the GCP project ID, and a service account JSON key granted roles/artifactregistry.reader. The key is exchanged for short-lived access tokens at scan time.
The login server (myregistry.azurecr.io) plus either a repository-scoped token (token name as the username, token password as the password) or a service principal (application ID as the username, client secret as the password) with pull access.
The base host (e.g. mycorp.jfrog.io), a username, and an identity token. Pulling and scanning work on all editions; browsing repositories from the scan dialog uses Artifactory’s repository-listing API, which requires Artifactory Pro.
Any other registry that speaks the OCI Distribution API — Harbor, Quay, GitLab’s registry, a self-hosted registry:2, and so on: the registry host, a username, and a token or password. Browsing repositories requires the registry to support the /v2/_catalog endpoint; without it you can still scan by entering an image reference, and the connection’s credentials are still used for the pull.
The registry must be reachable from ZeroPath over the public internet. Hosts that resolve to private IP addresses — registries inside your VPC or behind a firewall ZeroPath cannot traverse — are rejected when the connection is created and again at every scan when credentials are resolved. This two-stage check protects against DNS rebinding: even if the registry host’s DNS answer changes to a private address after the connection is saved, the scan is blocked before any credentials are used.

​
Scanning with a connection

Once a registry is connected, the Scan image dialog gains a Connected registry mode: pick the connection, browse its repositories and tags, and submit — no credentials re-entered. API and CLI submissions reference the connection by ID instead of carrying inline credentials:
registryConnectionId is mutually exclusive with inline registryUsername/registryToken, and the image reference’s host must match the connection’s registry host.

​
Registry connection in API responses

When you fetch a container image via the API, the response includes a registryConnection field that identifies the org-level registry connection associated with the image. When the image uses a saved connection, this field contains the connection’s id and displayName; when the image uses inline credentials or pulls anonymously, it is null. The hasRegistryAuth flag remains true whenever either a saved connection or inline credentials are present, so existing consumers that check only the flag continue to work without changes.

​
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.
The scan pulls the referenced image, inventories its OS packages and bundled dependencies, and returns per-layer findings with base-image upgrade guidance.

​
Key Capabilities

OS Package Coverage

Detects known vulnerabilities in the system packages installed in your base image and build steps.

Bundled Dependency Detection

Finds vulnerable application dependencies copied or installed into the image during the build — including packages that never appear in your source manifests.

Per-Layer Attribution

Every vulnerability is tied to the layer that introduced it, distinguishing inherited base-image issues from ones your build added.

Base-Image Upgrade Recommendations

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.

Private Registry Support

Scans images in private registries using inline credentials or a saved org-level registry connection (Docker Hub, GHCR, ECR, GAR, ACR, Artifactory, or any OCI registry). Credentials are sent over TLS and stored encrypted.

Local Archive Upload

Scans air-gapped images that cannot be pulled by uploading a docker save archive directly, with no registry access required.

Scheduled Monitoring

Re-scans monitored images on a recurring schedule so newly disclosed CVEs surface automatically.

Unified Supply Chain View

Image-level findings appear under the same Supply Chain section as dependency analysis, giving you the complete picture of what ships in production.

Archive Upload via API

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

1

Identify the Images You Ship

List the built images that run in production — these are the artifacts Container Scanning analyzes by registry reference.
2

Run a One-Shot Scan

Use zeropath container test <image> to get an immediate snapshot of an image’s vulnerabilities.
3

Review Per-Layer Findings

Inspect findings under the Supply Chain section, using layer attribution to separate inherited base-image issues from ones your build introduced.
4

Apply Base-Image Upgrade Recommendations

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.
5

Enable Monitoring

Register production images with zeropath container monitor <image> so newly disclosed CVEs surface automatically on a schedule.