How It Works

Compliance management in Anchore Enterprise is built around a policy engine that evaluates software artifacts — source repositories, imported SBOMs, and container images — 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. Gates group checks into broad categories such as vulnerabilities, secrets, licenses, file permissions, and Dockerfile configuration; triggers define specific conditions within each gate and specify an action — STOP, WARN, or GO — that determines how a match is handled. Policies are mapped to artifacts using configurable mapping rules, allowing different policies to apply to different registries, repositories, or artifact types. Exceptions can be defined through allowlists, which suppress specific findings, or through allowed and denied image lists, which unconditionally pass or fail specific images regardless of policy content. Anchore Enterprise also provides pre-built policy packs mapped to common regulatory frameworks — FedRAMP, NIST, CIS, and DoD — as well as a default Secure policy pack included in every deployment. SBOM drift detection is also available through the tag_drift gate, which surfaces package-level additions, removals, and modifications between successive builds of the same image tag. For organizations subject to formal government security configuration requirements, STIG evaluation support is available as an additional entitlement.

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

• Policy Gates
• Policy Mappings
• Allowlists
• Allowed and Denied Images
• SBOM Drift
• Policy Packs
• Anchore STIG
• Test Policies
• Manage Policies

Policy Evaluation

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. Images on the denied list fail immediately; images on the allowed list pass immediately. When an image appears on both lists, the denied list takes precedence. This step applies only to container images — source repositories and SBOMs are not subject to image list overrides.

2. A mapping rule is resolved. The artifact’s identity — registry, repository, and tag for container images; host URL and repository for source repositories; name and version for SBOMs — is matched against the ordered list of mapping rules for that artifact type. Mapping rules are evaluated in order and halt on the first match. The resolved mapping identifies which rule sets and allowlists apply to the artifact.

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. Rules do not interfere with each other: two rules with identical trigger conditions but different actions both fire and produce separate findings.

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.

Policy Bundle Structure

A policy is stored in Anchore Enterprise as a single JSON document — the policy bundle. The bundle contains all components required for evaluation: rule sets, allowlists, mappings, and image override lists.

{
  "id": "default0",
  "version": "2",
  "name": "My Default Policy",
  "comment": "My system's default policy",
  "allowlisted_images": [],
  "denylisted_images": [],
  "mappings": [],
  "allowlists": [],
  "rule_sets": []
}

Policy bundles can be managed via the UI, REST API, or the anchorectl policy command. For details, see Managing Policies.

Policy Gates and Rules

Policy Gates define the structure of compliance rules. A rule is built by combining a gate, a trigger, optional parameters, and an action.

Each rule within a rule set is a JSON object of the following shape:

{
  "action": "STOP",
  "gate": "vulnerabilities",
  "trigger": "package",
  "id": "rule1",
  "params": [
    { "name": "package_type", "value": "all" },
    { "name": "severity_comparison", "value": ">=" },
    { "name": "severity", "value": "medium" }
  ],
  "recommendation": "Upgrade the package"
}

Actions

Rules are evaluated independently. Two rules with identical trigger conditions but different actions both fire and produce separate findings.

Gate Availability by Artifact Type

For source repository and SBOM rule sets, only the following Vulnerabilities gate triggers are supported: denylist, package, and stale_feed_data.

Policy Mappings

Policy Mappings define which rule sets and allowlists are applied to a given artifact during evaluation. Each artifact type has its own set of mapping rules, and each type is evaluated independently.

Mapping rules are evaluated in order and halt on the first matching rule. A final catch-all mapping — using wildcards for all fields — is recommended to ensure every artifact is covered.

Each mapping entry is a JSON object of the following shape:

{
  "name": "DockerHub",
  "registry": "docker.io",
  "repository": "library/postgres",
  "image": { "type": "tag", "value": "latest" },
  "rule_set_ids": [ "policy1", "policy2" ],
  "allowlist_ids": [ "allowlist1" ]
}

Matching Criteria by Artifact Type

A typical mapping array ends with a catch-all entry that uses wildcards in every field to ensure all artifacts are evaluated:

[
  {
    "name": "DockerHub",
    "registry": "docker.io",
    "repository": "library/postgres",
    "image": { "type": "tag", "value": "latest" },
    "rule_set_ids": [ "policy1" ],
    "allowlist_ids": [ "allowlist1" ]
  },
  {
    "name": "default",
    "registry": "*",
    "repository": "*",
    "image": { "type": "tag", "value": "*" },
    "rule_set_ids": [ "policy1" ],
    "allowlist_ids": [ "allowlist1" ]
  }
]

