Evidence

Evidence is what you hand to a customer, an auditor, a regulator, or a downstream consumer. Anchore Enterprise turns the vulnerability and annotation data it already holds into three kinds of formal, standards-aligned documents:

Evidence is available at both app-version and image scope. A separate export lists every app version in the account that a vulnerability affects; see Export App Versions Affected by a Vulnerability.

For SBOM evidence (CycloneDX and SPDX SBOM exports of an app version’s contents), see Export an SBOM.

Evidence from an App Version

App-version evidence runs as an asynchronous job: submit the job, wait for completion, and the result is written to a file or stdout.

Via the Anchore Enterprise GUI

Open the app version detail page, click on the Download button, and choose the document type from the menu along with the desired format (where supported), and click Download. The My Recent Activity panel on the App Version Summary tab shows the job’s progress and, once complete, the link to download the generated document.

Via AnchoreCTL

Each evidence type has a dedicated subcommand under anchorectl app version export:

anchorectl app version export vex 1.4.0 \
  --app my-service \
  --format cyclonedx-json \
  --file my-service-1.4.0-vex.json

anchorectl app version export vdr 1.4.0 \
  --app my-service \
  --file my-service-1.4.0-vdr.json

anchorectl app version export vulnerabilities 1.4.0 \
  --app my-service \
  --file my-service-1.4.0-vulns.csv

Each command submits a job, waits for completion, and writes the resulting document to the path supplied with --file (or to stdout if --file is omitted).

Today the app-version VEX and VDR exports both produce CycloneDX JSON. The vulnerability data export, the raw finding rows surfaced by anchorectl app version export vulnerabilities, is CSV-only at app-version scope; VEX and VDR carry the same findings wrapped in their respective document forms.

The app-version vulnerability CSV ends with four columns added in v6.3.0: Fix State, EPSS Percentile, and CVSS Source and Is Primary, which identify where the row’s CVSS scores came from. New columns are added at the end, so tools that read columns by position are not affected.

App-version CSV exports (vulnerabilities, policy compliance, and packages alike) emit one row per result per asset, and every row identifies where it was found through Asset ID, Asset Name, Asset Class (SBOM or Image), and Asset Type columns. A finding that touches three assets therefore appears as three rows.

Via the API

App-version exports live under the App Jobs tag of the API:

The job lifecycle is: POST to submit, poll GET .../{job_id} until status is complete, then fetch download_id from the job’s response and GET /apps/{app_id}/downloads/{download_id}. The full request and response schemas are in the API browser; search for the App Jobs tag.

Evidence from an Image

Image-scoped evidence is synchronous: the document is generated on the fly when you request it. No job to track, no separate download step.

Via the Anchore Enterprise GUI

Open the image detail page, switch to the Vulnerabilities tab, and use the Download menu to pick a format. The document streams back to your browser when the request completes.

Via AnchoreCTL

anchorectl image vulnerabilities doubles as the image evidence command; the -o flag selects the output format:

anchorectl image vulnerabilities sha256:<digest> -o csv             > image-vulns.csv
anchorectl image vulnerabilities sha256:<digest> -o cyclonedx-json  > image-vulns.cdx.json
anchorectl image vulnerabilities sha256:<digest> -o html -d ~/reports/  # -d takes a directory; the HTML file is written into ~/reports/

Supported formats are text, json, json-raw, csv, cyclonedx-json, cyclonedx-xml, and html. The JSON and CSV outputs include each vulnerable package’s purl, matching the GUI’s Security Data Export from the image and source analysis vulnerabilities views. The CycloneDX outputs embed VEX annotations recorded on the image’s findings; HTML produces a human-readable summary document suitable as a build artifact.

Via the API

Image VEX exports support OpenVEX in addition to CycloneDX, which is useful for downstream consumers that have standardized on the OpenVEX format.

Export App Versions Affected by a Vulnerability

