The default Secure policy pack comes included (and enabled) in every fresh deployment of Anchore Enterprise.
Current Secure policy pack version: Anchore Enterprise - Secure v2026.2
Introduction
The Secure pack is the Anchore Enterprise baseline vulnerability policy: the checks a deployment should be running before it has a compliance framework to satisfy. It is deliberately conservative: critical and known-exploited findings fail an evaluation, everything else warns, so a fresh deployment produces a usable signal without blocking every build on day one.
The pack ships parallel rule sets for container images and SBOMs, so the vulnerability checks apply whether you scan an image or import an SBOM directly. All the rules configured by default can (and should) be adjusted according to an organization’s security policy.
Controls
Anchore Enterprise checks for the following control specifications in the Secure policy:
| Rule set | Behavior | Applies to |
|---|---|---|
| Fail on criticals | Fail when a critical severity vulnerability is present | Container images and SBOMs |
| Fail on KEV list | Fail when a vulnerability appears on the CISA Known Exploited Vulnerabilities (KEV) catalog | Container images and SBOMs |
| Warn on low, moderate, and high with fixes | Warn on low, medium, and high severity vulnerabilities that have a fix available | Container images and SBOMs |
| Warn on week old Important | Warn on important severity vulnerabilities more than a week old, even when no fix is available | Container images and SBOMs |
| Feed Data not available | Fail when vulnerability feed data is unavailable | Container images |
| Outdated Feed Data | Warn when the vulnerability feed has not synced in 2 days | Container images |
The two feed-data checks are the exception to the parallel coverage: they are bound to the container mapping only and are not evaluated against SBOMs. The pack also ships an empty DefaultAllowlist, attached to both mappings and ready for your accepted risks.
VEX Annotations
The vulnerability rule sets are each split into two rules that differ only in annotation state, as described in Annotations and VEX:
- One rule matches findings that carry no annotation yet, so un-triaged vulnerabilities still count against the policy.
- The other matches findings annotated
affectedorunder_investigation, so vulnerabilities you have assessed as genuinely exploitable keep counting.
Findings annotated not_affected or fixed match neither rule, so they drop out of the evaluation as soon as the annotation is saved, without an allowlist entry and without editing the policy. This is the intended path for a critical or KEV-listed finding that does not apply to your product: annotate it with a status and justification, and the assessment travels into the VEX document generated for the app version. The feed-currency checks do not depend on annotation state.
Use the Pack
The Secure pack is already imported and active in a new deployment, so there is nothing to add before it starts evaluating. Adjust it as your program matures: tighten the warn-level rules into failures as remediation catches up, attach allowlists for accepted risks, and scope it through Policy Mappings if different registries warrant different thresholds. See Manage Policies for the GUI, AnchoreCTL, and API workflows.
Teams that need to demonstrate a specific framework (NIST, CIS, FedRAMP, CMMC, PCI DSS, or the Essential Eight) generally keep Secure as the baseline and import the matching policy pack alongside it.