How Red Hat’s Risk-based Vulnerability Management methodology aligns to PCI DSS v4

Disclaimer

This document is provided for informational purposes only and is intended to outline Red Hat's alignment with relevant requirements in the Payment Card Industry Data Security Standard (PCI DSS) v4. It describes relevant Red Hat controls and practices as of the publication date and should not be considered a guarantee of PCI DSS compliance. Information provided is subject to change without notice. For specific guidance and clarification regarding your organization’s compliance obligations, it is recommended to consult a PCI DSS Qualified Security Assessor (PCI QSA).

Introduction

The PCI DSS v4 introduces significant updates, demanding a refined approach to vulnerability management. This document will help navigate the complexities of PCI DSS v4 compliance, clarifying Red Hat’s role in supporting your organization’s security posture and providing strategies for effectively managing critical and non-critical vulnerabilities within your ecosystem. This whitepaper leverages Red Hat’s first-hand experience from ongoing Red Hat OpenShift Dedicated (OSD) and Red Hat Openshift on AWS (ROSA) engagements with PCI QSAs to provide actionable insights supporting your organization’s PCI DSS v4 compliance. Key areas such as system scoping, shared responsibility models, risk-based vulnerability management, security patching, vulnerability scanning (internal and external), and penetration testing requirements are discussed along with practical guidance on meeting compliance objectives.

Customers often express concerns about meeting the stringent requirements of PCI DSS audits, especially regarding the timely remediation of unpatched vulnerabilities. Red Hat's approach to vulnerability management, detailed in "An Open Approach to Vulnerability Management," aligns with the PCI DSS risk-based model. This document explains how Red Hat addresses key PCI DSS v4.0 requirements and how leveraging a risk-based assessment model, aligned with Red Hat's vulnerability ratings and scores, can help organizations improve their PCI audit outcomes and reduce escalations related to unaddressed vulnerabilities. Organizations often face challenges navigating these requirements, including:

  • Defining Scope and Shared Responsibility: Clearly identifying which systems and environments fall under PCI DSS regulations and delineating security responsibilities, especially when using Third-Party Service Providers (TPSPs) like Red Hat (Requirements 12.5, 12.9).
  • Managing Vulnerabilities Based on Risk: Implementing processes to identify, rank (Requirement 6.3.1), and address (Requirement 6.3.3) vulnerabilities according to their actual risk, rather than just patching everything immediately.
  • Meeting Scan and Test Requirements: Performing regular internal and external vulnerability scans (Requirement 11.3) and penetration tests (Requirement 11.4) and addressing the findings appropriately.
  • Demonstrating Compliance to Auditors: Providing clear documentation and evidence, including Targeted Risk Analyses (TRAs) (Requirement 12.3.1), to justify vulnerability management decisions and timelines (SLAs).

Detailed testing procedures and guidance for each requirement are available in the PCI DSS official documentation.

Red Hat’s alignment to PCI DSS v4 requirements

Red Hat products and vulnerability management practices are designed to help customers meet PCI DSS v4 requirements, which emphasize risk ranking and TRAs for vulnerability management. The Red Hat approach to vulnerability management is practiced 24/7 internally for all security matters and products, is extensively documented publicly, and is regularly audited as part of relevant external audit programs.

Risk-based approach to vulnerability management

To support customers in their risk-based approach to assessing, documenting, rating, managing, and addressing vulnerabilities in Red Hat software, they can leverage Red Hat’s Product Security Vulnerability Management processes and documentation. This reduces the need for customers to independently conduct risk analysis of Red Hat software. As required within a TRA, Red Hat evaluates, documents, and manages vulnerabilities according to their risk, prioritizing remediation based on severity and impact. This enables customers to focus system upgrades on critical and high-risk items while addressing other risks according to their operational needs and provides insight into threats against the Cardholder Data Environment (CDE) for informed security decisions. The TRA formally identifies, evaluates, and manages CDE risks, balancing security with practicality for evidence-based compliance. It justifies flexible control frequency based on risk profile, threat landscape, and business context. TRA requirements include managing vulnerabilities (not all require immediate fixes based on risk), security patching and updates, and various testing.

Red Hat analyzes vulnerability risks in its software by rating the severity of Common Vulnerabilities and Exposures (CVEs). This involves a four-tier severity scale (Low, Moderate, Important, Critical) and a Common Vulnerability Scoring System (CVSS) base score. Red Hat's CVSS scores and impact ratings may differ from the NVD and other vendors because they consider Red Hat specific factors like software version, build process and usage. For each CVE, Red Hat provides details in affected products and packages, risk impact, its assessed CVSS score, a risk description, mitigation steps, and the current status (e.g., not affected, fixed). This vendor-specific context is important because Red Hat's CVSS and impact ratings are tailored to its products' build, configuration, and typical usage, offering a more relevant risk assessment for Red Hat environments.

Red Hat CVE Database provides this information, including the status and links to errata (patches), enabling prioritized risk assessment for effective upgrade and patching decisions aligned with an organization's specific risks. Red Hat, as an authoritative https://www.cve.org/Media/News/item/blog/2025/02/25/Red-Hat-Root-Adds-CNA-LR, maintains a complete list of CVEs affecting its software. By providing this systematic CVE information, Red Hat equips customers with all necessary details, including prioritized risk scores and impact ratings, for their TRA to demonstrate PCI DSS compliance to auditors. Customers can directly adopt Red Hat’s assessment or enhance it with their own environmental and use-case considerations.

Vulnerability Scans

