A mid-sized payment gateway processing 40,000 transactions a day found out the hard way that "we use mostly open-source libraries" is not a compliance answer. During a 2025 QSA assessment, the assessor asked for an inventory of every third-party component in the checkout service — versions, patch status, known CVEs. The team had none. What followed was a six-week remediation sprint before the Attestation of Compliance could be signed.
This is now a routine finding. PCI DSS software composition analysis has moved from "good practice" to an explicit, dated requirement under PCI DSS 4.0.1, and payment processors are discovering that their existing vulnerability scanning does not cover it. Below is what the standard actually requires, why it singles out third-party and open-source code, and how SBOMs and payment application security testing fit into an assessment that a QSA will sign off on.
What Does PCI DSS Actually Require for Software Composition Analysis?
PCI DSS 4.0.1 requires payment processors to maintain a documented inventory of every third-party and open-source component used in bespoke or custom payment software, and to track known vulnerabilities against that inventory on an ongoing basis. This obligation sits primarily in Requirement 6.3.2, which became mandatory on March 31, 2025, after a one-year transition period from PCI DSS 4.0's publication. The requirement text is specific: entities must maintain "an inventory of bespoke and custom software, and third-party software components incorporated into bespoke and custom software... to facilitate vulnerability and patch management." That inventory has to be kept current, not produced once for an audit and forgotten.
In practice, this is software composition analysis by definition — the automated identification of open-source and third-party dependencies inside an application, mapped against vulnerability databases like the National Vulnerability Database and vendor advisories. A payment processor running Java, Node, or Python services typically has hundreds to low thousands of transitive dependencies per application. Manually maintaining that inventory in a spreadsheet does not survive a single dependency update, which is why QSAs increasingly expect to see SCA tooling output as evidence, not a manually curated list.
Why Does PCI DSS 4.0 Single Out Third-Party Software?
PCI DSS 4.0 singles out third-party software because the majority of exploited vulnerabilities in payment environments originate in dependencies the organization didn't write, not in first-party code. Verizon's Data Breach Investigations Report has repeatedly flagged third-party and supply chain involvement in a growing share of breaches, and payment-specific incidents like the 2023 MOVEit and 2020 SolarWinds compromises made clear that a vulnerable library several layers deep in a build can expose cardholder data even when the primary application code is clean.
PCI DSS 4.0 third-party software provisions extend beyond the component inventory in 6.3.2. Requirement 6.3.1 requires a documented process to identify new vulnerabilities from reputable sources and assign a risk ranking (critical, high, medium, low) using industry-recognized practices — essentially, an SLA for triaging what your SCA tool finds. Requirement 6.2.4 additionally requires that custom software be developed using techniques that prevent or mitigate common coding vulnerabilities, which pushes the same scrutiny upstream into how third-party libraries get selected and pinned in the first place. Together, these requirements mean a payment processor can no longer treat "it's an open-source library, not our code" as a reason to exclude something from vulnerability management.
How Does an SBOM Support PCI DSS Compliance Evidence?
An SBOM supports PCI DSS compliance evidence because it is the structured, machine-readable format that satisfies the Requirement 6.3.2 inventory obligation without manual upkeep. A Software Bill of Materials generated in SPDX or CycloneDX format lists every direct and transitive dependency, its version, license, and origin, and can be regenerated automatically on every build. That gives a QSA a timestamped, reproducible artifact instead of a document someone updated by hand three months before the assessment window.
SBOM for PCI compliance also matters because Requirement 6.3.2 explicitly ties the inventory to patch management: the inventory has to be "used to facilitate vulnerability and patch management," meaning it needs to be queryable against newly disclosed CVEs, not just descriptive. When a vulnerability like the December 2021 Log4Shell flaw (CVE-2021-44228) surfaces, an organization with current SBOMs across its estate can answer "are we affected, and where" in minutes. Organizations without one have historically taken days to weeks to manually audit build artifacts — an unacceptable delay for a component embedded in payment processing infrastructure. PCI DSS assessors are increasingly asking processors to demonstrate exactly that turnaround time as part of the 6.3.1 risk-ranking evidence.
What Counts as Payment Application Security Testing Under PCI DSS?
Payment application security testing under PCI DSS covers both the server-side application code and, since the 4.0.1 update, the client-side scripts running in the customer's browser on payment pages. Requirement 11.6.1, which also became mandatory on March 31, 2025, requires a change- and tamper-detection mechanism to alert on unauthorized modifications to HTTP headers and the content of payment pages as received by the consumer browser. Requirement 6.4.3 requires that all scripts loaded and executed on a payment page be authorized, have their integrity verified, and be maintained in an inventory with written justification for why each one is necessary.
These two requirements exist because of a specific attack pattern: Magecart-style digital skimming, where attackers inject malicious JavaScript — often through a compromised third-party analytics, chat, or ad-tech script — directly into a checkout page to steal card data client-side, bypassing server-side controls entirely. British Airways' 2018 breach, attributed to a single modified JavaScript file, and the ongoing wave of Magecart incidents affecting thousands of e-commerce sites, are why PCI DSS now treats the browser-executed payment page as part of the assessed application surface, not just the backend. Payment application security testing that only scans server-side code and container images misses this entire attack class.
What Happens If a Payment Processor Fails an SCA-Related Requirement?
A payment processor that fails an SCA-related requirement during assessment typically receives a non-compliant finding on the specific requirement, which blocks signature of the Attestation of Compliance until remediation is demonstrated and, in some cases, re-tested. For a Level 1 merchant or processor undergoing a Report on Compliance with a Qualified Security Assessor, a missing or stale component inventory under 6.3.2, or the absence of a documented vulnerability risk-ranking process under 6.3.1, is one of the more common gaps QSAs report following the March 2025 enforcement date, since many organizations treated the one-year transition period as optional rather than a deadline.
The downstream consequence is not just a delayed AOC. Acquiring banks and card brands can restrict processing privileges or increase transaction fees for processors that lapse out of compliance, and a documented gap in SCA for payment processing becomes discoverable in the event of a later breach investigation, which affects liability determinations under card brand rules. Remediation timelines of four to eight weeks are common when an organization has to stand up SCA tooling, generate SBOMs retroactively, and build a triage process from scratch under assessment pressure — all of which is materially cheaper to do before the assessment window than during it.
How Safeguard Helps
Safeguard gives payment processors continuous, automated software composition analysis mapped directly to PCI DSS 4.0.1 evidence requirements, rather than a point-in-time scan run the week before an audit. Every build across your services generates an SPDX/CycloneDX SBOM automatically, satisfying the Requirement 6.3.2 inventory obligation with a reproducible, timestamped artifact a QSA can independently verify.
Safeguard continuously matches every third-party and open-source component in that inventory against newly disclosed CVEs and assigns risk rankings aligned to the process Requirement 6.3.1 expects, so triage SLAs are enforceable and auditable rather than ad hoc. For the client-side surface covered by Requirements 6.4.3 and 11.6.1, Safeguard extends the same dependency visibility to scripts loaded on payment pages, flagging unauthorized or unverified third-party scripts before they become the next Magecart headline.
The result is an evidence trail — inventory, risk ranking, remediation history, script authorization — that maps directly onto the requirement numbers your assessor will ask about, turning PCI DSS software composition analysis from a scramble before assessment into a control that runs quietly in the background all year.