Container Image Scanning

Most of your CVE exposure lives in the base image

The OS packages baked into the image you build on carry the bulk of your container risk, and they keep changing as new advisories land against tags you already pinned. Pragma Core scans the base images declared in your Dockerfiles and any image you import from a registry, then tracks every CVE through a clear lifecycle with real severities.

Scan your images View all features

Two sources

Images find their way into the inventory two ways

Both sources funnel into one inventory and are scanned the same way, so a base image from a repo and an image pulled from a registry live side by side.

From your repositories

Enable container scanning on a repo and the platform refreshes the checkout, finds every Dockerfile and Containerfile, and reads the FROM lines to register the external base images you build on, such as python:3.8-slim. Stage aliases and scratch are skipped. The image is never built, only the declared bases are pulled and scanned.

From a registry

Add a container registry integration and import image references by pasting image and tag lines. A bare reference is prefixed with the registry host automatically, so org/app:1.2 on a GHCR integration becomes ghcr.io/org/app:1.2 and gets pulled with your stored credentials.

How it works

From an image reference to a tracked CVE

No local Docker daemon, no build step. The scanner pulls each image, reads its packages, and matches them against the vulnerability database.

Discover the images

For a repository source, the Dockerfile parser returns the distinct external base images. Registry images come straight from the references you imported. Everything lands in one inventory.

Pull and scan

Trivy pulls each image into a dedicated cache and scans it for vulnerabilities only, with no Docker daemon required. Registry pulls use the credentials stored on the integration.

Normalize the results

Each vulnerability becomes a row with the CVE, the affected package, the installed and fixed versions, the severity, and the CVSS score. Trivy emits real severities, so there is no guesswork and no platform-owned map.

Diff and track

Findings are diffed by fingerprint. New CVEs open, patched ones close, and a CVE that comes back reopens the same row. The per-image severity counts are recomputed at the end of every scan.

Live look

A snapshot of one workspace

Base images and registry imports both carry a tail of CVEs that grows as new advisories land. Here is what the dashboard collapses that into.

Vulnerabilities by image

Sample workspace

Active CVEs per image, broken down by severity. The slim and distroless bases carry far less than a full distribution image, which is exactly the kind of decision this view is meant to inform.

Top CVEs surfaced

Latest 5

Ranked by CVSS, with the package and the version that fixes each one. The fixed column tells you immediately whether a patch even exists yet, which is usually the first triage question.

CVE	Severity	Package	Fixed in
CVE-2023-44487	9.8	golang.org/x/net	0.17.0
CVE-2024-2961	8.1	glibc	2.36-9+deb12u7
CVE-2023-5678	7.5	openssl	3.0.13
CVE-2023-29491	6.5	ncurses	6.4-4
CVE-2024-0567	5.3	gnutls28	3.7.9-2+deb12u3

Capabilities

Container risk you can actually keep on top of

Base images and registry images

Scan the base images your Dockerfiles build on and the images you import from a registry, all in one inventory. Repository scanning focuses on the bases, which is where the bulk of OS-package CVE exposure actually lives.

No Docker daemon required

Images are pulled and scanned directly into a dedicated cache, with no Docker daemon to install or socket to expose. The scan runs as a plain subprocess with the vulnerability scanner only, nothing else.

Real CVSS, no severity map

The scanner emits genuine CVSS scores and severities straight from the vulnerability database. Unlike pipeline checks, there is no platform-owned classification to second-guess, so the numbers you see are the real ones.

Findings track over time

Each CVE is diffed by fingerprint. New ones open, patched ones drop out of the default view, and a CVE that returns reopens the same row without re-notifying. A base image no longer referenced anywhere has its active CVEs closed automatically.

Rolled into the supply chain view

Active container CVEs feed the workspace Supply Chain Security dashboard and the executive PDF, alongside your dependency findings. One rollup of severity breakdowns, most-vulnerable images, and the CVEs that need attention first.

Scanned every day

Repository and registry images are rescanned daily on a dedicated queue. A pinned tag picks up new CVEs as the advisory database grows even when the tag itself never changes, so a quiet image does not mean a safe one.

Supported registries

Pull from the registries you already use

Token and password registries are handled natively. Cloud registries that need per-provider credential helpers are on the roadmap.

Docker Hub GitHub Container Registry Quay Harbor GitLab Container Registry Generic OCI registries

Why it matters

A pinned tag is not a frozen risk

Choose a lighter base on evidence

Seeing the CVE count on a full distribution image next to a slim or distroless variant turns base-image choice from a habit into a measured decision. The per-image view makes the difference obvious.

Catch CVEs the day they publish

A tag you pinned months ago accumulates new vulnerabilities as advisories land. Daily rescans against the latest database surface them automatically, so you are not relying on an image rebuild to learn you are exposed.

Know if a fix even exists yet

Every finding shows the version that resolves it, or makes it clear when no fix is available. That distinction decides whether you upgrade today or apply a mitigation while you wait, and it is right there in the table.

One supply chain story for leadership

Container CVEs sit beside dependency findings in a single executive rollup. When leadership asks where the supply chain risk is, you have one dashboard and one PDF that answer it across libraries and images together.