Policy Packs

1 - Secure

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:

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 affected or under_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.

2 - NIST

The NIST policy packs map the NIST SP 800-53 security controls and the NIST SP 800-190 Application Container Security Guide to checks that the Anchore Enterprise policy engine can evaluate against container images and SBOMs.

Current NIST policy pack versions: Anchore NIST 800-53r5 v2026.2 and Anchore NIST 800-190 v2026.1

Introduction

The National Institute of Standards and Technology (NIST) is a non-regulatory agency of the U.S. Commerce Department that provides industry standards and guidelines to help federal agencies meet requirements set by the Federal Information Security Management Act (FISMA).

Anchore Enterprise provides two NIST policies:

• NIST 800-53: a catalog of security and privacy controls for the U.S. Federal Government. These controls are also the foundation of FedRAMP, the Joint Special Access Program (SAP) Implementation Guide (JSIG), and Intelligence Community Directive (ICD) 503. Anchore Enterprise helps security teams meet the subset of these controls that can be evaluated against container and SBOM content.
• NIST 800-190: the Application Container Security Guide, which describes security concerns with container technologies and recommendations to address them across the container lifecycle.

Anchore also covers NIST 800-218 (SSDF) through the SSDF Attestation Form Guide and Evidence document. See SSDF.

NIST 800-53

Anchore Enterprise checks for the following control specifications against container images. Rule sets marked Required in the Configuration column ship with placeholder values and must be configured for your environment before the policy is used. See Configure Rule Sets.

Three rule sets are bound to the SBOM mapping, so the RA-5 checks apply whether you scan an image or import an SBOM directly: RA-5 Vulnerability Scan - SBOM, RA-5 Vulnerability on KEV list - SBOM, and RA-5 specific CVE [CONFIGURE] - SBOM.

NIST 800-190

Anchore Enterprise checks for the following control specifications in the NIST 800-190 policy, which is bound to container images only.

Each 800-190 rule set carries the equivalent 800-53 control in its description, so a finding traces to both frameworks at once.

VEX Annotations

The vulnerability rule sets in both packs are 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 affected or under_investigation, so vulnerabilities you have assessed as genuinely exploitable keep counting.

Findings annotated not_affected or fixed match neither rule, so an accurate VEX assessment clears them from the evaluation without an allowlist entry, and the compliance result refreshes as soon as the annotation is saved. The configuration, privilege, secret, malware, and feed-currency rule sets do not depend on annotation state.

Use the Pack

Import the pack like any other policy. See Manage Policies for the GUI, AnchoreCTL, and API workflows. Once imported, scope it to the registries and repositories it should apply to through Policy Mappings, then activate it as the account’s default policy.

Configure Rule Sets

The rule sets marked Required in the tables above ship with placeholder values: an allowed port of 123456, a denied package of opensshd, an example CVE ID, a sample trusted-registry list, and a placeholder configuration file and checksum. Each is tagged [CONFIGURE] in its rule set name in the GUI. Edit them from the policy’s Edit action in the Anchore Enterprise GUI (see Manage Policies) before you rely on the pack’s results.

2.1 - SSDF

In February 2021, The National Institute of Standards and Technology (NIST) created NIST SP 800-218, otherwise known as Secure Software Development Framework (SSDF), in response to a new executive order mandated by the federal government.

SSDF provides a comprehensive set of guidelines aimed at integrating security into the software development lifecycle, thereby enhancing the security posture of software products from inception to deployment. To verify and validate that organizations meet the controls needed to be SSDF compliant, CISA created an official SSDF Attestation Form that allows organizations to verify and attest that they adhere to the SSDF guidelines and comply with a subset of security controls.

Purpose

Anchore provides a downloadable document that serves as an evidence attachment for the SSDF Attestation Form. The document makes the assumption Anchore Enterprise is used in the organization’s environment and is configured to scan the software that is in scope for the SSDF Attestation Form.

The SSDF Attestation Form consists of three sections that must be completed. Sections I and II cover organization-specific details, whereas Section III lists requirements against various security controls. The intent of this document is to provide guidance for first time applicants and help organizations save time collecting evidence required for Section III of the SSDF Attestation Form.

Download

Detailed instructions to complete the form can be found on page 1. This document uses the official SSDF Attestation Form as its base template. Once completed, the document can be directly attached to an SSDF Attestation Form submission. Click below to obtain the form:

