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.

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.

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, asset attribution, 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.

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 per-asset attribution.
• GET .../policy/findings/vulnerabilities — vulnerability findings only, isolated from other gate types.

To re-run the evaluation against an existing version — for example after editing a policy or attaching new assets to a version — submit a job:

• POST /apps/{app_id}/jobs/evaluate-policy — creates an evaluate-policy job; the response carries a job_id. Poll GET /apps/{app_id}/jobs/{job_id} until status reaches a terminal state.

The full request and response schemas, including the structure of findings and the evaluate-policy job spec, are in the API browser; search for the App Version Policy and App Jobs tags.

A few conventions worth knowing as you call these endpoints:

• Re-evaluations are asynchronous. The standard job lifecycle (pending → processing → complete / failed / cancelled) applies; see How It Works for the underlying model.
• 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.