PCI DSS 4.0: where software supply chain controls map

PCI DSS 4.0 touches the software supply chain mainly in requirement 6.3.2, an inventory of custom software and the third-party components inside it, and in the payment page script rules in 6.4.3 and 11.6.1. These have been scored since 31 March 2025, so a current component inventory is now expected.

This summary relies on a vendor article that lists the requirements, plus the PCI Security Standards Council overview. Wording and numbering must be checked against the official standard in the PCI SSC Document Library before you use it in an assessment.

Which requirements matter most?

According to a Qualys article on 2026 application assessments:

• 6.3.2 asks for a current record of custom applications and APIs and the third-party components inside them. It is marked as a new requirement in 4.0.
• 6.4.2 expects an automated technical solution that continually detects and prevents web-based attacks for public-facing web applications, replacing an earlier option of manual review.
• 6.4.3 asks for an inventory of every script on payment pages, a written justification for each, and integrity checks. The article notes that analytics tags, chat widgets and tag manager containers all count.
• 11.6.1 asks for a mechanism that detects and alerts on unauthorized changes to payment page content and HTTP headers.

The article also says the 51 requirements that were best practice in 4.0 have been fully scored since 31 March 2025.

The PCI SSC says the standard provides a baseline of technical and operational requirements for protecting payment account data and applies to entities that store, process or transmit cardholder data, or that could affect the cardholder data environment.

How do supply chain controls line up?

Inventory (6.3.2). A software bill of materials per application release, covering direct and transitive dependencies, gives you the component list. Keep it with the release record and update it on each build. A stale spreadsheet will not satisfy an assessor who compares it to what is deployed.

Browser-side scripts (6.4.3, 11.6.1). These are a supply chain problem of a different shape: scripts loaded from third parties into the customer's browser. The inventory must include them, with owner and reason. Integrity checks and change alerts are separate controls. Dependency scanning of your build does not see scripts injected by a tag manager at runtime, so treat the two as distinct inventories.

Attack prevention (6.4.2). A web application firewall or similar service is the usual answer. Dynamic testing complements it by checking the live site.

Vulnerability handling. Records of findings, who owns them and when they were fixed support your wider vulnerability management evidence. We did not fetch the text of the patching requirements, so read the standard directly for time limits.

What evidence will an assessor want?

• The inventory and how it is generated.
• Screenshots or exports showing it matches production.
• The script inventory for payment pages, with justifications.
• Alerts and responses for payment page changes.
• Policies and records of who reviews findings.

Safeguard produces component inventories and findings, and its compliance automation can help organize the evidence. It does not make you PCI compliant, and a Qualified Security Assessor decides your result.

See it at /demos/sca-dependency-inventory.

What to do

1. Confirm requirement wording in the official PCI DSS document.
2. Generate an SBOM for each in-scope application on every release.
3. Build a separate inventory of payment page scripts with owners and reasons.
4. Turn on change detection for payment pages and test the alert path.
5. Decide who reviews findings and how fast they fix them.
6. Collect all of the above where your assessor can see it.

Quick check

Sources

• PCI Security Standards Council: PCI DSS
• Qualys: PCI DSS 4.0.1 application requirements you are assessed on in 2026

Last reviewed: 18 October 2026.