Additional Resources

1. SSDF Attestation 101: A practical guide for Software Producers - Download eBook
2. Using the Common Form for SSDF Attestation: What Software Producers Need to Know - Read blog
3. Automate NIST compliance and SSDF attestation with Anchore Enterprise - Learn more

If you want to contact one of our experts, please contact us.

3 - CIS

The Center for Internet Security (CIS) provides prescriptive configuration recommendations for a variety of software vendors. Anchore Enterprise’s CIS policy pack is based on the CIS Docker 1.8 Benchmark and validates a subset of security and compliance checks against container images.

Current CIS policy pack version: Anchore CIS Docker Benchmark V1.8.0 v2026.1

Introduction

The Center for Internet Security is a nonprofit that publishes consensus-developed configuration baselines, the CIS Benchmarks, for operating systems, cloud platforms, and container runtimes. They are widely used as the reference hardening standard in audits and contracts, and other frameworks frequently point at them rather than restating the same configuration guidance.

The Docker Benchmark is organized by where a control applies: host configuration, daemon configuration and files, container images and build files (section 4), container runtime (section 5), and security operations. This pack implements the section 4 controls, which are evaluated against image and Dockerfile content, plus 5.8 on privileged port mapping. The host, daemon, and runtime sections describe the machine a container runs on rather than the artifact itself and are out of scope for an image policy.

Controls

Anchore Enterprise checks for the following control specifications in the CIS policy. Rule sets marked Required in the Configuration column must be configured for your environment before the policy is used. See Configure Rule Sets.

Use the Pack

Import the pack like any other policy. See Manage Policies for the GUI, AnchoreCTL, and API workflows. Once imported, scope it to the registries and repositories it should apply to through Policy Mappings, then activate it as the account’s default policy.

Configure Rule Sets

The control specifications marked Required in the table above need configuration for your environment. The control specifications are represented by rule sets, edited from the policy’s Edit action in the Anchore Enterprise GUI (see Manage Policies).

4 - FedRAMP

The FedRAMP policy packs map the FedRAMP Rev 5 vulnerability scanning requirements and the FedRAMP 20x Key Security Indicators to checks that the Anchore Enterprise policy engine can evaluate against container images and SBOMs.

Current FedRAMP policy pack versions: Anchore FedRAMP v5 Checks v2026.3 and Anchore FedRAMP 20x v2026.2

Introduction

FedRAMP (Federal Risk and Authorization Management Program) is a standardized approach for assessing, authorizing, and monitoring cloud service providers (CSPs) that provide service to federal agencies. Through a rigorous and comprehensive process, FedRAMP ensures that CSPs meet security standards by providing a baseline set of security controls to enhance the overall security of federal information systems.

Anchore Enterprise’s FedRAMP policy validates whether container images are compliant with the FedRAMP Vulnerability Scanning Requirements, and validates them against the FedRAMP controls specified in NIST 800-53 Rev 5 and NIST 800-190. The policy checks only the specification requirements relevant to software supply chain security.

FedRAMP Rev 5

Anchore Enterprise’s FedRAMP Rev 5 policy checks for the following specifications. Rule sets marked Required in the Configuration column must be configured for your environment before the policy is used. See Configure Rule Sets.

An RA-5 SI-02 vulnerability scan remediation rule set is bound to the SBOM mapping, so the RA-5 vulnerability checks apply to imported SBOMs as well as scanned images. The remaining rule sets evaluate image content and are bound to the container mapping only.

The RA-5 SI-02(2) RISK ASSESSMENT rule set is VEX-aware: its vulnerability rules are split so that un-annotated findings and findings annotated affected or under_investigation both match, while findings annotated not_affected or fixed match neither. See Annotations and VEX.

FedRAMP 20x

FedRAMP 20x replaces the Rev 5 control-by-control narrative with Key Security Indicators (KSIs), outcome statements a cloud service offering must demonstrate, and a Vulnerability Detection and Response (VDR) standard governing how providers find and act on vulnerabilities. The Anchore FedRAMP 20x pack implements the Class C indicators that are reachable from container and SBOM content.

Two rule sets are bound to the SBOM mapping: VDR-CSO-AKE SBOM, which applies the KEV gate to imported SBOMs, and KSI-SCR-MIT - SBOM, which fails supply chain findings that have a fix available or appear on the KEV catalog.