To answer “which of our releases does this vulnerability affect?” in a document you can hand on, export every app version in the account that is affected by a vulnerability to CSV. The export runs as an asynchronous job, like the other app-version exports, and is available through AnchoreCTL and the API from Anchore Enterprise v6.3.0. To answer the same question interactively, use the quick vulnerability search in the GUI.

The export takes one complete vulnerability ID. A GHSA advisory that maps to a single CVE is exported under that CVE; an advisory that maps to more than one CVE is rejected, so export each CVE instead.

Via AnchoreCTL

anchorectl app export apps-by-vulnerability takes a single vulnerability ID and produces a CSV report of every application version in your account that contains a package affected by that vulnerability. Unlike anchorectl app version export vulnerabilities, which lists every vulnerability in one app version, this command works in the other direction: it starts from one vulnerability and looks across all of your applications at once.

anchorectl app export apps-by-vulnerability VULNERABILITY_ID [flags]

When you run the command, AnchoreCTL:

1. Submits an export job to Anchore Enterprise for the vulnerability, with any filters and sort order you supplied.
2. Waits for the job to finish, polling for up to 30 minutes.
3. Downloads the finished CSV and writes it to the path supplied with --file (-f), or to stdout if --file is omitted.

Each row of the CSV is one affected package in one asset of one app version, so the report shows not only which releases are affected, but where in each release the vulnerable package sits, whether a fix version exists, and how the finding has been annotated. See CSV Columns for the full layout. App versions that the vulnerability does not affect do not appear in the report, and CSV is the only output format.

For example, to list every released app version affected by CVE-2025-1974, with a link from each row back to the GUI:

anchorectl app export apps-by-vulnerability CVE-2025-1974 \
  --status released \
  --ui-base-url https://anchore.example.com \
  --file cve-2025-1974-app-versions.csv

To find the affected versions that still need a decision, those without a fix and not yet annotated, sorted by application name:

anchorectl app export apps-by-vulnerability CVE-2025-1974 \
  --has-fix=false \
  --annotation-status none \
  --sort application.name --order ascending \
  --file cve-2025-1974-untriaged.csv

Without filters, the export covers every affected app version in the account. These flags narrow it. Flags that take a list accept comma-separated values and match any of them, and different flags combine, so a row must satisfy all of them.

--sort orders the rows by application.name, contact.effective_organization_name, app_version.name, app_version.status, app_version.created_at, app_version.release_date, has_fix, or affected_packages, and --order sets ascending or descending (the default). Without --sort, the newest app versions come first. --ui-base-url adds a column that links each row to the app version’s Vulnerabilities tab in the Anchore Enterprise GUI.

Via the API

The export uses account-level job and download endpoints, not the per-app endpoints under /apps/{app_id}:

The request body names the vulnerability, and optionally carries filters, sort, and ui_base_url:

curl -X POST \
  'https://my-anchore.example.com/v2/jobs/export-apps-by-vulnerability' \
  -H 'content-type: application/json' \
  -d '{
    "vulnerability_id": "CVE-2025-1974",
    "filters": [{"field": "app_version.status", "operator": "eq", "value": "released"}],
    "ui_base_url": "https://anchore.example.com"
  }'

Poll GET /jobs/export-apps-by-vulnerability/{job_id} until status is complete (the other values are pending, processing, failed, and cancelled), then GET /downloads/{download_id} with the download_id from the job’s completion_detail. The file is named apps-by-vulnerability-export-<download_id>.csv. The filter fields and their operators are listed under QuickSearchVulnFilterCondition in the API browser.

CSV Columns

The CSV has one row for each affected package in each asset of each app version, so a package in two assets of one version appears twice. Vulnerability and app version values repeat on every row they apply to.

Impacted Package VEX Status is none for a package with no VEX annotation. The export can filter and sort by the contact’s organization name, but the CSV has no organization column.

Where to Go Next

• Search — investigate vulnerabilities before producing the formal documents.
• Annotations — record the VEX dispositions that drive every VEX and VDR document.
• Export an SBOM — produce Syft-native, CycloneDX, or SPDX SBOMs for the components that the vulnerability evidence above sits alongside.