Container Scanning

Container scans inspect every layer of a Docker image and report CVEs in OS packages (apt, apk) and application dependencies (pip, npm, gem, go modules). Scan a local image with the CLI, or connect a registry for automatic scanning on every push.

What’s scanned

Type	Examples
OS packages	`apt` (Debian/Ubuntu) and `apk` (Alpine) — the engine classifies these as OS packages and tags them as such.
Application dependencies	npm `node_modules`, Python `site-packages`, Go binaries, Ruby gems, Maven JARs, Composer packages.

The engine walks the image layer by layer, enumerates every package present at runtime, and matches each one against the OSV vulnerability database. Findings are tagged with the layer that introduced the package, so you can pinpoint whether an issue comes from your base image or your build.

OS packages from RHEL/CentOS, pacman, or zypper are scanned by osv-scanner if present, but Vygl currently only flags Debian/Ubuntu/Alpine entries with the is_os_package tag.

Scanning a local image

Use --image to scan a container image instead of a directory:

docker run --rm \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -e VYGL_API_KEY=vgl_your_key \
  vygl/vygl-cli scan --image myorg/myapp:1.2.3

--image forces --scan-types container. Mounting the Docker socket lets the CLI pull and inspect the image. For local-only runs, add --no-upload.

Scanning from a registry

Connecting a registry is the recommended approach for production workloads. See Connecting Registries for the supported registries.

What you’ll see

For each image, Vygl produces:

Severity counts — critical / high / medium / low across OS and app packages.
Layer attribution — which layer introduced each vulnerable package.
Base-layer flagging — layers attributed to the base image (using osv-scanner’s base_image_index heuristic) are flagged in the UI; CVEs concentrated there usually mean a base-image upgrade is the right fix.
AI risk summary — prioritized remediation written by your configured LLM (Anthropic, OpenAI, Bedrock, or OpenAI-compatible). See Container AI Analysis.
Source correlation — links to source-code dependencies that share a CVE with the container finding. See Source ↔ Container Correlation.

Finding metadata

Every container finding carries:

scan_type=CONTAINER
package_name, package_version, fixed_versions
metadata.image_ref — the image reference scanned.
metadata.pkg_type — package format (deb, apk, pypi, npm, …).
metadata.ecosystem — full OSV ecosystem string.
metadata.layer_index — index into the image’s layer list (numeric, not a digest).
metadata.is_os_package — boolean flag for OS-vs-app classification.
metadata.aliases — alternate CVE/advisory IDs.
metadata.advisory_url, metadata.urgency — when known.

The detected base OS lives on the scan record (metadata_.image_metadata.os — e.g. debian:12), not on individual findings.

These fields appear in the finding detail view and in API responses (GET /findings/{id}).