VEX Annotations

The VDR rule sets act on VEX annotation state, as described in Annotations and VEX. They match findings annotated affected or under_investigation, so a finding assessed as not_affected or fixed drops out of the evaluation as soon as the annotation is saved.

This pairing matters more under 20x than under Rev 5: the VDR standard expects a provider to show a continuous detection and response process, and an annotation records the assessment and its justification as evidence rather than simply muting the finding. The KSI rule sets, which evaluate image configuration rather than vulnerabilities, do not depend on annotation state.

Use the Pack

Import the pack like any other policy. See Manage Policies for the GUI, AnchoreCTL, and API workflows. Once imported, scope it to the registries and repositories it should apply to through Policy Mappings, then activate it as the account’s default policy.

Configure Rule Sets

The control specifications marked Required in the table above need configuration for your environment. The control specifications are represented by rule sets, edited from the policy’s Edit action in the Anchore Enterprise GUI (see Manage Policies).

5 - DoD

The DoD policy packs map the DISA Container Image Creation and Deployment Guide and the Platform One IronBank requirements to checks that the Anchore Enterprise policy engine can evaluate against container images.

Current IronBank policy pack version: Anchore DoD Iron Bank v2026.1

Current DISA policy pack version: Anchore DISA Image Creation and Hardening Guide v20241001

Introduction

Anchore Enterprise provides two DoD policies:

• DISA Image Creation and Deployment Guide: provided by the Defense Information Systems Agency (DISA), the agency that supplies IT and communications support to the U.S. government and federal organizations. This policy provides security and compliance checks that align with specific NIST 800-53 and NIST 800-190 controls as described in the DoD Container Image Creation and Deployment Guide.
• IronBank: validates images against DoD security and compliance requirements in alignment with U.S. Air Force security standards at Platform One and IronBank, written in accordance with DoD Enterprise DevSecOps Reference Design documentation.

DISA

Anchore Enterprise checks for the following control specifications in the DISA policy. Rule sets marked Required in the Configuration column must be configured for your environment before the policy is used. See Configure Rule Sets.

IronBank

The IronBank policy includes checks across the following areas:

Use the Pack

Import the pack like any other policy. See Manage Policies for the GUI, AnchoreCTL, and API workflows. Once imported, scope it to the registries and repositories it should apply to through Policy Mappings, then activate it as the account’s default policy.

Configure Rule Sets

The IronBank policy does not require rule set configuration. The DISA policy, however, requires configuration for the control specifications marked Required in the DISA table above. The control specifications are represented by rule sets, edited from the policy’s Edit action in the Anchore Enterprise GUI (see Manage Policies).

6 - CMMC

The CMMC policy pack maps the controls of the Cybersecurity Maturity Model Certification (CMMC) to checks that the Anchore Enterprise policy engine can evaluate against container images. The pack is grounded in NIST SP 800-171r3, the security-requirement publication from which CMMC draws its control set, and ships as a single bundle ready to import as a policy.

Current CMMC policy pack version: Anchore CMMC - NIST 800-171r3 v2026.2

Introduction

CMMC is the U.S. Department of Defense’s certification program for the Defense Industrial Base, the contractors and subcontractors that build, deliver, and support systems for the DoD. It exists because the DoD’s sensitive unclassified information lives largely on contractor networks, and self-attestation alone proved a weak assurance that it was protected there.

The program is tiered by the sensitivity of the information a contract involves. Contracts touching Federal Contract Information (FCI) sit at the lowest tier, while contracts involving Controlled Unclassified Information (CUI) require the full NIST SP 800-171 security requirements, assessed rather than self-asserted. CMMC requirements flow down through the supply chain: a subcontractor handling CUI on a prime’s behalf carries the same obligation the prime does.

For organizations delivering software, this lands squarely on the build pipeline. Container images that process, store, or transmit CUI are in scope, as is the infrastructure that produces them. The least-privilege, unauthorized-software, secrets, malware, and vulnerability-management requirements therefore have to be demonstrable against the artifacts themselves, not just described in a system security plan. That is the evidence this pack produces: each rule set is named for the 800-171r3 requirement it supports, so a policy evaluation maps directly onto the control an assessor is asking about.

