Payment applications live or die by a document most engineering teams have never seen: the Report on Compliance. Inside it, a Qualified Security Assessor checks whether every custom script, every third-party library, and every payment page component is accounted for — not just scanned for bugs. PCI DSS 4.0, fully enforced since March 31, 2025, shifted the compliance burden from "did you run a scanner" to "can you prove what's running in production, where it came from, and that nobody tampered with it." That's a software supply chain problem, not a static analysis problem.
Application security teams that built their PCI DSS program around SAST and SCA tools like Checkmarx are discovering the gap firsthand during 2025 and 2026 audit cycles: those tools tell you a library has a CVE, but they don't maintain the continuously updated inventory, provenance record, and tamper-detection evidence that Requirements 6.3.2, 6.4.3, and 11.6.1 now demand. Below is what's actually required, when it's enforced, and where scanner-only programs fall short.
What Does PCI DSS 4.0 Actually Require From Application Security Teams?
PCI DSS 4.0 requires AppSec teams to maintain three things a bug scanner was never built to produce: a current inventory of bespoke and custom software (Requirement 6.3.2), an authorized inventory of scripts loaded on payment pages with a documented business justification for each (Requirement 6.4.3), and a mechanism to detect unauthorized changes to those scripts at least weekly (Requirement 11.6.1). Requirement 6.3.2 specifically calls for an inventory "to facilitate vulnerability and patch management," which the PCI Security Standards Council's guidance documents describe in practice as SBOM-equivalent data — component name, version, and known vulnerabilities, kept current, not a point-in-time export from last quarter's scan.
Requirement 6.4.3 is narrower but harder to satisfy with existing tooling: it applies specifically to consumer-facing payment pages and requires an inventory of every script — first-party and third-party, including tag managers and analytics pixels — with justification for why each one needs to execute. Requirement 11.6.1 then requires a change-and-tamper-detection mechanism (like a Content Security Policy report-only setup or subresource integrity monitoring) that alerts within a defined interval, no longer than weekly, if any of those scripts change unexpectedly. Together these three controls target the exact attack pattern behind Magecart-style skimming incidents, where a single compromised third-party script — not a vulnerability in first-party code — siphoned card data from thousands of checkout pages.
When Do the New PCI DSS 4.0 Software Requirements Take Effect?
These requirements are not future-dated anymore — they became mandatory on March 31, 2025, after a one-year transition period that started when PCI DSS 4.0 itself became the only active standard on March 31, 2024. Requirements 6.3.2, 6.4.3, and 11.6.1 were all listed as "future-dated" in the original 4.0 release specifically because the Council recognized most organizations didn't have inventory and integrity-monitoring processes in place. That grace period is over. Any Level 1 or Level 2 merchant undergoing a Report on Compliance assessment in 2025 or 2026 is now assessed against these controls as fully in-force, not as a documented remediation plan. QSAs report that the software inventory requirements — 6.3.2 in particular — are among the most commonly cited gaps in current assessment cycles, because most inventories that exist were built for a security scan, not for continuous compliance evidence.
Why Isn't SAST/SCA Scanning Alone Enough for Requirement 6.3.2?
SAST/SCA platforms weren't built to produce a maintained inventory — they were built to find vulnerabilities in a snapshot of code at scan time, which is a fundamentally different deliverable than what 6.3.2 requires. Checkmarx, like most tools in that category, excels at identifying known-CVE dependencies and insecure code patterns during a CI run or a scheduled scan. But a scan result is a report, not a living inventory: it ages the moment a new dependency is pulled in, a container base image is rebuilt, or a developer adds a package outside the pipeline that triggered the scan. PCI DSS 4.0's Requirement 6.3.2 explicitly calls for the inventory to be "maintained" — the Council's own reporting template asks assessors to confirm the process for keeping it current, not just that an inventory was produced once.
In practice, this means AppSec teams running Checkmarx or similar SAST/SCA-first tooling end up bolting on spreadsheets, manual SBOM exports, and quarterly reconciliation exercises to bridge the gap between "here's a scan result" and "here's what's actually deployed right now, everywhere." That reconciliation work is where audits fail: a component shows up in production that never appeared in any scan, because it was pulled in via a transitive dependency, a build-time script, or a vendor update that bypassed the pipeline. A continuously generated, deployment-tied SBOM closes that gap; a periodic scan report does not.
How Does Requirement 6.4.3 Change Payment Page Security?
Requirement 6.4.3 moves payment page script control from a design review checkbox to an operationally enforced, continuously verified control, and most AppSec tooling stacks have no equivalent capability today. Traditional AppSec scanning operates on source code and build artifacts — it has no visibility into what a browser actually loads when a customer hits the checkout page, which is precisely where 6.4.3 and 11.6.1 operate. A tag manager script, a chat widget, or a fraud-detection pixel can all be added by a marketing team or a third-party vendor with zero code review, and none of it would ever cross a Checkmarx scan.
Meeting 6.4.3 in practice requires runtime script inventories captured from the actual rendered page, cross-referenced against a documented allowlist with a named business owner for each script. Combined with 11.6.1's weekly-or-better change detection, this means AppSec teams need visibility that extends past their own repositories into every script origin that touches the payment flow — including scripts loaded by other scripts. Organizations that treat this as a one-time documentation exercise for the audit tend to fail the following year's assessment when the inventory has quietly drifted.
What Happens If You Fail a PCI DSS Audit Over Software Inventory Gaps?
Failing on software inventory grounds doesn't just mean a finding on a report — it can mean loss of compliant status, increased card-brand scrutiny, and, if a breach follows, direct exposure to non-compliance fines that card brands can levy retroactively for the period the gap existed. IBM's 2024 Cost of a Data Breach Report put the global average breach cost at $4.88 million, and breaches tied to third-party or supply chain compromise took an average of 26 additional days to identify and contain compared to other attack vectors — time during which card data continues to be exposed on an unmonitored payment page. For merchants, a compliance gap discovered during an assessment (rather than self-reported) also increases the likelihood of an on-site or more intensive QSA review the following cycle.
The Magecart family of attacks remains the clearest illustration of why 6.4.3 and 11.6.1 exist: in incidents going back to British Airways' 2018 breach (a £20 million ICO fine) and continuing through smaller e-commerce compromises reported annually since, the root cause was consistently a third-party script modified without the merchant's knowledge — exactly the failure mode these requirements are designed to catch within a week instead of months.
How Safeguard Helps
Safeguard is built around the assumption that a compliance artifact is only as good as the data feeding it, which is why we generate SBOMs and software inventories continuously from the actual build and deployment pipeline rather than from periodic scans. For Requirement 6.3.2, that means the component inventory a QSA reviews is the same one that updates automatically every time a dependency changes, a container is rebuilt, or a new service ships — no quarterly spreadsheet reconciliation required.
Safeguard extends that same provenance model to Requirement 6.4.3 and 11.6.1 by tracking script origins and integrity across the software supply chain feeding customer-facing applications, so changes to third-party and first-party components are flagged as they happen rather than discovered at audit time. Where SAST/SCA tools like Checkmarx tell you a library has a known vulnerability, Safeguard tells you what's actually deployed, where it came from, and whether it changed — the specific evidence PCI DSS 4.0 now requires. For AppSec teams heading into their next Report on Compliance cycle, that difference is the line between a clean assessment and a finding that takes months to remediate.