CVE reporting

Most of the CVEs a scanner reports against a container image are for packages your workload never actually loads. tracepod cve-report renders a reachability report: for every CVE a scanner finds in your image, whether the affected package was observed loading during the profiling window — so you triage the CVEs your workload exercises, not the hundreds it never touches.

It is a free-tier command and works against any sensor.

Note

cve-report requires the Tracepod controller to be deployed in your cluster — the CLI is a pure rendering client that port-forwards to the controller; all classification, matching, and scoring happen server-side. The controller is a separate component, not part of the open-source repository.

Usage

tracepod cve-report <workload|profile-id> [flags]

The argument is a numeric profiling-session ID, or a workload (deployment) name — a name resolves to the most recent profiling session for that deployment (use --namespace to disambiguate).

Flags

Flag	Default	Description
--findings <file>	—	Upload a Trivy or Grype JSON findings file and classify it, instead of triggering a server-side scan
--severity <level>	high	Minimum severity shown in the table: critical, high, medium, low, negligible, or all. Summary lines always cover all severities
--output <format>	table	table (human-readable) or json (the controller payload, byte-for-byte)
--verbose	false	Also show the coverage-score component breakdown and attribution evidence
--namespace <ns>	—	Namespace of the workload (ignored for a numeric profile ID)
--controller-namespace <ns>	tracepod	Namespace where the controller is deployed
--kubeconfig <path>	$KUBECONFIG or ~/.kube/config	Kubeconfig used to port-forward to the controller

Example

tracepod cve-report php-hello

Reachability report — acme-legacy/php-hello (profile 1)
  image  localhost:5000/tracepod-demo/php-hello@sha256:32afd47b…
  scan   grype 0.92.2 · server-side grype scan · generated 2026-01-02T00:00:01Z

759 findings: 132 loaded, 627 not loaded, 0 indeterminate, 0 unmatched
High+Critical — 97 findings: 35 loaded, 62 not loaded, 0 indeterminate, 0 unmatched

SEVERITY  CLASSIFICATION  CVE             PACKAGE      VERSION           EVIDENCE
Critical  loaded          CVE-2026-29167  apache2-bin  2.4.67-1~deb13u3  /usr/lib/apache2/modules/mod_authz_user.so (observed)
…

The headline is the two summary lines. The raw total (759) overstates the work — the honest number is the severity cut: of 97 High+Critical findings, only 35 were actually loaded. That is the queue worth triaging first. The table leads with that actionable slice by default; widen it with --severity all.

The four classifications

Classification	Meaning
loaded	The affected package was observed loading during the profiling window — a direct file access, a pyc-derived load, or a resolved ELF-closure dependency of something loaded
not_loaded	Present in the image but not observed loading during the window. Not proof of unreachability
indeterminate	The package’s ecosystem could not be resolved against the image inventory
unmatched	No package in the image inventory owns the scanner’s reported purl

What this does — and does not — claim

The reachability report is an observational result, bounded by the profiling window:

Reachability classifications are bounded by the profiling window. A package marked not_loaded was not observed loading during the window — this is not proof of unreachability.

Treat not_loaded as prioritization, not suppression — it tells you which CVEs to look at last, not which to ignore. The longer and more representative the profiling run, the more you can trust it; a 30-second smoke test is not an hour of real traffic. A lossy profiling window (nonzero event_loss) further weakens absence claims — see Known limitations.

Exporting not_loaded findings as signed VEX not_affected statements is a separate, paid (Pro) feature; the report itself is free.

Classifying an existing scan

If you already run Trivy or Grype in CI, upload the findings instead of scanning server-side:

tracepod cve-report php-hello --findings trivy.json

Other useful invocations:

# Everything, as JSON, piped to jq:
tracepod cve-report php-hello --severity all --output json | jq '.summary'

# Full coverage + attribution breakdown for a specific session:
tracepod cve-report 42 --verbose

Exit codes

Code	Meaning
0	Report fetched and rendered (or emitted as JSON)
1	Any error — bad flags, controller connection failure, a controller error response, or a schema-invalid response (which may indicate an outdated CLI)