Controls

Anchore Enterprise checks for the following control specifications against container images. Rule sets marked Required in the Configuration column ship with placeholder values and must be configured for your environment before the policy is used. See Configure Rule Sets.

VEX Annotations

The 03.11.02 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 affected or under_investigation, so vulnerabilities you have assessed as genuinely exploitable keep counting.

Findings annotated not_affected or fixed match neither rule, so an accurate VEX assessment clears them from the evaluation without an allowlist entry, and the compliance result refreshes as soon as the annotation is saved. This matters for an assessment conversation: the evidence shows which findings were reviewed and dismissed with a justification, rather than suppressed.

The other rule sets (least privilege, port exposure, unauthorized software, secrets, malware, and feed currency) do not depend on annotation state.

SBOM Rule Sets

The pack ships three 03.11.02 rule sets bound to the SBOM mapping, so vulnerability checks apply whether you scan an image or import an SBOM directly: 03.11.02 vulnerability scan - SBOM, 03.11.02 vulnerability fix available - SBOM, and 03.11.02 specific CVE [CONFIGURE] -SBOM.

The remaining controls depend on image content and are bound to the image mapping only. The SBOM rule sets do not always use the same action as their image counterpart, so review them alongside the image rule sets after import.

Allowed and Denied Images

The bundle also ships example deployment-wide image overrides, which force an image’s final result regardless of the rest of the evaluation, as described in Allowed / Denied Images:

These are placeholders. Replace them with your own approved and prohibited registries before activating the pack. As shipped, the docker.io entry fails every image pulled from Docker Hub.

Use the Pack

Import the pack like any other policy. See Manage Policies for the GUI, AnchoreCTL, and API workflows. Once imported, scope it to the registries and repositories it should apply to through Policy Mappings, and attach any allowlists you need before activating it as the account’s default policy.

The CMMC pack is intended as a starting point. Most teams customize mappings, attach allowlists for accepted risks, or layer additional rule sets on top before activating the pack against production registries.

Configure Rule Sets

The rule sets marked Required in the table above ship with placeholder values that stand in for values only you can supply: an allowed port of 123456, a denied package of opensshd, and an example CVE ID. Each is tagged [CONFIGURE] in its rule set name in the GUI. Edit them from the policy’s Edit action in the Anchore Enterprise GUI (see Manage Policies) before you rely on the pack’s results.

7 - ASD Essential 8

The ASD Essential 8 policy pack maps the Australian Signals Directorate’s Essential Eight mitigation strategies to checks that the Anchore Enterprise policy engine can evaluate against container images and SBOMs. The pack covers Maturity Levels 1 through 3 and ships as a single bundle ready to import as a policy.

Current ASD Essential 8 policy pack version: Anchore ASD Essential 8 Level 1-3 v2026.1

Introduction

The Essential Eight is a set of eight mitigation strategies published by the Australian Signals Directorate as a baseline against the attacks it sees most often. Implementation is mandatory for Australian federal government entities and widely adopted by state agencies, critical infrastructure operators, and their suppliers. Progress is measured in maturity levels, tiered against increasingly capable adversary tradecraft; every rule set in this pack applies at Maturity Levels 1 through 3.

Four of the eight strategies are reachable from container image content: patch applications, patch operating systems, restrict administrative privileges, and application control. The rest (application hardening, macro settings, multi-factor authentication, and backups) depend on organizational process or runtime configuration and are not represented in the bundle. Rule sets are named by strategy and ISM control identifier, so a finding maps straight back to the control it supports.

Controls

Anchore Enterprise checks for the following control specifications against container images. The rule set marked Required in the Configuration column ships with a placeholder value and must be configured for your environment before the policy is used. See Configure Rule Sets.

The two patching timelines the Essential Eight sets out are split across the rule sets rather than expressed in one: the 48-hour requirement for critical vulnerabilities and working exploits is enforced as an immediate failure (ISM-1876, ISM-1877, and the KEV rule sets), while the two-week requirement for non-critical vulnerabilities is enforced through the max_days_since_fix threshold in ISM-1690 and ISM-1694.

VEX Annotations

Every vulnerability rule set in this pack is 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 fail the policy.
• The other matches findings annotated affected or under_investigation, so vulnerabilities you have assessed as genuinely exploitable keep failing it.

