CVE reporting

Most of the CVEs a scanner reports against a container image are for packages your workload never 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 can prioritize the CVEs your workload exercises.

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 [flags] <workload|profile-id>

Flags can come before or after the workload or profile ID (v0.2.5 and later); global flags such as --kubeconfig and --controller-namespace must come before cve-report. 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-url <url>	—	Controller base URL (e.g. http://localhost:8080); bypasses the in-cluster port-forward
--controller-namespace <ns>	tracepod	Global flag — namespace where the controller is deployed. Place it before cve-report: tracepod --controller-namespace <ns> cve-report ...
--kubeconfig <path>	$KUBECONFIG or ~/.kube/config	Global flag — kubeconfig used to port-forward to the controller. Place it before cve-report: tracepod --kubeconfig <path> cve-report ...

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 number that matters is the severity cut: of 97 High+Critical findings, only 35 were loaded. That is the queue to triage first. The table leads with that 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 report claims

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 covers far less than 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 --findings trivy.json php-hello

Other useful invocations:

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

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

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)