27.5: PCI DSS 4.0 and Software Supply Chain¶

The Payment Card Industry Data Security Standard (PCI DSS)¹ governs security for organizations that store, process, or transmit payment card data. Version 4.0, released in March 2022, became the mandatory baseline on March 31, 2024; its future-dated requirements became mandatory on March 31, 2025. The Magecart attacks that compromised British Airways (380,000 records, 2018), Ticketmaster (40,000 records, 2018), and hundreds of other organizations demonstrated that attackers increasingly target the software supply chain to steal payment credentials at scale—injecting malicious scripts into legitimate payment pages through compromised scripts, services, or components.

The British Airways breach resulted in a £20 million fine from the UK Information Commissioner's Office—at the time the largest GDPR penalty issued. The attack vector: malicious JavaScript injected into the airline's payment flow, exfiltrating customer payment card data to attacker-controlled servers. The malicious code exploited trust in scripts that the payment flow was allowed to execute. This attack pattern—compromising legitimate scripts that payment pages trust—prompted PCI DSS 4.0's new Requirement 6.4.3.

For organizations in the payment card ecosystem, PCI DSS 4.0's supply chain requirements represent both enhanced security expectations and practical compliance challenges. Requirement 6 (Develop and Maintain Secure Systems and Software) has been substantially updated, with new requirements for third-party component management and the landmark Requirement 6.4.3 requiring integrity controls for payment page scripts. Understanding these requirements—and implementing them before assessment—is essential for any organization handling payment card data.

Requirement 6: Secure Development and Supply Chain¶

PCI DSS Requirement 6 addresses secure development practices, vulnerability management, and protection of systems and software. Version 4.0 significantly expands supply chain security coverage throughout this requirement.

Requirement 6.2: Bespoke and Custom Software Security

Requirement 6.2 mandates secure development practices for bespoke and custom software, including:

• 6.2.1: Developing bespoke and custom software securely according to industry standards and PCI DSS requirements
• 6.2.2: Training software development personnel at least once every 12 months in secure software development practices and common vulnerabilities
• 6.2.3: Reviewing bespoke and custom software before release to production or customers to identify and correct coding vulnerabilities
• 6.2.4: Defining and using software engineering techniques or other methods to prevent or mitigate common software attacks and vulnerabilities

For supply chain security, these requirements extend to how organizations integrate third-party components. Code reviews should examine dependency usage, automated testing should include dependency scanning, and developers should understand supply chain attack vectors.

Requirement 6.3: Security Vulnerabilities Management

Requirement 6.3 establishes vulnerability identification and management practices directly applicable to software components:

• 6.3.1: Security vulnerabilities are identified and managed through a defined process
• 6.3.2: An inventory of bespoke and custom software and incorporated third-party software components is maintained
• 6.3.3: Vulnerabilities are addressed through installation of applicable security patches/updates

Requirement 6.3.2 explicitly mandates an inventory of bespoke and custom software and third-party software components incorporated into that software, supporting vulnerability and patch management for in-scope systems.

This requirement aligns with SBOM practices and provides the foundation for supply chain vulnerability management.

The requirement specifies that the inventory must include:

• All bespoke and custom software
• Third-party software components incorporated into custom software
• Third-party libraries and frameworks

This inventory must be current and accurate, enabling vulnerability correlation and remediation tracking.

Third-Party Component Management¶

PCI DSS 4.0 establishes specific expectations for managing third-party components throughout their lifecycle.

Component Inventory Requirements

Beyond the basic inventory mandate, organizations must:

• Document the purpose and function of each component
• Track component versions in use
• Identify component sources and provenance
• Maintain component update and patching information

Your SBOM serves as the foundation for PCI DSS component inventory compliance. Ensure SBOM generation covers in-scope bespoke and custom applications and that SBOMs are updated with each release.

Vulnerability Management for Components

Requirement 6.3.3 mandates that vulnerabilities be addressed through security patches and updates. For third-party components, this means:

• Continuous monitoring: Components must be monitored for newly disclosed vulnerabilities
• Risk assessment: Vulnerabilities must be evaluated for impact on the cardholder data environment
• Timely remediation: Critical and high-severity vulnerabilities require prompt remediation
• Compensating controls: When patches are unavailable, compensating controls must be implemented

PCI DSS requires vulnerabilities to be risk-ranked using reputable external sources and consideration of organizational impact; CVSS² is a common input. Requirement 6.3.3 sets explicit patching expectations for critical and high-severity vulnerabilities:

Note: PCI DSS 6.3.3 explicitly mandates that critical and high-security patches and updates be installed within one month. Lower-severity timelines should be defined by the entity's documented risk assessment process.

