Evaluate Policy Compliance

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.

Scope	What is evaluated	Verdict shape	Typical use
App-version-scoped	Every asset attached to an app version	Aggregated Pass / Fail for the whole version, rolling up each asset’s findings	Release-stage CI/CD gates, version-acceptance checks once an app version has all its assets attached, portfolio-level compliance reporting
Image-scoped	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.

Where to Go Next

Evaluate Policy Against an App Version — GUI / CLI / API walkthrough for the app-version-scoped path
Evaluate Policy Against an Image — GUI / CLI / API walkthrough for the image-scoped path

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.

Last modified June 16, 2026