A vulnerability scan uses automated tools to identify potential weaknesses in systems, applications, and networks that can be exploited by attackers. PCI DSS v4 identifies two types of vulnerability scans: internal and external scans. For both of these vulnerability scan types, a TRA provides vulnerability management justification which includes vulnerability remediation timeframes and defined rescan frequency. This justification is key in setting expectations for critical and non-critical (risk) evaluated vulnerabilities, and PCI DSS audit assessors will evaluate adherence to TRA for vulnerability management.

Internal vulnerability scanning

Internal scans are conducted from within the CDE’s logical perimeter on all internal-facing hosts that are within or with incoming connections to the CDE. Requirement 11.3.1 mandates internal vulnerability scans at least every 3 months or after any significant change (11.3.1.2), using approved scanning tools by qualified internal personnel or by an approved third-party vendor. Based on a justifiable TRA, High and Critical vulnerabilities must be addressed and rescanned to confirm remediation, while Medium(Moderate)/Low vulnerabilities must be managed per guidance in 6.3.1 and documented by a TRA under 12.3.1. Customers receive all necessary TRA information for their auditor, including Red Hat's CVE scores and impact ratings for applicable PCI DSS products, outlining the associated risks.

External vulnerability scanning

External vulnerability scans, as required by 11.3.2, must be performed quarterly by a PCI DSS Approved Scanning Vendor (ASV). These scans are conducted over the internet from outside the CDE perimeter to test all internet-facing hosts within the CDE perimeter or connected systems with a logical path incoming to the CDE. PCI DSS v4.0 mandates these quarterly external scans by an ASV, and vulnerabilities (typically CVSS >=4.0) must be addressed per the ASV Program Guide until a passing scan is achieved. External scans carry a higher risk if exploited, so all vulnerabilities with a CVSS score ≥ 4.0 must be resolved, with rescans until a passing report is achieved per the ASV Program Guide. While a TRA is required for any risk found in the CDE, external scans have stricter remediation guidelines, which should be considered when planning analyses, patching, and rescans. Rescans that show that the remediated vulnerabilities no longer exist for the CDE.

Red Hat’s Vulnerability and Incident Response Plan (VIRP)

The Red Hat's Vulnerability and Incident Response Plan (VIRP) meets the PCI DSS scope and responsibility requirements. The VIRP outlines the formal, structured process for addressing all reported or discovered security vulnerabilities affecting Red Hat software, encompassing comprehensive analysis, coordinated remediation, and, where required, appropriate incident response and disclosure of affected software.

Software patch management

PCI DSS requires that security patches are applied in a reasonable timeframe based on a risk-based approach. Red Hat’s Software lifecycle support policy ensures fixes for Red Hat-rated Critical and Important CVEs as soon as they are available. Patching for other applicable vulnerabilities, as mentioned in 11.3.1.1, is addressed within our risk-based vulnerability management process, aligning with requirement 12.3.1 to define the frequency of applying other applicable patches based on the risk criticality assessed during the vulnerability management process(equivalent to a TRA). Red Hat provides multiple channels for software patch notifications, including routine errata releases, accompanied by comprehensive documentation on the Red Hat Product Errata page on the Red Hat Customer Portal:

The Red Hat Product Security Center offers comprehensive security incident guidance, supported product releases, versions, patches and subscriptions for advisories and notifications.

Penetration testing within Secure Software Development Lifecycle (SDLC)

Red Hat maintains a Secure Software Development Life Cycle (SDLC) process that includes risk assessment, vulnerability management, and security testing protocols for its software. This process aligns with the NIST SP 800-218 Secure Software Development Framework (SSDF) v1.1, which guides customer expectations and market requirements for secure development practices. Executive summary reports from the SDLC penetration tests are available upon request to support PCI DSS compliance. In addition to penetration testing, Red Hat also includes security architecture reviews, build pipeline and supply chain evaluations, threat modeling, Static and Dynamic Application Security Testing (SAST/DAST), and anti-malware scanning security practices throughout the SDLC. SDLC incorporates comprehensive security practices to meet required security criteria prior to Red Hat software general availability release.

Conclusion

PCI DSS v4 refines information security and vulnerability management processes, changing how vulnerability scanning and penetration testing are documented and executed. These changes emphasize a risk-based approach to addressing vulnerabilities, using Targeted Risk Analysis for repeatable risk ranking and management. This aligns with Red Hat's long-standing security philosophy. Our annual Red Hat Product Security Risk Report consistently demonstrates the effectiveness of prioritizing Critical and Important vulnerabilities. The 2024 report further supports this, showing even lower exploitation rates for Low and Moderate vulnerabilities compared to previous years. Attackers prioritize high-yield vulnerabilities, and our focus mirrors this, concentrating on Critical and Important vulnerabilities.

Red Hat software supports compliance with applicable PCI DSS requirements and serves as a strategic component of a comprehensive security program. Red Hat software can also be configured to include capabilities that facilitate alignment to some PCI DSS requirements through integrations with the system management solutions available in our portfolio. However, it should be noted that full compliance is not automatically achieved and requires a thorough review of customer-specific deployment environments. PCI DSS configuration specifications are available on the Red Hat PCI DSS Product Compliance.

Relevant PCI DSS v4 control updates have been summarized throughout this paper to bring awareness and a better understanding of what these changes are and how they can impact operations for organizations that need to meet and maintain these requirements. These summaries are for informational purposes only. For a complete list of the latest PCI DSS requirements, visit the official PCI Security Standards Council website at pcisecuritystandards.org. For specific advice, be sure to consult a PCI DSS Qualified Security Assessor (PCI QSA) for any requirement clarification.

Appendix A - PCI DSS References

PCI DSS official standards and practical implementation strategies from the PCI Security Standards Council (PCI SSC) https://www.pcisecuritystandards.org/document_library/