Allowlists

Allowlists define exceptions that suppress specific policy findings without modifying the underlying rules — useful for accepted risks or known false positives. A policy bundle can contain multiple allowlists; each mapping specifies which allowlists are active for the artifacts it matches.

Allowlists are applied after rule evaluation. When an allowlist item matches a finding, the finding’s action is overridden to GO and the evaluation output records which allowlist and item produced the match.

Each allowlist is a JSON object with the following structure:

{
  "id": "allowlist1",
  "name": "My Allowlist",
  "comment": "Optional description of the allowlist",
  "version": "2",
  "items": [
    {
      "id": "item1",
      "gate": "vulnerabilities",
      "trigger_id": "CVE-2018-0737+*",
      "expires_on": "2025-12-30T12:00:00Z"
    }
  ]
}

Each entry in the items array specifies the gate context, a trigger_id to match, and an optional expiry:

For vulnerabilities, trigger_id takes the form CVE-ID+package-name. Wildcards in either component enable broader suppression — for example, CVE-2017-9000+bind-* suppresses a given CVE across all packages with the bind- prefix.

Allowed and Denied Images

The allowed and denied image lists are system-wide overrides applied before mapping and rule evaluation. Images on the allowed list pass unconditionally; images on the denied list (denylist) fail unconditionally. When an image appears on both lists, the denied list takes precedence.

Unlike mapping rules, these lists apply across all images in the deployment regardless of which mapping rule matched.

Images can be identified in any of the following ways:

SBOM Drift

SBOM drift detection surfaces package-level changes between successive builds of the same image tag. The tag_drift gate compares the SBOM of the image being evaluated against the SBOM of the immediately preceding image with the same tag, then evaluates the result against configured triggers.

Triggers

All three triggers accept an optional package_type parameter to restrict evaluation to a specific package ecosystem.

Example rule that raises a WARN when packages are added:

{
  "action": "WARN",
  "gate": "tag_drift",
  "trigger": "packages_added",
  "params": [],
  "id": "1ba3461f-b9db-4a6c-ac88-329d38e08df5"
}

By treating drift as a policy gate rather than a separate report, build integrity monitoring participates in the same evaluation workflow used for all other compliance checks.

Policy Packs

Anchore Enterprise provides pre-built policy packs for common regulatory frameworks. The Secure policy pack is included and enabled by default in every deployment. All other packs require the correct license and subscription entitlement — contact Anchore Customer Success to obtain them.

Anchore STIG

Anchore STIG extends compliance management to cover formal government security configuration requirements. It supports two evaluation targets:

• Container images managed within Anchore Enterprise — STIG evaluation is performed against analyzed container images.
• Running containers in a Kubernetes deployment — STIG evaluation is performed against containers active in a Kubernetes cluster.

This gives organizations a single platform for both build-time and runtime STIG compliance. STIG requires an additional license entitlement; contact Anchore Customer Success for access.

Test Policies

The Evaluation Preview feature allows a policy to be tested against an artifact before enforcement. It verifies which mapping, policy, and allowlists would be applied and shows the resulting evaluation outcome — including any STOP or WARN findings — without affecting production enforcement.

The artifact must have already been analyzed by Anchore Enterprise before an evaluation preview can be run.

Policy evaluation can also be run via AnchoreCTL using the anchorectl image check command:

anchorectl image check docker.io/debian:latest --detail

The --detail flag shows each rule that fired, including the gate, trigger, description, and action. The --fail-based-on-results flag causes the command to exit with return code 1 when the evaluation fails — useful for enforcing pass/fail gates in CI/CD pipelines.

Manage Policies

Anchore Enterprise supports multiple policies per account, each with a unique name and ID. Only one policy can be active at a time — the active policy is used for automated evaluations, notifications, and Kubernetes webhooks. Inactive policies can still be explicitly requested by policy ID, making it practical to maintain historical policies for audit and comparison.

Anchore recommends managing policy configuration via the UI rather than AnchoreCTL. A lock icon next to a policy name indicates the policy cannot be deleted. Policy rule sets in use by active mappings cannot be deleted until they have been removed from every associated mapping.

Policies can be listed, added, activated, and deleted via AnchoreCTL:

anchorectl policy list
anchorectl policy add --input /path/to/policy/bundle.json
anchorectl policy activate <policy-id>
anchorectl policy delete <policy-id>