Findings annotated not_affected or fixed match neither rule. Recording an accurate VEX assessment therefore clears the finding from the evaluation without an allowlist entry, and the compliance result refreshes as soon as the annotation is saved. The non-vulnerability rule sets (feed currency, effective user, and application control) do not depend on annotation state.

SBOM Rule Sets

The pack ships parallel rule sets bound to the SBOM mapping, so the patching strategies apply to imported SBOMs as well as scanned images: Patch Applications ISM-1690 - KEV (SBOM), Patch Applications ISM-1876 (SBOM), Patch Applications ISM-1690 (SBOM), Patch OS ISM-1877 (SBOM), and Patch OS ISM-1694 (SBOM). They carry the same VEX rule pairing as their image counterparts.

Restrict administrative privileges, application control, and the feed-currency checks depend on image content or deployment state and are bound to the image mapping only.

Use the Pack

Import the pack like any other policy. See Manage Policies for the GUI, AnchoreCTL, and API workflows. Once imported, scope it to the registries and repositories it should apply to through Policy Mappings, and attach any allowlists you need before activating it as the account’s default policy.

The ASD Essential 8 pack is intended as a starting point. Most teams customize mappings, attach allowlists for accepted risks, or layer additional rule sets on top before activating the pack against production registries.

Configure Rule Sets

Application Control - ISM-1657 ships with a placeholder denied package, openssh at version 1.0.1, that stands in for the organization-approved software set the control calls for. It is tagged [CONFIGURE] in its rule set name in the GUI. Replace the placeholder with the packages you prohibit, using the policy’s Edit action in the Anchore Enterprise GUI (see Manage Policies), before you rely on the pack’s results.

The pack’s other rule sets are usable as shipped, though the two feed-currency thresholds (7 days) and the two patch-age thresholds (14 days) are worth reviewing against the scanning cadence and maturity level you are certifying to.

8 - PCI DSS

The PCI DSS policy pack maps the internal vulnerability-scanning requirements of the Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 to checks that the Anchore Enterprise policy engine can evaluate against container images. The pack targets requirement 11.3.1, internal vulnerability scans, and ships as a single bundle ready to import as a policy.

Current PCI DSS policy pack version: Anchore PCI 4 requirement 11.3.1 2026.1

Introduction

PCI DSS is the security standard maintained by the PCI Security Standards Council on behalf of the major payment card brands. It applies to any organization that stores, processes, or transmits cardholder data: merchants, payment processors, acquirers, issuers, and the service providers that support them. Unlike a government regulation, it is enforced contractually: card brands and acquiring banks require compliance as a condition of processing payments, validated annually through a Report on Compliance or a Self-Assessment Questionnaire, with the depth of validation scaled to transaction volume.

Scope is defined by the cardholder data environment (CDE): every system component that handles cardholder data, plus anything connected to or able to affect the security of those systems. For teams delivering payment software in containers, that pulls the images themselves into scope, along with the pipeline that builds them.

Requirement 11.3.1 is the internal vulnerability scanning requirement: scans run at least every three months and after any significant change, with high-risk and critical vulnerabilities resolved and rescans performed to confirm it. Sub-requirement 11.3.1.1 covers everything below that bar: all other applicable vulnerabilities, managed on the schedule set by the entity’s targeted risk analysis. That split is the shape of this pack: high-risk findings fail an evaluation outright, and the rest surface as warnings for triage rather than being discarded.

Controls

Anchore Enterprise checks for the following control specifications against container images:

The three 11.3.1 rule sets implement the requirement’s vulnerability ranking three ways (by severity, by KEV listing, and by EPSS score) and evaluate together, so an image fails if any one of them matches. The 11.3.1.c rule sets cover the requirement that scans be run with a current tool: a scan performed against missing or stale feed data fails rather than passing silently.

VEX Annotations

The four 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 fail the scan.
• The other matches findings annotated affected or under_investigation, so vulnerabilities you have assessed as genuinely exploitable keep failing it.

Findings annotated not_affected or fixed match neither rule. For requirement 11.3.1 this is the difference between an allowlist and an assessment: a VEX annotation records why a high-risk finding does not apply to your product, carries a justification with it, and travels into the VEX document an assessor can review, rather than simply muting the finding.

