Policy Mappings

Introduction

The Mapping feature of the Policy Editor creates rules that define which policies and allowlists should be used to perform the policy evaluation of a source repository, SBOM, or container image based on various factors.

The policy editor lets you set up different rule-sets that will be used on different artifacts based on the use case. For example the policy applied to a web-facing service may have different security and operational best practices rules than a database backend service.

Each artifact type supported by policy has it’s own set of mapping rules. The mapping rules are evaluated in order and will halt on the first matching rule. This is important to understand when combined with wildcard matches since it enables sophisticated matching behavior.

It is recommended that a final catch-all mapping exists for each artifact types to ensure that all artifacts are mapped to a policy. This catch-all mapping should specify wildcards in all the matching fields.

Each mapping can specify a list of rule-sets to be evaluated, as well as an optional list of allowlists to apply.

Note: The trusted images and denylisted images lists are applied across all images, regardless of the mappings that were applied. See Allowed / Denied Images for details.

Image Mappings

An image mapping matches on the parts of a container pull string, Registry, Repository, and Tag.

More information about Image mappings can be found at Container Image Mapping.

Source Mappings

A source mapping matches on the base host url of the source code as well as the specific repository.

More information about Source appings can be found at Source Repository Mapping.

SBOM Mappings

An SBOM mapping matches on the name and version of the SBOMs.

More information about SBOM mappings can be found at SBOM Mapping.

Last modified December 12, 2025