These timelines apply to component vulnerabilities just as they apply to operating system or application vulnerabilities. Organizations must demonstrate that their vulnerability management program encompasses in-scope third-party components.

Component Selection and Assessment

While PCI DSS doesn't prescribe specific component selection criteria, the standard's risk-based approach implies that organizations should:

• Evaluate component security before adoption
• Consider component maintenance status and project health
• Assess component provenance and integrity
• Document component selection rationale for high-risk decisions

Qualified Security Assessors (QSAs) increasingly examine component selection practices, particularly for components handling sensitive data or authentication functions.

Payment Page Script Integrity (Requirement 6.4.3)¶

Requirement 6.4.3 represents PCI DSS 4.0's most significant supply chain security addition, mandating integrity controls for scripts executing in payment pages. This requirement directly addresses Magecart-style attacks where malicious JavaScript injected into payment pages exfiltrates card data to attacker-controlled servers.

The requirement states:

"All payment page scripts that are loaded and executed in the consumer's browser are managed as follows:

• A method is implemented to confirm that each script is authorized
• A method is implemented to assure the integrity of each script
• An inventory of all scripts is maintained with written justification as to why each is necessary"

Scope of Requirement 6.4.3

The requirement applies to:

• Scripts loaded directly in payment pages
• Scripts loaded from third-party sources (CDNs, analytics providers, etc.)
• Inline scripts embedded in payment page HTML
• Scripts loaded dynamically by other scripts

Any JavaScript executing in the browser context of a payment page falls within scope, regardless of source or loading mechanism.

Authorization Methods

Organizations must implement methods to confirm script authorization:

• Content Security Policy (CSP)³: Define allowed script sources, preventing unauthorized script execution
• Script allowlisting: Maintain explicit lists of authorized scripts with enforcement
• Script inventory management: Document and approve each script before deployment

CSP implementation provides robust authorization enforcement:

Content-Security-Policy: script-src 'self' https://trusted-cdn.example.com;

This policy restricts script execution to same-origin scripts and those from explicitly trusted CDNs, blocking injection of scripts from unauthorized sources.

Integrity Assurance

Organizations must implement methods to assure script integrity:

• Subresource Integrity (SRI)⁴: Cryptographic hash verification for external scripts
• Version pinning: Loading specific, verified versions rather than "latest"
• Hash-based CSP: Using CSP with script hashes for inline scripts

Subresource Integrity (SRI) provides the primary mechanism for integrity verification:

<script src="https://cdn.example.com/payment.js"
        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
        crossorigin="anonymous"></script>

The browser verifies the downloaded script against the specified hash before execution. If the hash doesn't match—indicating the script has been modified—the browser blocks execution.

SRI can prevent script-tampering scenarios when enforced for affected external scripts with pinned hashes: a hash mismatch causes the browser to block execution. However, implementing SRI presents practical challenges⁵: third-party scripts that update frequently require constant hash updates, dynamic scripts may bypass SRI entirely, and organizations must establish processes for managing hash updates across deployments.

SRI implementation requirements:

• Calculate cryptographic hashes (SHA-384 or SHA-512 recommended) for all external scripts
• Include integrity attributes on all external script tags
• Include crossorigin="anonymous" for cross-origin resources
• Update hashes when scripts are legitimately updated
• Monitor for SRI failures indicating potential compromise

Script Inventory

Organizations must maintain a documented inventory of all payment page scripts including:

• Script name and source URL
• Purpose and business justification
• Owner responsible for the script
• Last review date
• Hash values for integrity verification

This inventory enables both authorization verification and ongoing script management. Review scripts periodically to identify and remove unnecessary scripts that expand attack surface.

Evidence and Validation Approaches¶

QSAs assessing PCI DSS 4.0 compliance examine supply chain controls through documentation review, technical testing, and process evaluation.

Documentation Evidence

Prepare documentation demonstrating:

• Component inventory: SBOM or equivalent inventory covering all in-scope applications
• Vulnerability management procedures: Documented processes for component vulnerability identification, assessment, and remediation
• Script inventory: Payment page script documentation with justification and approval records
• CSP policies: Documented Content Security Policy configurations
• SRI implementation: Records of script hashes and update procedures

Technical Evidence

QSAs typically request or verify:

• SBOM files demonstrating component inventory completeness
• Vulnerability scan reports covering components
• Remediation tickets showing vulnerability response
• CSP headers on payment pages (browser inspection)
• SRI attributes on external scripts (source inspection)
• Script inventory accuracy against deployed scripts

Process Evidence