The two 11.3.1.c feed-currency rule sets do not depend on annotation state.

SBOM Rule Sets

The pack ships parallel rule sets bound to the SBOM mapping, so the scanning requirement is met whether you scan an image or import an SBOM directly: 11.3.1 Internal vulnerability scan (sbom), 11.3.1 Internal vulnerability scan KEV (sbom), 11.3.1 Internal vulnerability scan EPSS (sbom), and 11.3.1.1 Internal vulnerability scan (sbom). They carry the same VEX rule pairing as their image counterparts.

The 11.3.1.c feed-currency checks are bound to the container mapping only.

Use the Pack

Import the pack like any other policy. See Manage Policies for the GUI, AnchoreCTL, and API workflows. Once imported, scope it to the registries and repositories it should apply to through Policy Mappings, and attach any allowlists you need before activating it as the account’s default policy.

The PCI DSS pack is intended as a starting point. Most teams customize mappings, attach allowlists for accepted risks, or layer additional rule sets on top before activating the pack against production registries.

Tune the Thresholds

No rule set in this pack requires configuration before use, but three thresholds are worth reviewing against your own scanning program:

• The EPSS threshold of 0.75 decides which vulnerabilities are treated as high-risk on exploit probability rather than severity.
• The 2-day feed-sync limit in the 11.3.1c Outdated Feed Data rule set should be no longer than the interval your deployment actually syncs feeds, or the check will not catch a stalled sync.
• The high-severity boundary splits requirement 11.3.1 from sub-requirement 11.3.1.1: vulnerabilities at or above it fail, everything below warns. Adjust both rule sets together if you move it.

Edit any of these from the policy’s Edit action in the Anchore Enterprise GUI (see Manage Policies).

9 - EU CRA

The EU CRA policy pack maps the vulnerability-handling obligations of the European Union’s Cyber Resilience Act to a check the Anchore Enterprise policy engine can evaluate against container images and SBOMs. The pack is deliberately narrow, enforcing only the Act’s requirement that products ship free of known exploitable vulnerabilities, and ships as a single bundle ready to import as a policy.

Current EU CRA policy pack version: EU-CRA 2026.1

Introduction

The Cyber Resilience Act sets cybersecurity requirements for products with digital elements placed on the EU market. It applies to manufacturers rather than operators: if you sell or distribute software or a connected product in the EU, the obligations attach to you, and CE marking depends on meeting them. That reach makes it relevant well beyond EU-based vendors: any supplier shipping into the single market is in scope.

The Act’s Annex I Part I sets out the security properties a product must have when it is made available, including that it be delivered without known exploitable vulnerabilities. Part II covers the vulnerability handling that follows: maintaining an SBOM, addressing vulnerabilities without delay, and reporting actively exploited vulnerabilities to ENISA.

This pack addresses the Annex I Part I requirement directly, using the CISA Known Exploited Vulnerabilities (KEV) catalog as the evidence that a vulnerability is exploited in practice. The wider Part II obligations are process and reporting duties rather than artifact checks, but they lean on the same machinery: the SBOMs Anchore Enterprise generates, and the VEX annotations that record how each finding was assessed.

Controls

Anchore Enterprise checks for the following control specifications against container images and SBOMs:

Both rule sets are bound to a default mapping matching every registry, repository, and tag, and both share an empty DefaultAllowlist ready for your accepted risks.

VEX Annotations

Each rule set is split into two rules that differ only in annotation state, as described in Annotations and VEX:

• One rule matches KEV findings that carry no annotation yet, so un-triaged exploitable vulnerabilities fail the evaluation.
• The other matches KEV findings annotated affected or under_investigation.

Findings annotated not_affected or fixed match neither rule. This is the mechanism that makes a narrow KEV gate workable under the CRA: a KEV-listed vulnerability whose code is not reachable in your product is assessed, justified, and cleared from the evaluation, and the assessment travels into the VEX document a downstream consumer or market surveillance authority can read.

Use the Pack

Import the pack like any other policy. See Manage Policies for the GUI, AnchoreCTL, and API workflows. Once imported, scope it to the registries and repositories it should apply to through Policy Mappings, and attach any allowlists you need before activating it as the account’s default policy.

Because the pack enforces a single requirement, most teams run it alongside a broader policy, such as the Secure pack or a framework pack, rather than as their only active policy.