Policy Gates

This page is the canonical list of policy gates supported by Anchore Enterprise. Each gate documented here has its own detail page covering its triggers, parameters, and example rules.

A rule inside a policy is built from four pieces:

Gate — the broad category of check (vulnerabilities, dockerfile, licenses, and so on).
Trigger — the specific condition to evaluate within the gate.
Parameters — gate- and trigger-specific values that tune the check.
Action — STOP, WARN, or GO, applied when the trigger fires.

For the broader conceptual model — how rules combine into rule sets, how mappings select which rule sets evaluate an artifact, and where allowlists override the result — see How It Works.

Gate Licensing

Some gates require a license entitlement beyond the base Anchore Enterprise license. The License column in the table below shows what each gate requires:

Included — available with every Anchore Enterprise license.
Anchore Enforce — requires the Anchore Enforce module, enabled by the Module:Enforce entitlement.
STIG add-on — requires the static STIG add-on, enabled by the AddOn:STIG:Static entitlement.

Application policies have their own two gates: vulnerabilities is included, and packages requires Anchore Enforce.

If your license does not include the entitlement a gate requires, a rule in an image rule set that uses that gate produces a warning in the policy evaluation results, for example:

The specified gate requires the "Module:Enforce" license entitlement.

If you see this warning, contact Anchore Customer Success about your license.

Image and SBOM Rule Sets

Every rule set in a policy has an artifact type, which decides what it evaluates and which gates it can use:

Image rule sets (artifact type image, Container Images in the Anchore Enterprise GUI) evaluate images in the image catalog: images analyzed from the Images view or with anchorectl image add, and checked with anchorectl image check or the /images/{image_digest}/check API. Image mappings decide which image rule sets apply to an image.
SBOM rule sets (artifact type sbom, SBOMs in the GUI) evaluate app versions. Every asset in an app version, container images included, is evaluated against all of the policy’s SBOM rule sets. Despite the name, an SBOM rule set is not limited to imported SBOMs. See Evaluate Policy Against an App Version.

Supported Gates

Gate	What it checks	Image rule sets	SBOM rule sets	License
`always`	Fires unconditionally — useful for testing rule sets, mappings, and allowlists	Yes	No	Included
`ancestry`	Checks an image against approved base or ancestor images	Yes	No	Anchore Enforce
`distro`	Matches the operating system distribution and version	Yes	No	Anchore Enforce
`dockerfile`	Checks Dockerfile content and Docker history for best-practice violations	Yes	No	Anchore Enforce
`files`	Matches files in the image by content, name, or attribute	Yes	No	Anchore Enforce
`image_source_drift`	Deprecated in v6 — compared the image SBOM against its source repository SBOM	—	—	Anchore Enforce
`licenses`	Matches package license metadata against allowed or disallowed expressions	Yes	No	Anchore Enforce
`malware`	Surfaces malware detected during analysis	Yes	No	Included
`metadata`	Matches image metadata attributes such as size, architecture, or distro	Yes	No	Anchore Enforce
`packages`	Checks for the presence or absence of specific packages	Yes	Yes (`match` only)	Anchore Enforce
`passwd_file`	Inspects `/etc/passwd` content retrieved during analysis	Yes	No	Anchore Enforce
`retrieved_files`	Inspects arbitrary files retrieved during analysis	Yes	No	Anchore Enforce
`secret_scans`	Surfaces embedded secrets matched by configured regexes	Yes	No	Included
`stig`	Requires the image to have a passing STIG evaluation attached	Yes	No	STIG add-on
`tag_drift`	Detects package additions, removals, or modifications between successive builds of the same tag	Yes	No	Anchore Enforce
`vulnerabilities`	Matches packages against vulnerability data from the Anchore Data Service	Yes	Yes	Included

SBOM Rule Set Trigger Restrictions

SBOM rule sets support two gates, each with its own set of triggers:

vulnerabilities
- denylist — fire when a specific CVE is present.
- package — fire when a package has a vulnerability matching the configured severity, CVSS, EPSS, KEV, Anchore Score, fix-state or VEX annotation criteria.
- stale_feed_data (deprecated) — fire when the vulnerability data source has not been updated within a configured time window.
packages
- match — fire for each package whose name, version or type matches the configured criteria. See SBOM Rule Sets: match Trigger.

The stale_feed_data trigger is deprecated in v6 and is no longer included in the default policy. Avoid using it in new rule sets.

All other gates, including always, and the remaining vulnerabilities and packages triggers apply only to container-image rule sets. Anchore Enterprise refuses to save a policy whose SBOM rule sets use any other gate, and reports a GateNotFoundError for each such rule.

Runtime Gate Inventory

The table above describes the gate library shipped with Anchore Enterprise. To retrieve the gate inventory as implemented by a specific running instance — including any gates added in a later release — call GET /system/policy-spec. The endpoint returns every gate, trigger, parameter, and value type the running instance supports, in the same shape that the policy validator uses.

Last modified November 2, 2026