Reporting

1 - Search

Search answers questions that span more than one asset in your catalog: “Which application versions are affected by a specific CVE?”, “Which application versions contain a specific package?”, “Which images have a Critical finding with a known KEV?”, “Which images contain a vulnerable version of a specific package?”

Anchore Enterprise runs search at two scopes: applications and container images. Pick the one that matches how your team organizes software. Image search is available in the GUI and the API. Application search runs in the GUI’s Quick Search, by vulnerability ID or by package, and is backed by an experimental API.

For producing formal documents such as VEX, VDR, SBOMs, and vulnerability data exports, see Evidence. Evidence exports are available at both image and app-version scopes today.

Search Applications

The application scope answers “is this vulnerability affecting any of my applications, and which versions?” It also answers “which of my applications contain this package?”, which helps when a vulnerability is announced before it reaches a vulnerability feed. It draws on the same aggregated, deduplicated vulnerability data described in Scan an App Version, so a match points you straight at the affected app version.

Search Applications in the Anchore Enterprise GUI

Click Search… in the top navigation bar, or press Ctrl+K (Cmd+K on Mac) from anywhere in the GUI, to open Quick Search. Quick Search has two search types, Vulnerability and Package. Choose one from the menu in the search box, or press Tab to switch between them. Quick Search remembers the type you used last.

Search by Vulnerability ID

Choose Vulnerability and enter a full CVE or GHSA identifier.

Anchore Enterprise returns the application versions in your account whose aggregated findings include that vulnerability. Open a result to jump to the affected version’s Vulnerabilities tab, triage by Anchore Score, and pivot to the impacted assets.

Search by Package

Choose Package and enter a package name, name@version, or PURL, for example log4j-core, [email protected], or pkg:maven/org.apache.logging.log4j/[email protected]. The search is not case-sensitive and matches any part of a package’s identifier: its PURL, or name@version for a package without a PURL. A name on its own therefore finds every version of that package. Qualifiers in a pasted PURL, from the first ? or # onwards, are ignored.

Quick Search lists the matching packages with their PURLs. Select a package to open its results page, or choose Show all matches to open a results page for every matching package. If your query names exactly one package in full, Quick Search opens its results page straight away.

The results page lists the Associated Application Versions: every app version with an asset that contains the package. Each row shows the application and version name, with the version’s description if it has one, its status, contact, creation and release dates, and the number of assets that contain the package. When the search matched more than one package, the last column counts the matched packages in each version instead, and a Packages by Ecosystem chart above the list breaks the matches down by ecosystem. Filter the list by application name, version name, contact name or email, status, release date, or count. Open a version to go to its Contents tab, filtered to the matching packages.

Check a Known App Version with AnchoreCTL

AnchoreCTL has no search command. To list every app version that a vulnerability affects, export them with anchorectl app export apps-by-vulnerability; see Export App Versions Affected by a Vulnerability. To check whether a CVE affects a version you already know, list its vulnerabilities and filter for the identifier:

anchorectl app version vuln list 1.4.0 --app my-service

Add -o json for the full per-finding record, including CVSS, EPSS, and CISA KEV flags; findings are aggregated and deduplicated across the version’s assets rather than attributed to individual ones. See Scan an App Version for the complete command reference.

Search Applications with the API

The APIs behind Quick Search are experimental: they are served under the /exp prefix and may change between releases.

Each path takes POST for the first page of results and GET for each page after it:

1. POST the request. For vulnerabilities-search and apps-by-package, send a JSON body; it can be empty ({}), or carry filters and sort. packages-lookup takes no body. limit sets the page size, up to the default of 1000.
2. While the response’s next_cursor is not null, GET the same path with the same query and cursor=<next_cursor>. A GET without cursor is rejected. The filters and sort from the POST apply to every page.

URL-encode the package query: a bare +, common in Debian versions, is read as a space. For example, to list the released app versions that contain log4j-core 2.14.1:

curl -X POST \
  'https://my-anchore.example.com/exp/quick-search/apps-by-package?package=log4j-core%402.14.1' \
  -H 'content-type: application/json' \
  -d '{"filters": [{"field": "app_version.status", "operator": "eq", "value": "released"}]}'

Each result names the application and its contact, the app version, and the number of matched packages and assets in that version.

Check a Known App Version with the API

The stable API returns the vulnerabilities for a version you already know, under /apps/{app_id}/versions/{version_id}/vulnerabilities, with a packages-by-vulnerability pivot for a specific finding:

curl -X GET \
  'https://my-anchore.example.com/apps/{app_id}/versions/{version_id}/vulnerabilities' \
  -H 'accept: application/json'

The full schemas are in the API browser under the App Version Vulnerabilities tag; see Scan an App Version for details.

Search Container Images