Demonstrate operating procedures through:

• Change management records for component updates
• Script approval workflows
• Periodic script inventory reviews
• Vulnerability management meeting minutes
• Exception documentation for delayed remediation

QSA Expectations¶

QSA assessment approaches for supply chain requirements vary, but common expectations include:

The Qualified Security Assessor (QSA) community has developed interpretation guidance for Requirement 6.4.3, but significant variation remains⁶. Some QSAs accept CSP as the primary authorization method with SRI as optional; others mandate both. Some QSAs accept automated script inventory tools; others require manual documentation. The PCI Security Standards Council has intentionally provided implementation flexibility, recognizing that payment environments vary significantly—but this flexibility creates uncertainty for organizations preparing for assessment.

For Requirement 6.3.2 (Component Inventory):

• Complete inventory of in-scope third-party components
• Evidence inventory is maintained current
• Ability to correlate inventory with vulnerability databases
• Documentation of component purposes

For Requirement 6.3.3 (Vulnerability Management):

• Evidence of continuous vulnerability monitoring
• Remediation records demonstrating timeline compliance
• Documentation of risk assessment for vulnerabilities
• Compensating controls for unpatched vulnerabilities

For Requirement 6.4.3 (Payment Page Scripts):

• Complete script inventory with justifications
• Implemented CSP with appropriate restrictions
• SRI attributes on external scripts
• Evidence of script inventory accuracy verification
• Monitoring for CSP/SRI violations

QSAs may perform technical validation including:

• Comparing deployed scripts against inventory
• Verifying CSP header presence and configuration
• Testing SRI hash accuracy
• Attempting to load unauthorized scripts (blocked by CSP)
• Reviewing browser console for security warnings

Implementation Timeline¶

PCI DSS 4.0 requirements have phased compliance dates:

March 31, 2024: PCI DSS 3.2.1 retired; 4.0 becomes mandatory baseline

March 31, 2025: Future-dated requirements become mandatory, including:

• Requirement 6.3.2 (component inventory)
• Requirement 6.4.3 (payment page script integrity)

These supply chain requirements are now mandatory for PCI DSS 4.0 assessments. Given implementation complexity—particularly for Requirement 6.4.3—organizations should not defer script governance work until assessment fieldwork begins.

The challenge many organizations face: their payment pages load scripts from third-party analytics providers, fraud detection services, A/B testing platforms, and chat widgets—often added by marketing teams without security review. When security teams attempt CSP/SRI implementation, they discover payment pages loading 15-20 external scripts, many of which update automatically and would break if SRI were enforced. Untangling these dependencies and establishing script governance requires cross-functional coordination that extends well beyond security teams.

Implementation Phases:

1. Assessment (Months 1-2): Inventory current state, identify gaps, assess payment page script usage
2. Planning (Months 2-3): Design CSP policies, plan SRI implementation, establish component inventory processes
3. Implementation (Months 3-6): Deploy CSP, implement SRI, establish automated SBOM generation
4. Testing (Months 6-7): Validate controls, test for bypasses, verify inventory accuracy
5. Documentation (Months 7-8): Prepare evidence packages, document procedures, train staff

Recommendations¶

We recommend organizations preparing for PCI DSS 4.0 supply chain requirements:

1. Implement SBOM generation for in-scope bespoke and custom applications in the cardholder data environment, ensuring coverage of incorporated third-party components

2. Extend vulnerability scanning to cover all in-scope dependencies, with remediation tracking meeting PCI DSS timelines

3. Inventory all payment page scripts immediately, documenting purpose, source, and business justification for each

4. Deploy Content Security Policy on payment pages, starting with report-only mode to identify legitimate scripts before enforcement. CSP report-only mode is essential—it reveals which scripts would be blocked without actually breaking functionality, allowing gradual refinement of policies.

5. Implement Subresource Integrity for all external scripts on payment pages, establishing hash management procedures for updates. Organizations using third-party scripts that update frequently (like analytics or A/B testing) face a choice: implement automated hash updating workflows, work with vendors to provide version-pinned URLs, or remove scripts that can't be integrity-verified from payment pages.

6. Establish script change management requiring security review and approval for payment page script modifications

7. Monitor CSP and SRI violations to detect attempted attacks or configuration issues

8. Treat these controls as ongoing operations—the March 2025 deadline has passed, and complex implementations require continuing testing and refinement

PCI DSS 4.0's supply chain requirements represent a significant advancement in payment security standards. Organizations that implement robust component management and payment page script integrity controls will not only achieve compliance but meaningfully reduce their exposure to supply chain attacks targeting payment data.