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).