The image scope searches across the analyzed image catalog. Both surfaces below draw from the same underlying vulnerability and package data, so the choice is about who is running the query and what they want back.

Search Container Images in the Anchore Enterprise GUI

The Reports tab in the Anchore Enterprise GUI is the interactive search surface for images. Reports are built from templates that define which filters appear on the report form and which columns appear in the result, and from executions that capture the result of running a configured report at a point in time.

New Report

The New Report tab is where reports are composed and executed. Pick a template, set the filter values, and run the report once for an immediate result, or save it for re-use.

Saved Reports

Saved reports retain their template, filter selections, and execution history. From the Saved Reports tab you can:

• Generate Now — run a saved report on demand.
• Schedule — run the report on a recurring cadence and notify subscribers when results are ready.
• Execution history — browse past runs, download their CSVs, or drill into the on-screen results.

A saved report keeps the columns its template had when the report was saved, and editing a saved report does not change them. To pick up columns added to a template later, create the report again from the template.

Templates

Templates define the shape of a report: which filters are presented to the user, with what defaults, and which columns appear in the result.

Anchore Enterprise ships a set of system templates as starting points, for example “Images Affected by Vulnerability”, “Images Failing Policy Evaluation”, and “Tags by Vulnerability”. System templates cannot be modified, but you can copy any of them into a user template and tailor the filter and column set to your team’s needs.

Templates and reports are both account-scoped. Templates created by other users in the same account are visible and can be used as a starting point for further customization.

Track How Long a Tag Has Been Vulnerable

The Tags by Vulnerability system template includes an Image Tag Vulnerable From column: the earliest date a vulnerability was detected on a tag, across every image the tag has pointed to. A vulnerability that persists through several image pushes keeps its original date instead of restarting with each new image. Only findings that are still open count, and the date reaches back only as far as reporting data is retained.

To select vulnerabilities by how long they have been present on a tag, add the Vulnerable For At Least Days or Vulnerable For At Most Days filter from the report’s Filters menu. For example, Vulnerable For At Least Days set to 30 lists the vulnerabilities that have been present on a tag for 30 days or more, which suits remediation SLA tracking. In the GraphQL API, the filters are vulnerableForAtLeastDays and vulnerableForAtMostDays, and the column is the imageTagVulnerableFrom field.

Search Container Images with AnchoreCTL

AnchoreCTL returns the findings for a single analyzed image rather than searching across the catalog. To pull an image’s vulnerabilities and filter for a CVE:

anchorectl image vulnerabilities docker.io/my-org/api:1.4.0

See Scan a Container Image for the output formats and filter flags. For questions that span the whole image catalog, use the Reports view above or the Query API below.

Search Container Images with the API

The Query API is the programmatic surface for zero-day investigation and tooling integrations. Two endpoints cover the common patterns: look up a vulnerability by ID, or find images containing a specific package version.

Find Images by Package

When the vulnerability record is incomplete, common in the first hours after disclosure, search by the affected package version directly. The classic example: locate every image with a vulnerable version of k8s.io/ingress-nginx.

curl -X GET \
  'https://my-anchore.example.com/v2/query/images/by-package?name=k8s.io%2Fingress-nginx&package_type=go&version=v1.11.0' \
  -H 'accept: application/json'

The response is a paginated PaginatedImageList, where each entry names the image digest, the tag history that points at it, and the package records that match the filter:

{
  "images": [
    {
      "image": {
        "image_digest": "sha256:4db2297322e827ae13892be1480800471ec83726edea921bd45af0f8ed35e094",
        "tag_history": [
          {
            "full_tag": "registry.k8s.io/ingress-nginx/controller:v1.11.0"
          }
        ]
      },
      "packages": [
        { "name": "k8s.io/ingress-nginx", "version": "v1.11.0", "type": "go" }
      ]
    }
  ],
  "total_count": 1
}

For the full zero-day investigation pattern, including how to escalate from a package match to remediation, see the Find Zero-day Vulnerabilities quickstart.

Look Up a Vulnerability by ID

When the vulnerability ID is known, GET /v2/query/vulnerabilities returns the underlying record and the packages it affects:

curl -X GET \
  'https://my-anchore.example.com/v2/query/vulnerabilities?id=CVE-2024-3094' \
  -H 'accept: application/json'

Useful as a quick “does Anchore Enterprise know about this yet?” check before kicking off a broader hunt.

The full request and response schemas for both endpoints are in the API browser under the Query tag.

Where to Go Next

• Evidence — produce formal documents from search results: VEX, VDR, vulnerability data exports.
• Annotations — record VEX dispositions on findings; annotations feed the VEX evidence exports, and both the quick vulnerability search and the affected app versions export can filter by annotation status.
• Reporting Service configuration — tune the data-refresh cadence that drives the Reports view.

2 - 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.