Policy

Policy is how Anchore Enterprise turns findings into decisions. Once an artifact has been analyzed into an SBOM, a policy evaluates that SBOM — together with its vulnerability matches, metadata, and file content — and produces a pass-or-fail verdict that a CI pipeline, admission controller, or reviewer can act on. Policies are authored as JSON documents and managed through the Enterprise UI, AnchoreCTL, or the API; they can be evaluated against an artifact on demand, or continuously as vulnerability data and SBOM contents change over time.

Components of a Policy

A policy is a JSON document (a policy bundle) composed of four kinds of configuration, each with its own editor and API surface:

Rule sets — named collections of rules that define the checks to run. See Rule Sets, Gates, and Triggers below.
Mappings — ordered selection rules that pick which rule sets and allowlists apply to a given artifact. The first mapping that matches wins. See Policy Mappings.
Allowlists — per-trigger exclusions that downgrade a specific finding (for example, a known false-positive CVE) to go, so it no longer contributes to a failing evaluation. See Allowlists.
Allowlisted and denylisted images — deployment-wide overrides that force an image’s final result to pass or fail regardless of the rest of the evaluation. See Allowed / Denied Images.

For the complete JSON shape of a policy bundle, see Policy Bundle JSON Structure.

Rule Sets, Gates, and Triggers

A rule set is a named collection of rules. Each rule specifies four things:

A gate — the category of check (for example, vulnerabilities, metadata, dockerfile, secrets, files).
A trigger — the specific condition within that gate that should match (for example, a vulnerability at or above a severity threshold).
A set of parameters — gate- and trigger-specific inputs that refine the match.
An action — stop, warn, or go — emitted whenever the trigger fires.

Gates provide a logical namespace for triggers, so the same trigger name can exist in different gates without collision. A trigger can fire many times within a single evaluation — one match per detected instance — and each firing produces a finding that carries a unique trigger ID, the rule’s action, and a human-readable message. Findings are the audit-trail unit: every rule that matches contributes one or more findings to the evaluation result.

For the full catalog of gates and their triggers, see Policy Checks.

Actions and the Final Action

Each rule declares a per-rule action — stop, warn, or go. When the rule’s trigger matches, that action is recorded alongside the finding. Once all rules have run, Anchore Enterprise aggregates every recorded action into a single final action for the evaluation:

stop — at least one finding carried action stop (and was not downgraded by an allowlist). The artifact fails evaluation.
warn — no stop actions survived, but at least one warn did. The artifact passes with a warning.
go — no stop or warn actions. The artifact passes cleanly.

go findings never affect the outcome on their own, but they are still recorded in the evaluation response so historical audits can see that a check ran and produced no issue.

For the per-finding field reference and an example findings payload, see Evaluation Findings.

Policy Evaluation Flow

A full evaluation takes two slightly different paths depending on the artifact type. Container images go through image-based mapping, every supported gate, and the deployment-wide allowlisted/denylisted image overrides. Imported SBOMs go through SBOM-based mapping and evaluate only the vulnerabilities gate; they are not subject to image-level overrides. Both paths converge on the same action-aggregation logic and the same pass/warn/fail terminal states.

flowchart TD
    start([Policy evaluation requested]) --> artifact{Artifact type?}
    artifact -->|Container image| imap[Select image mapping<br/>registry, repository, tag]
    artifact -->|Imported SBOM| smap[Select SBOM mapping<br/>name and version]
    imap --> irs[Evaluate mapped rule sets<br/>across all gates]
    smap --> srs[Evaluate mapped rule sets<br/>vulnerabilities gate only]
    irs --> itrig[Triggers fire<br/>each emits stop, warn, or go]
    srs --> strig[Triggers fire<br/>each emits stop, warn, or go]
    itrig --> iallow[Apply mapped allowlists<br/>matching trigger IDs become go]
    strig --> sallow[Apply mapped allowlists<br/>matching trigger IDs become go]
    iallow --> deny{Image in<br/>denylisted_images?}
    deny -->|Yes| fail([Final action: fail])
    deny -->|No| allow{Image in<br/>allowlisted_images?}
    allow -->|Yes| pass([Final action: pass])
    allow -->|No| agg{Aggregated<br/>action across<br/>all findings}
    sallow --> agg
    agg -->|stop| fail
    agg -->|warn| pass_warn([Final action: pass with warning])
    agg -->|go| pass

At every step the finding-by-finding output is preserved in the evaluation response, so reviewers can see not just whether an artifact passed but why — every trigger that fired, every allowlist that matched, and every image-level override is recorded alongside the final action.

Pass and Fail

A policy evaluation resolves to one of two terminal states:

Pass — the artifact may proceed. Pass covers both “no findings” (go) and “findings with warnings, but nothing blocking” (warn). Warning findings are recorded for audit purposes but do not block.
Fail — the artifact is blocked. Either an image-level denylist matched (container images only), or at least one rule fired with action stop that was not downgraded by an allowlist.