PCI DSS for containers and Kubernetes

Trivy is an Apache-2.0 scanner that examines container images, Kubernetes clusters, infrastructure as code files, secrets and software licenses. In a cardholder data environment it is most useful as the build-time and periodic check that shows you know what is inside your images and manifests before they run. Its output, typically a report per image or cluster scan, can serve as dated evidence for vulnerability review and configuration checks.

• Image scans: Run against each image in your registry and record the image digest, scan date and findings, so the report ties to exactly one artifact.
• Cluster scans: Assess running Kubernetes resources for known vulnerabilities and misconfigurations, which supports reviews of configuration standards.
• Infrastructure as code checks: Flag misconfigurations in manifests and templates before they reach the cluster, a useful input for configuration standards.
• Secrets and licenses: Detect exposed credentials and license issues, but triage is yours; a detected secret still needs rotation and a record.
• Still your decision: Severity thresholds that block a build, who may accept a risk, how long accepted findings stay open and where reports are retained.

Confirm current scanner coverage, output formats and database update behavior against the Trivy repository README before you design your evidence trail.

Kyverno is an Apache-2.0 policy engine that runs at Kubernetes admission. It can validate resources against rules, mutate them to add required settings, generate supporting resources, remove resources, and verify container image signatures. For a cardholder data environment, admission policies are how a documented configuration standard becomes something the cluster enforces rather than something people are asked to remember.

• Validation policies: Reject workloads that run privileged, mount host paths or omit required labels, giving you a reviewable rule set tied to your standard.
• Mutation policies: Add defaults such as security contexts or resource settings. Assessors will want to know exactly what the policy changes.
• Image verification: Admit only images that meet your signing or provenance rules, which supports change and software control reviews.
• Policy reports: Kyverno can record pass and fail results per resource, which is evidence that enforcement ran, not just that a policy file exists.
• Still your decision: Which rules are enforced versus audited, the exception process for legitimate workloads, who owns policy changes and how policy history is versioned and retained.

Confirm the current admission and reporting features against the Kyverno introduction documentation, and test each policy in audit mode before enforcing it.

Falco is an Apache-2.0 runtime detection tool. It parses Linux system calls, by default through an eBPF probe, and evaluates them against YAML rules. It flags events such as privilege escalation, unauthorized file modification, unexpected network connections and suspicious process execution, then enriches each alert with container and Kubernetes metadata. For a cardholder data environment it provides the runtime detection layer that admission controls cannot see once a workload is running.

• Rule-based detection: Rules for privilege escalation, file changes and unexpected network activity map to the threats your container risk assessment identifies.
• Metadata enrichment: Alerts carry container and pod context, so responders can identify the workload without manual lookup.
• Alert outputs: Alerts can go to stdout, files, syslog, HTTP endpoints or programs, which determines where your evidence actually lives.
• Tuning records: Rule changes and suppressions should be documented, since an unreviewed suppression is a gap an assessor will ask about.
• Still your decision: Alert routing to a monitored queue, who triages and how quickly, retention of alert records, and the response procedure for confirmed events.

Confirm supported kernels, the eBPF driver requirements and current output options against the Falco documentation before committing to a deployment model.

The organization that stores, processes or transmits cardholder data owns its PCI DSS obligations, including every control that runs on its container platform. Ownership covers the decisions that no outside party can make for it: which systems are in scope, which risks are accepted, which compensating or customized approaches are justified, and how alerts are answered when they fire. The organization also has to keep the controls working after any engagement ends, because PCI DSS is assessed on what runs in production, not on what was delivered.

• Scope and risk decisions: Deciding which clusters, namespaces, registries and CI pipelines touch the cardholder data environment, and recording the reasoning.
• Policy and standards: Approving the configuration standards for nodes, clusters and images, and the policies that define who may change them.
• Alert response: Staffing the people and on-call process that triage runtime detections, scanner findings and admission denials.
• Vulnerability and exception management: Owning the remediation decisions, deadlines and any documented exceptions.
• Operations after handover: Running upgrades, rotating credentials, reviewing access and keeping inventories current.

Before engaging anyone, confirm internally who signs the evidence and who answers to the assessor for each control.

An implementation partner such as DeployOpen plans, builds and hardens the self-hosted platform inside the client's own cloud accounts or data centers, then prepares the configuration, scanning and evidence that the organization and its assessor will review. The partner works to a written scope with agreed deliverables. It does not own the controls, does not decide scope, and does not issue reports, attestations or certificates. Only the independent QSA or assessor performs that role. Hiring a partner does not guarantee a compliant result or a favorable assessment.

• Platform build: Deploying Kubernetes, the container runtime and supporting components according to a documented configuration standard.
• Hardening and admission policy: Configuring cluster settings and policy engines such as Kyverno so non-conforming workloads are blocked or flagged.
• Scanning and runtime detection: Setting up image and cluster scanning with Trivy and runtime rules with Falco, and wiring their output to the client's alerting.
• Evidence preparation: Producing configuration files, scan reports, change records and architecture diagrams in a form the assessor can sample.
• Documentation and handover: Writing runbooks and recording which controls the client must still operate.

Ask for the written scope, the list of deliverables and the named evidence before work starts, and confirm that the partner's role excludes any validation activity.

A Qualified Security Assessor (QSA) or other assessor independent of the implementation work tests the environment and documents the result. For organizations that need a Report on Compliance, the QSA completes the ROC, and for those that qualify for a Self-Assessment Questionnaire, the SAQ is completed and signed with an Attestation of Compliance. The assessor decides whether each requirement is met, using samples of configurations, logs, scan results and interviews. Certificates are not accepted as validation under PCI DSS, so the AOC or ROC is the document that counts.

• Independent testing: Sampling running clusters, images and policies rather than relying on documents alone.
• Reporting: Issuing the ROC or completing the SAQ and AOC on official PCI SSC templates.
• Compensating and customized approaches: Judging whether an alternative control meets the stated objective, with the supporting analysis supplied by the organization.
• Changes during the year: Reviewing whether significant changes to the cardholder data environment affect scope.
• Scope confirmation: Agreeing the scope with the organization before testing begins.

Confirm early which assessor is needed for your validation type, and whether the assessor has agreed to rely on the evidence you plan to provide.