Allowlists

Allowlists suppress specific policy findings without modifying the underlying rules — useful for accepted risks or known false positives. Each allowlist is stored inside the policy bundle alongside its rule sets and mappings, and is applied to findings during the evaluation pipeline. For how allowlists relate to the other exception mechanism, see Manage Exceptions.

An allowlist contains one or more entries, each matching a specific gate/trigger result — for example, excluding a particular CVE from policy evaluation. Allowlists are optional, and a policy may contain multiple of them. An allowlist takes effect only when a matched mapping rule references it; when an allowlist entry matches a policy trigger output, that output’s action is set to go and the evaluation result records the matching allowlist and item IDs.

Manage Allowlists in the Anchore Enterprise GUI

The Allowlist tab shows the allowlists present in a policy.

Add a New Allowlist

1. Click Add New Allowlist to create a new, empty allowlist.

2. Enter a name. A name is required and should be unique.

3. Optionally add a description. A description is recommended — it is often updated as entries are added, to explain the background (for example, “Updated to account for a false positive in the glibc library”).

   

Import or Paste an Allowlist

If you have a JSON document containing an existing allowlist, you can upload it into Anchore Enterprise. You can also edit the allowlist directly in its native JSON format — see Manage Allowlists with AnchoreCTL for the structure.

1. Click Import Allowlist.

   

2. Drag an allowlist file into the dropzone, or click Add a Local File to load it from your filesystem.

3. Click OK to upload. Anchore Enterprise validates the allowlist; only validated allowlists are stored.

Copy an Allowlist

You can copy an existing allowlist, give it a new name, and reuse it for policy evaluation.

1. From the Tools drop-down, select Copy Allowlist.

   

2. Enter a unique name.

3. Optionally add a description.

   

Download an Allowlist

To download an existing allowlist as a JSON file, open the Tools drop-down and click Download to JSON.

Edit Allowlist Entries

The Allowlists editor lets you create, edit, and remove allowlist entries.

Each entry has these components:

• Gate — the gate the entry matches, so trigger IDs are not matched in the wrong context.
• Trigger ID — the specific trigger result to match. The format is gate/trigger-specific; for the vulnerabilities gate it is the CVE trigger ID. Wildcards are supported for partial matches.
• id — an identifier for the entry, unique within the allowlist.
• Expires On (optional) — an RFC 3339 date-time after which the entry no longer applies. An expired entry that matches is not allowlisted.

From the Select a Gate dropdown you can choose any active gate (deprecated gates appear in a separate group). The fields shown depend on the gate: the vulnerabilities gate takes a CVE / vulnerability identifier and a package, while any other gates differ. The steps below use the vulnerabilities gate as the example.

1. Choose an allowlist and click Edit.

   

2. Choose a gate — for example, vulnerabilities. A vulnerabilities entry has two elements: a CVE / vulnerability identifier and a package.

   

3. Enter a CVE / Vulnerability Identifier — the vulnerability to match (for example, CVE-2017-7246), in the same format shown in the image vulnerabilities report. Wildcards are supported, but use them carefully to avoid allowlisting too many vulnerabilities.

   

4. Enter a Package — the package to match with the vulnerability (for example, libc-bin). Wildcards are supported.

   

   An entry can specify both a CVE and a package for an exact match (for example, CVE-2005-2541 + tar), or use a wildcard package where multiple packages are built from the same source (for example, CVE-2017-9000 + bind-* allowlists bind-utils, bind-libs, and bind-license). Take special care with wildcards in the CVE field — a wildcard there allowlists any vulnerability for the package, which is appropriate only in specific cases (for example, the bind-license package, a single copyright file included in all CentOS:7 images, which commonly accrues Bind CVEs that do not actually apply to it).

   

5. Save all changes before leaving the editor — at that point the edits are sent to Anchore Enterprise.

Manage Allowlists with AnchoreCTL

There is no dedicated AnchoreCTL command for allowlists — they are part of the policy bundle. To manage them from the CLI, edit the allowlists array in the bundle JSON and apply the bundle with anchorectl policy add or anchorectl policy update.

Each allowlist in the allowlists array is a JSON object:

{
  "id": "allowlist1",
  "name": "My First Allowlist",
  "comment": "An allowlist for my first try",
  "version": "2",
  "items": [
    {
      "gate": "vulnerabilities",
      "trigger_id": "CVE-2018-0737+*",
      "id": "rule1",
      "expires_on": "2026-12-30T12:00:00Z"
    }
  ]
}

• id, name — identifier and label for the allowlist; comment is an optional description.
• items — the allowlist entries. Each has a gate, a trigger_id (gate/trigger-specific; wildcards supported), an id unique within the allowlist, and an optional expires_on (RFC 3339). An entry whose expires_on has passed is not applied.

An allowlist takes effect only when a matched mapping rule references it. When an entry matches a trigger output, that output’s action is set to go and the result records the matching allowlist and item IDs.

Manage Allowlists with the API

Allowlists are submitted as part of the policy bundle, not through a dedicated endpoint. Include the allowlists array (shape above) in the bundle when you create or update a policy:

The full request and response schemas are in the API browser; search for the Policies tag.