Evaluate Policy Against an App Version

App-version-scoped policy evaluation runs a policy against every asset attached to an app version and aggregates the results into a single per-version verdict. Use this surface for release-stage CI/CD gates, version-acceptance checks once an app version has all its assets attached, and portfolio-level compliance reporting.

The policy applied is the per-app policy_id when one is set on the parent app, otherwise the account’s active policy. Every asset in the version — container images and SBOMs alike — is evaluated against all SBOM-type rule sets in the policy bundle; the bundle’s container-image mappings are not used in app-version evaluation, and rule sets are not selected by mapping. SBOM mappings are consulted only for their allowlists: every allowlist referenced by any SBOM mapping is applied to the findings, and the sbom_name and sbom_version selectors are completely ignored in v6.0. The per-asset findings are rolled up into the version-level status.

To apply different rule sets to different applications, set a specific policy on the app (its policy_id). SBOM mapping selectors are not used to differentiate assets during app-version evaluation. See Policy Mappings.

When an evaluation changes the version’s overall policy status, Anchore Enterprise emits a policy_status_changed event that the Notifications service can route to Slack, email, Jira, and other endpoints. The notification carries the previous and new status alongside the application and version names, and links to the version’s Compliance tab. Versions marked eol are never notified, and emission is best-effort; a failed notification never fails the evaluation job.

App-version evaluation is VEX-aware: each vulnerability finding carries the version’s VEX annotation status for its (vulnerability, package version) pair, and the vulnerabilities gate’s missing_annotation and annotation_status parameters let rules act on that state, for example failing the version while findings remain assessed as affected or un-triaged. Saving or updating an annotation triggers a fresh evaluation immediately, so the compliance verdict reflects the new assessment without waiting for the next scheduled evaluation. See Policy Gating by Annotation Status for worked examples.

Evaluate an App Version in the Anchore Enterprise GUI

The Compliance tab on a version’s detail page is the home for app-version compliance results. The tab shows the aggregated Pass / Fail verdict at the top, with findings grouped by gate, trigger, and asset below. Each finding carries the action badge (STOP, WARN, GO), the rule that produced it, the asset on which it fired, and any allowlist item that matched.

Review Findings by Gate

The Gates panel on the Compliance tab lists the gates an app version is evaluated against: Vulnerabilities and Packages. Select a gate to show its findings. Each gate has its own findings table, filters and Export button, and the selected gate is reflected in the URL.

The Packages gate lists the findings from the match trigger. Each row shows the trigger, the matched package and its details, the outcome, the policy rule, the number of affected assets and any allowlist match. The findings can be filtered by Package Name, Package Version, Package Type and PURL, as well as by outcome, policy rule, allowlist state and number of affected assets. If the policy has no rules for the packages gate, the tab says so instead of showing an empty table.

Filter Findings by VEX Status

Each vulnerability finding on the Compliance tab shows the VEX status of its (vulnerability, package version) pair, and the tab can be filtered by Has VEX Annotation and VEX Status, matching the filters on the version’s Vulnerabilities tab. Findings can also be filtered by rule set name, and the Policy Rule column is sortable. Filter and sort selections are reflected in the URL, so a filtered view can be bookmarked or shared, and updating a VEX annotation refreshes the compliance findings automatically.

Evaluate an App Version with AnchoreCTL

AnchoreCTL exposes two read commands plus an export. The pair of read commands covers the typical CI/CD pattern of “check the verdict, then drill into findings if it failed.”

Get the Version’s Pass / Fail Status

The status command returns the headline verdict for a version against the account’s active policy (or the app’s policy_id if one is set). It’s the right surface for CI/CD pipelines that need a quick pass/fail signal:

anchorectl app version policy status get 1.4.0 --app my-service

Use -o json for the structured response, which includes the verdict, the policy ID that was evaluated against, and the timestamp of the underlying evaluation.

List the Findings That Drove the Verdict

When a version fails, the findings list enumerates every rule that fired across every asset in the version, with the gate, trigger, action, count of affected assets, and any allowlist match:

anchorectl app version policy findings list 1.4.0 --app my-service

Use -o json for the structured records that downstream tooling can consume.

Export the Compliance Report

To produce a downloadable CSV report of the version’s compliance findings — for an audit, a customer deliverable, or an offline review — use the export command:

anchorectl app version export policy-compliance 1.4.0 \
  --app my-service \
  --file my-service-1.4.0-compliance.csv

The export runs as an asynchronous job; AnchoreCTL submits it, waits for completion, and writes the result to the file specified by --file (or stdout if omitted). CSV is the only export format supported today.

Each export covers the findings of one gate. AnchoreCTL exports the vulnerabilities gate. To export the packages gate’s findings, select the Packages gate on the Compliance tab and click Export, or set gate to packages in the API request:

curl -u <username>:<password> -X POST \
  -H "Content-Type: application/json" \
  -d '{"app_version_id": "<version-id>", "format": "csv", "gate": "packages"}' \
  "https://<anchore-url>/v2/apps/<app-id>/jobs/export-policy-compliance"

gate defaults to vulnerabilities. The generated file is named policy-compliance-export-<gate>-<job-id>.csv. To download it, follow the job lifecycle described in Evidence.

The CSV contains one row per finding per asset. Every row starts with the same columns, followed by columns specific to the gate, and ends with the columns that identify the asset:

See Evidence for the shared CSV conventions.

Evaluate an App Version with the API

App-version-scoped evaluation is exposed through several endpoints under /apps/{app_id}/versions/{version_id}/policy/:

• GET .../policy/status — the headline Pass / Fail verdict for the version.
• GET .../policy/findings/all — every finding from the most recent evaluation, with a count of affected assets per finding.
• GET .../policy/findings/vulnerabilities — vulnerability findings only, isolated from other gate types.
• GET .../policy/findings/packages — packages gate findings only, with the name, version, type and PURL of each matched package.

There is no endpoint for requesting an evaluation directly; re-evaluation is automatic. Editing the policy, changing the version’s assets, saving a VEX annotation, and vulnerability data updates all make the stored evaluation stale. While a fresh evaluation runs, the .../policy/ endpoints return 409 (error code PO504); retry after a short delay to receive the new result.

The full response schemas, including the structure of findings, are in the API browser; search for the App Version Policy tag.

A few conventions worth knowing as you call these endpoints:

• Re-evaluations are asynchronous; a 409 from the status or findings endpoints means one is in flight, not an error to handle.
• Findings are first-class records — see Findings as First-Class Records for the data shape and the relationship to allowlists.
• Cross-account requests follow the standard pattern — see Account Scoping.