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.

Supported Gates

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

SBOM Rule Set Trigger Restrictions

SBOM rule sets support the vulnerabilities gate (and the always utility gate), but not every trigger of the vulnerabilities gate is available in this scope. The supported triggers for SBOM rule sets are:

denylist — fire when a specific CVE is present.
package — fire when a package has a vulnerability matching the configured severity, CVSS, or fix-state criteria.
stale_feed_data (deprecated) — fire when the vulnerability data source has not been updated within a configured time window.

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.

The remaining vulnerabilities triggers and all other gates apply only to container-image rule sets. To use the full gate library on a release that includes both images and SBOMs, model the release as an app version and let the per-asset mappings pick the appropriate rule set for each asset.

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 June 16, 2026