PCI DSS 4.0 makes software supply chain security an explicit audit requirement: 6.3.2 mandates an inventory of bespoke and custom software including third-party components, 6.3.1 requires monitoring those components for vulnerabilities, and 6.4.3 plus 11.6.1 require payment page scripts to be authorized, justified, and integrity-monitored. Version 3.2.1 retired on 31 March 2024, so 4.0 is now the only game in town, with the future-dated requirements becoming mandatory on 31 March 2025. If your cardholder data environment (CDE) includes software you build — and for almost every merchant or service provider with a checkout flow, it does — here's what changed and what an assessor will ask for.
Requirement 6.3.2: the component inventory is now an audit artifact
The new 6.3.2 requires maintaining "an inventory of bespoke and custom software, and third-party software components incorporated into bespoke and custom software" to support vulnerability and patch management. Read that twice: not just your applications, but the libraries inside them. Your package-lock.json and pom.xml files contain the raw data, but an assessor wants a maintained inventory with an owner and an update process, not a pile of lockfiles.
The practical implementation is an SBOM generated per release. CycloneDX or SPDX format, produced in CI, stored where the QSA can review it:
syft dir:. -o cyclonedx-json > sbom.json
That single artifact answers the inventory question and feeds 6.3.1. Requirement 6.3.2 was a best practice until 31 March 2025, after which it's mandatory — meaning assessments in 2025 will test whether the inventory existed and was maintained, not whether you generated one the week before the audit.
Requirement 6.3.1: vulnerabilities in third-party code count
Requirement 6.3.1 requires identifying security vulnerabilities in bespoke, custom, and third-party software using industry-recognized sources, ranking them by risk, and covering them in your patch process under 6.3.3 (critical patches within one month). PCI has always required patching; what 4.0 sharpened is that a CVE in a Java library you compiled in is your finding, not the library author's problem.
Operationally this means software composition analysis running continuously against the inventory from 6.3.2, with risk ranking that reflects your environment — a critical CVE in a dependency that never touches the CDE data path can be ranked accordingly, but you need the analysis documented, not assumed. QSAs increasingly ask for the ranking methodology in writing. Our companion piece on PCI DSS AppSec testing covers how 6.2.3 and 6.2.4 layer code review on top of this.
Requirements 6.4.3 and 11.6.1: the Magecart clauses
These two exist because of formjacking. British Airways (2018, roughly 380,000 payment records, via a modified script) and the long tail of Magecart attacks demonstrated that a payment page loading 40 third-party scripts is an unmonitored supply chain executing in the customer's browser.
Requirement 6.4.3 (mandatory 31 March 2025) requires that every script loaded on payment pages is authorized, integrity-assured, and inventoried with written justification. Requirement 11.6.1 adds a change- and tamper-detection mechanism covering payment page scripts and security-relevant HTTP headers, evaluated at least weekly. Concretely, the toolbox is: Subresource Integrity attributes (integrity="sha384-...") for static scripts, Content-Security-Policy headers to bound what can load at all, and a monitoring service or synthetic client that renders the payment page and diffs observed scripts against the approved inventory. The awkward part is marketing tags — the justification exercise usually kills a few, which nobody mourns.
Requirement 12.8: your vendors are in scope too
The supply chain reading of PCI extends past code into third-party service providers (TPSPs). Requirement 12.8 requires a list of TPSPs, due diligence before engagement, written agreements acknowledging responsibility for cardholder data, and an annual monitoring program of their compliance status — typically collecting their Attestations of Compliance. 4.0's 12.8.5 tightens the responsibility matrix: you must document exactly which requirements each TPSP handles versus which remain yours. When a payment processor says "we're PCI compliant," that sentence covers their obligations, not your integration code.
Putting it together: an evidence checklist
| Requirement | Deadline | Evidence a QSA will request |
|---|---|---|
| 6.3.2 component inventory | 31 Mar 2025 | SBOMs or inventory exports, update process, owner |
| 6.3.1 vulnerability identification | In force | SCA/scanner reports, risk ranking methodology |
| 6.3.3 patching | In force | Tickets showing critical fixes inside one month |
| 6.4.3 script authorization | 31 Mar 2025 | Script inventory with justifications, SRI/CSP configs |
| 11.6.1 tamper detection | 31 Mar 2025 | Monitoring tool output, weekly check records, alert samples |
| 12.8 TPSP management | In force | TPSP list, AOCs, responsibility matrix |
None of this requires exotic tooling — SBOM generation, continuous SCA, CSP headers, and a script monitor cover the technical surface. What it does require is starting before the March 2025 dates, because 12 months of maintained inventory is evidence, and a fresh one is a finding waiting to be written. Platforms like Safeguard consolidate the SBOM, scanning, and ranking evidence into one export, which shortens the assessment conversation considerably.
Frequently asked questions
Does PCI DSS 4.0 require an SBOM?
Not by that name. Requirement 6.3.2 requires an inventory of custom software including its third-party components, and an SBOM in CycloneDX or SPDX format is the standard way to produce and maintain one. Most QSAs now accept — and increasingly expect — SBOM output as the inventory artifact.
When did the new supply chain requirements become mandatory?
PCI DSS 4.0 took full effect on 31 March 2024 when 3.2.1 retired. The future-dated requirements — including 6.3.2, 6.4.3, and 11.6.1 — become mandatory on 31 March 2025 and are best practices until then.
Do the payment page script rules apply if we use a hosted iframe?
Partially. SAQ A merchants embedding a compliant provider's iframe still have obligations for the page that hosts the iframe, and 6.4.3/11.6.1 apply to scripts on that page since they can attack the iframe context. Your provider's AOC covers their side only.
Are open source components treated differently from commercial ones?
No. Requirements 6.3.1 and 6.3.2 apply to any third-party component incorporated into your software, open source or commercial. The difference is operational: for open source you patch by upgrading versions yourself, so scan-to-upgrade latency is what an assessor will probe.