Anchore Enterprise evaluates policies against software artifacts to produce a Pass or Fail verdict. The same policy engine, the same rule sets, and the same exception mechanisms run against two distinct scopes — pick the one that matches how your team organizes software.
Two Evaluation Scopes
The two scopes differ only in what the policy is run against. The authoring side is identical.
A single analyzed container image, identified by digest
Pass / Fail for that one image, with per-trigger findings
Image-stage CI/CD gates, post-build pre-publish checks, ad-hoc checks against an image you already have on hand
The app-version-scoped surface is the v6-native evaluation path for teams that have adopted the apps, versions, and assets model. The image-scoped surface is the long-standing path and remains fully supported.
What’s Shared Between Scopes
Both scopes share the same authoring surface — there is no separate “image policy” and “app version policy” to maintain. Specifically:
The policy bundle is the same. The same bundle gates an image-scoped evaluation and an app-version-scoped evaluation. Within the bundle, image rule sets support the full gate library and SBOM rule sets support the Vulnerabilities gate only — so a check against a container image exercises more of the bundle than a check against an SBOM asset, while the bundle being applied is identical. See Policy Gates for the canonical list of all supported gates and their per-rule-set-type availability.
Mappings resolve identically. The image’s registry, repository, and tag (or the SBOM’s name and version) determine which rule sets and allowlists apply, regardless of whether the evaluation was triggered by an image-check or an app-version-status call.
Allowlists apply in both scopes — they attach to the policy and are referenced by both image and SBOM mappings. Allowed and denied image lists are the exception: they apply to image-scoped evaluation only.
The Pass / Fail / Warn verdict semantics are identical — STOP, WARN, and GO actions roll up to the same final verdict in both scopes.
The aggregation is what differs: an image-scoped evaluation returns one verdict for one image, while an app-version-scoped evaluation rolls up every asset in the version into a single per-version verdict and exposes the underlying findings through a query API that pivots across assets. Because the version may contain a mix of container-image and SBOM assets, the verdict aggregates evaluations against different rule sets within the same bundle — each asset matched by its mapping to the rule set appropriate for its type.
Tip: for the gate inventory as implemented by a specific running Anchore Enterprise instance — useful for tooling that validates policy bundles client-side before submission — call GET /system/policy-spec. The endpoint returns every gate, trigger, parameter, and value type the running instance supports.
For the underlying evaluation pipeline that both scopes run through — image override checks, mapping resolution, rule evaluation, allowlist application, and final action determination — see How It Works.
1 - 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:
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.
2 - Evaluate Policy Against an Image
Image-scoped policy evaluation runs a policy against a single analyzed container image and returns a Pass or Fail verdict for that one image, plus the per-trigger findings that produced it. This is the long-standing evaluation surface and remains fully supported in v6 — use it for image-stage CI/CD gates, post-build pre-publish checks, and ad-hoc verification of an image already in the catalog.
The evaluation is computed against the image’s existing analysis and the policy that the artifact’s mapping selects. The active account policy is used by default; pass a specific policy ID to evaluate against a different bundle.
Evaluate an Image in the Anchore Enterprise GUI
Open an analyzed image’s detail page from the Images view. The Compliance tab shows the most recent evaluation result — the final Pass / Fail verdict at the top, with findings grouped by gate and trigger below. Each finding carries its action badge (STOP, WARN, GO), the rule that produced it, and any allowlist item that matched.
To evaluate the same image against a different policy, change the Policy selector at the top of the tab. The evaluation is recomputed and the result is displayed without changing the account’s active policy.
Evaluate an Image with AnchoreCTL
anchorectl image check fetches the policy evaluation for an image. The image argument accepts a registry/repo:tag reference, an image digest, or an image ID; for digest or ID, the -t flag specifies which tag’s evaluation to return.
A basic check returns the Pass / Fail verdict for the image against the account’s active policy:
anchorectl image check docker.io/my-org/api:1.4.0
To see the individual findings that drove the verdict — each rule that fired, the gate and trigger that produced it, the action, and the message — add --detail:
To evaluate the image against a specific policy rather than the account default, pass --policy with the policy name or ID. The account’s active policy is not affected:
The output format is controlled with -o. Beyond text, the json, json-raw, and csv formats are useful for piping into other tooling; html (combined with --detail) emits a formatted compliance report you can save as a build artifact:
Image-scoped evaluation is exposed through a single endpoint:
GET /images/{image_digest}/check — returns the most recent policy evaluation for the image. Accepts query parameters for policy_id, tag (required), detail, history, and base_digest.
The full request and response schemas, including the structure of findings inside the evaluation result, are in the API browser; search for the Images tag.
A few conventions worth knowing as you call this endpoint:
The tag query parameter is required even when the image is identified by digest — the evaluation result is per-tag, so the same image may have different verdicts under different tags.
base_digest=auto enables base-image inheritance in the evaluation result, marking which findings come from the image’s base rather than its own layers.
Cross-account requests follow the standard pattern — see Account Scoping.
