How It Works

Compliance management in Anchore Enterprise is built around a policy engine that evaluates software artifacts against customizable rules and produces a Pass or Fail verdict. A policy is composed of one or more rule sets, each containing gates and triggers that define specific conditions to check. Policies are bound to artifacts through mappings, and findings can be suppressed by exceptions (allowlists, plus allowed and denied image lists).

The same policy engine evaluates against two scopes — a single analyzed container image, or every asset attached to an app version — letting the same rule set serve both per-artifact gates and release-level aggregation.

Specific topics related to the compliance management framework can be referenced per the links below:

• Manage Policies
• Policy Gates
• Policy Packs
• Policy Mappings
• Exceptions
• Evaluate Policy Compliance
• STIG
• SBOM Drift

Policies, Gates, Triggers, and Actions

A policy is structured around two levels of detail:

• Gates group checks into broad categories such as packages, vulnerabilities, secrets, licenses, file permissions, Dockerfile configuration, and tag drift. The full gate library applies to container-image rule sets; SBOM rule sets currently support the Vulnerabilities gate only.
• Triggers define the specific condition to check within a gate, and carry parameters that tune the check — for example, the Vulnerabilities gate’s package trigger accepts a minimum severity and a CVSS comparison.

Each rule fires with one of three actions:

Rules are evaluated independently — two rules with the same trigger condition but different actions both fire and produce separate findings. Detailed gate, trigger, and parameter reference lives under Policy Gates.

Policy Mappings

Policy mappings bind policies and allowlists to the artifacts they apply to. Each mapping carries selection filters (registry, repository, tag, name, version), and the resolved match identifies which rule sets and allowlists evaluate the artifact.

Container-image mapping rules are evaluated in order and halt on the first match; a catch-all rule using wildcards in every field is recommended at the end of the list so every image is covered. App-version evaluation behaves differently in v6.0 — every asset is evaluated against all SBOM-type rule sets in the bundle, the container-image mappings are not consulted, and sbom_mappings are used only to supply allowlists. Container images and SBOMs each have their own mapping configuration.

Exceptions

Two mechanisms suppress policy findings without modifying the underlying rules. Both live under Exceptions:

• Allowlists target individual findings — a specific CVE on a specific package, with optional expiry. When an allowlist item matches a finding, the finding’s action is overridden to GO and the evaluation output records which allowlist item produced the match.
• Allowed and denied image lists are system-wide overrides applied before any mapping logic. Images on the denied list fail immediately; images on the allowed list pass immediately. When an image appears on both, the denied list takes precedence.

The Evaluation Pipeline

When an artifact is submitted for evaluation, Anchore Enterprise performs the following steps in order:

1. Allowed and denied image lists are checked first. These are system-wide overrides applied before any mapping or rule set logic. This step applies only to container images.
2. A mapping rule is resolved. For standalone container-image evaluation, the artifact’s identity — registry, repository, and tag — is matched against the ordered list of mapping rules, evaluated in order and halting on the first match. In app-version evaluation (v6.0), mappings are not used to select rule sets: every asset is evaluated against all SBOM-type rule sets in the bundle, and sbom_mappings supply only the allowlists.
3. All specified rule sets are evaluated. Each rule within each rule set is evaluated independently against the artifact’s SBOM. Every triggered rule produces a finding with the action defined in that rule.
4. Allowlists are applied to findings. Each allowlist item is matched against the set of findings from step 3. A matched finding has its action overridden to GO and is flagged as allowlisted in the evaluation output.
5. A final action is determined. The engine aggregates all remaining findings into a single verdict:

   Final Action	Condition
   stop	At least one rule fired with action STOP and was not allowlisted. The evaluation fails.
   warn	No STOP results, but at least one WARN. The evaluation passes with warnings.
   go	No STOP or WARN results. The evaluation passes cleanly.

Evaluation Scopes

The same policy engine runs against two distinct scopes — pick the one that matches how your team organizes software. Both are covered in Evaluate Policy Compliance.

• App-version-scoped — evaluate a policy against every asset attached to an app version, with results aggregated into a single per-version status. This is the v6-native surface, used by anchorectl app version policy status get / policy findings list, the /apps/{id}/versions/{vid}/policy/* endpoints, and the evaluate-policy job that re-runs aggregation on demand.
• Image-scoped — evaluate a policy against a single analyzed container image, identified by digest. The result returns a Pass / Fail verdict and the per-trigger findings for that one image. This is the long-standing evaluation surface, used by anchorectl image check, the /images/{digest}/check API, and CI/CD gates that don’t yet model releases as app versions.

Both scopes share the same policies, mappings, and exceptions — there is no separate policy authoring surface for each. The scope only determines what the policy runs against.

Findings as First-Class Records

Every finding produced by an evaluation is a structured record stored in Anchore Enterprise’s database — not an entry buried inside a result envelope. Each finding carries its own UUID, its created_at and updated_at timestamps, the gate and trigger that produced it, the resolved action (including any allowlist override), and the matched allowlist item when one applied.

This shape makes it practical to query findings the same way you query packages or vulnerabilities — see the pivot endpoints documented in Observe an App Version for the app-version-scoped queries. Findings are exposed directly through /apps/{id}/versions/{vid}/policy/findings/all and /policy/findings/vulnerabilities, and through anchorectl app version policy findings list.

Specialized Frameworks

Anchore Enterprise also provides two specialized features that sit alongside the policy engine:

• STIG — Security Technical Implementation Guide evaluation against analyzed container images. STIG runs independently of the standard policy pipeline and requires an additional license entitlement.
• SBOM Drift — surfaces package-level additions, removals, and modifications between successive builds of the same image tag. Drift detection runs through the tag_drift gate within the standard policy pipeline rather than as a separate report.