Policy Mappings

Policy mappings bind rule sets and allowlists to the artifacts they evaluate. When an artifact is checked against a policy, the mapping section of the bundle is what decides which rule sets to run and which allowlists to apply, based on the artifact’s identity.

Each artifact type — container images and SBOMs — has its own mapping configuration inside the policy bundle. Mappings are evaluated in order; the first match wins; everything else in the list is ignored for that artifact.

A typical bundle ends with a catch-all mapping that uses wildcards in every selection field, so every artifact gets matched against at least one rule set. Without a catch-all, an artifact that matches no specific mapping is treated as unmapped.

Mapping Selection Fields

The two mapping types match on different artifact attributes, but share the same set of action fields — the rule sets and allowlists the mapping applies.

Container Image Mappings

A worked example: an image at registry.example.com/anchore/webapi:latest matches a mapping with registry = registry.example.com, repository = anchore/web*, and image.value = *.

SBOM Mappings

SBOM rule sets support a limited gate library — see Policy Gates for the per-rule-set-type availability.

Order of Evaluation

Container-image mappings within the mappings list are evaluated top-to-bottom and halt on the first match. This means:

• Order matters. A specific mapping placed below a wildcard mapping will never fire.
• A catch-all should always be last. Putting wildcards (*) in every selection field at the bottom of the list guarantees nothing slips through.
• Image and SBOM mappings are independent. Container images consult the mappings list only; SBOMs consult the sbom_mappings list only. An image’s mapping order has no effect on what an SBOM matches.

Manage Mappings in the Anchore Enterprise GUI

Mappings live on the Mappings tab of the policy editor, with separate panels for container-image and SBOM mappings. Each panel shows the existing mappings in order, with controls to add, edit, reorder, or delete entries.

Add a Mapping in the GUI

From the relevant panel, click Add Mapping (or the prompt that appears when the panel is empty). Provide a name, the rule sets the mapping should apply, optional allowlists, and the selection fields for the artifact type (registry / repository / tag for images; name / version for SBOMs). When more than one mapping exists, a Position field also appears so the new mapping can be placed at the right point in the evaluation order.

Reorder, Edit, or Delete a Mapping

Use the row actions on each mapping to edit, reorder, or delete it. Because order matters, the reorder action carries the most operational weight — moving a wildcard mapping above a specific one effectively disables the specific one.

Manage Mappings with AnchoreCTL

Mappings live inside the policy bundle JSON. There is no dedicated anchorectl mapping command — to change a policy’s mappings, retrieve the bundle, edit the mappings and sbom_mappings arrays, and submit the updated bundle through anchorectl policy update. The full CRUD workflow is documented under Manage Policies.

A minimal pair of bundle excerpts — one image mapping and one SBOM mapping, each terminated by a catch-all:

{
  "mappings": [
    {
      "name": "internal-registry",
      "registry": "registry.example.com",
      "repository": "anchore/web*",
      "image": { "type": "tag", "value": "*" },
      "rule_set_ids": [ "strict-policy-image-rs" ],
      "allowlist_ids": [ "prod-allowlist" ]
    },
    {
      "name": "default",
      "registry": "*",
      "repository": "*",
      "image": { "type": "tag", "value": "*" },
      "rule_set_ids": [ "default-image-rs" ]
    }
  ],
  "sbom_mappings": [
    {
      "name": "default",
      "sbom_name": "*",
      "sbom_version": "*",
      "rule_set_ids": [ "default-sbom-rs" ]
    }
  ]
}

To apply the edit, submit the updated bundle:

anchorectl policy update --input ./strict-policy.json

Manage Mappings with the API

The mappings and sbom_mappings arrays are part of the Policy schema and are created and updated through the same POST /policies and PUT /policies/{policy_id} endpoints as the rest of the bundle. The full schema for each mapping type, including every selection field and allowed value, is in the API browser; search for the Policies tag.