`vulkro container`

Pro

vulkro container is part of Pro: Container scanning (container), scan the image the service ships in. On Free it stops before doing any work, prints what it needs and where to get it, and exits 1. See Pricing.

Trivy-lite - scan a built container image's installed packages against the local CVE bundle. Supports apk + deb (rpm coming soon).

Usage

vulkro container <IMAGE> [--format FMT] [--save]

Arguments

Argument	Description
`IMAGE`	Either a Docker reference (e.g. `alpine:3.19`) or a path to a `.tar` produced by `docker save`.

Flags

Flag	Description	Default
`--format <FMT>`	Same format set as `vulkro scan`.	`table`
`--save`	Persist the scan to history. Off by default - container scans are usually one-shot CI checks.	(false)

How it works

When given a Docker reference, Vulkro shells out to the local docker save to materialise the image as a tar, then walks the layers for installed package metadata:

/lib/apk/db/installed for Alpine (apk).
/var/lib/dpkg/status for Debian / Ubuntu (deb).

Packages are matched against the CVE bundle the same way vulkro scan matches package.json / requirements.txt / Cargo.lock. KEV / EPSS decoration applies.

Air-gap

If docker is missing, pre-save the tar elsewhere:

docker save alpine:3.19 -o alpine.tar
vulkro container ./alpine.tar

Command reference

Generated from vulkro help container on vulkro 0.26.0. This block is the authoritative flag, usage, and exit-code reference for this command; the prose above is the friendly explanation. Do not edit this block by hand; run npm run docs:cli after a release.

[Pro] Check the packages inside a built container image against vulnerability data.

[Pro] Scan a built container image's installed packages against the local vulnerability data: OS package databases plus an application-layer SBOM.

`<image>` is either a docker reference (e.g. `alpine:3.19`) or a path to a `.tar` produced by `docker save`. When a reference is given, Vulkro invokes the local `docker` command; if `docker` is missing it exits with a hint to pre-save the tar elsewhere.

Coverage: - OS packages: apk + dpkg databases; rpm via the system `rpm` CLI. - App layer: Java jars (`META-INF/MANIFEST.MF` / `pom.properties`), npm `node_modules` packages, and Python `*.dist-info` / `*.egg-info` metadata, matched against the Maven / npm / PyPI CVE caches. - OCI whiteout (`.wh.<name>`) and opaque-dir (`.wh..wh..opq`) markers are honoured, so a package deleted in a later layer is not reported. Nested / fat jars are not recursed into in this version.

Offline: the scan reads only the image tar and `~/.vulkro/data/cves/*.json`, and never pulls from a registry. The image contents, the package inventory, and the findings never leave the machine. Like every scanning subcommand this one passes the license gate, which can fire the anonymous usage heartbeat (at most once per 24h, on a background thread); `VULKRO_OFFLINE=1` silences it.

Exit codes: 0 = no findings, 1 = findings reported, 2 = error.

Usage: vulkro container [OPTIONS] <IMAGE>

Arguments:
  <IMAGE>
          Image reference (e.g. `alpine:3.19`) or path to a `.tar` saved image

Options:
  -f, --format <FORMAT>
          Output format. Same set as `vulkro scan`

          Possible values:
          - table
          - json
          - sarif
          - gh-pr
          - gh-pr-inline-comments: GitHub PR per-finding **inline review comments**. NDJSON, one `{path, line, side, severity, rule_id, fingerprint, body}` object per line. Designed to be piped straight to a `gh api` loop so `vulkro gate` can drop comments next to the offending line on the Files Changed tab without going through a GitHub App. See the GitHub CLI integration guide at vulkro.com/docs
          - github-annotations:    GitHub Actions / GitLab CI **PR annotations**. One workflow-command line per finding (`::error file=...,line=...,endLine=...,title=<rule id>::<message> (<helpUri>)`). Printed straight to a CI job's stdout, GitHub turns each line into an inline annotation pinned to `file:line` on the Files Changed tab; GitLab CI's annotation parser reads the same grammar. When run against a baseline (`--gate-vs` / a `gate` flow) only NEW findings are annotated so a first run does not paper the PR
          - gitlab-mr:             GitLab Merge-Request comment: GitLab-flavored Markdown with collapsible blocks
          - bitbucket-pr:          Bitbucket Pull-Request comment: flat Markdown (Bitbucket does not render `<details>`)
          - azure-pr:              Azure DevOps Pull-Request comment: flat Markdown (shared with Bitbucket)
          - junit
          - csv
          - cyclonedx:             CycloneDX 1.6 JSON SBOM (uses `ScanResult.packages`)
          - cyclonedx-1.7:         CycloneDX 1.7 JSON SBOM. Same component shape as `cyclonedx`; emits the newer `specVersion`. Offered alongside 1.6 (which stays default)
          - spdx:                  SPDX 2.3 JSON SBOM
          - spdx3:                 SPDX 3.0.1 JSON-LD SBOM (`@context` + `@graph` of typed elements). Offered alongside SPDX 2.3, which stays the default for `--format spdx`
          - cbom:                  CycloneDX 1.6 CBOM (Cryptographic Bill of Materials): one `cryptographic-asset` component per detected weak algorithm (MD5, SHA-1, ECB, RC4, DES, static IV, insecure RNG), with file:line occurrences inlined under `evidence.occurrences`. Compliance buyers (FedRAMP, post-quantum readiness reviews) ask for this as a distinct artefact from the library SBOM
          - openvex:               OpenVEX 0.2.0 exploitability statements for each dependency CVE (`affected` / `not_affected` / `under_investigation`), with `not_affected` backed by reachability analysis. Pairs with an SBOM
          - cyclonedx-vex:         CycloneDX 1.6 VEX: the same exploitability verdicts as `openvex`, in a CycloneDX `vulnerabilities[].analysis` document
          - cbom-1.7:              CycloneDX 1.7 CBOM. Same crypto-asset grouping as `cbom` plus a richer post-quantum descriptor. Offered alongside 1.6 (default)
          - pdf:                   PDF render of the executive HTML report (requires `wkhtmltopdf` on PATH)
          - ropa-md:               GDPR Article 30 Records-of-Processing template - Markdown
          - ropa-html:             GDPR Article 30 Records-of-Processing template - HTML
          - ndjson:                Newline-delimited JSON: one finding per line plus a trailing summary line. Designed for SIEM ingestion and `jq` filter pipelines
          - evidence-graph:        Evidence-graph JSON (`evidence-graph/1.0`): a stable, versioned, AI-consumable document that composes endpoints, taint source -> sink flows, reachability verdicts, findings, and the dependency SBOM into one graph. Meant to be handed to an external AI agent as deterministic ground truth (Vulkro embeds no model; the agent brings its own). Pairs with `vulkro aggregate` for cross-repo linking. See `docs/ai-tool/`
          
          [default: table]

      --offline
          Hard-disable every outbound network call for this run (sets VULKRO_OFFLINE=1). Blocks the CVE feed, the license heartbeat, the update check, webhooks, and any cloud AI endpoint; a loopback model (http://127.0.0.1, http://localhost) is still allowed. Equivalent to exporting VULKRO_OFFLINE=1, and the flag wins when both are set

      --save
          Persist the scan to history (mirrors `vulkro scan --save`). Off by default - container scans are usually one-shot CI checks

  -h, --help
          Print help (see a summary with '-h')

Usage​

Arguments​

Flags​

How it works​

Air-gap​

Related​

Command reference​